Přeskočit na obsah

Wikiverzita:Technické potřeby/G

Přidat odkazy
Z Wikiverzity

Wikiverzita:Technické potřeby/G

Databáze

[editovat]
  • Analýza:
    • navrhnout vhodný relační a objektový databázový model pro ukládání vědeckých dat, různých seznamů atp. v prostředí MediaWiki ("databázi v databázi")
    • navrhnout vhodný model přístupových práv
    • navrhnout vhodný transakční mechanismus
    • navrhnout nástroje pro kontrolu konsistence (integrity) a udržování takovýchto dat
    • navrhnout vhodný revertovací mechanismus
  • Implementace pilotního projektu:
    • implementovat databázový stroj, založený na navržených principech (nejspíš ve formě extenze)
    • provést transformaci stávajících databázových dat do navrženého systému
    • vyvíjet nástroje pro třídění a další zpracování takovýchto databázových dat
    • vyvíjet nástroje pro snadnou manipulaci s datovými strukturami a daty na vyšší úrovni (vytváření databází, spojování, rozpojování a přemísťování objektů atd.)
    • vyvíjet nástroje pro uživatelský vstup/výstup takovýchto dat (vstupní formuláře, výstupní sestavy) včetně možnosti indexace takových dat (např. možnost zobrazení jen vybraných prvků tabulky)
    • vyřešit export/import databázových dat do otevřených formátů relačních a objektových databází (preferovaně XML)
    • navrhnout a implementovat vhodný paralelismus pro možnost synchronizace takovéto databáze s běžnými databázemi (nejspíš pomocí botů), a to alespoň pro jeden relační model (SQL) a dva objektové (XQuery, XPath)
  • vyřešit způsob sdílení databázových dat s jinými projekty (jazykovými verzemi)

Odůvodnění

[editovat]

Problém MediaWiki

[editovat]

Software MediaWiki je v podstatě sadou PHP skriptů, pracujících nad relační databází (MySQL či PostgreSQL), původně vyvinutý pro potřeby wiki encyklopedie. Datovým modelem takové encyklopedie je v podstatě hashovací tabulka, která umožňuje vyhledávat články podle jejich jedinečného názvu z pomyslné hromady, která nemá žádnou strukturu (je plochá), pouze je možné ji rozdělit na různé jmenné prostory. Struktura je do takovéto hromady zaváděna teprve sekundárně pomocí kategorií, o kterých se hovoří jako o stromech (i když jejich grafová struktura nemusí být nutně stromová). Struktura relační databáze, na které celá MediaWiki běží, je tak před běžnými uživateli (i správci a byrokraty) prakticky skryta, odstíněna.

Tato koncepce vyhovuje základním požadavkům na shromažďování encyklopedických hesel, i když i zde má problémy. Tísnivě jsou pociťovány napřiklad velmi omezené možnosti prohledávání. Jedná se zejména o absenci efektivních vyhledávací algoritmů. Prohledávání probíhá pouze fulltextově, nanejvýš lze specifikovat oblast jmenných prostorů. Nelze používat regulární výrazy, ani logické operátory, ani substringy, ani různé gramatické tvary. Nelze specifikovat ani žádné další parametry, části článků, pole atd, jak je tomu jinde běžné.

Další problémy celé koncepce vyvstávají u takových projektů nadace WikiMedia, jejichž vnitřní struktura je složitější a pro které datový model hashovací tabulky již nedostačuje; takovým projektem je například Wikiverzita, kde je využívano možnosti odlišné konfigurace MediaWiki, např. možnost vytváření podstránek i v hlavním jmenném prostoru, čímž je možné vytvářet např. stromové struktury vedle lineárních. Ovšem podpora této možnosti ze strany systému je minimální: V podstatě se jedná jen o delší názvy stránek, obsahující lomítka, avšak ani takto vzniklé struktury již nelze využívat například pro specifikaci vyhledávacích kriterií. Případný přesun jedné části stromu do jinéhu uzlu je velmi komplikovaný.

Nejobvyklejšími strukturami pro ukládání rozsáhlejších dat s možností indexace je pole a seznam. Prakticky jediným způsobem, jak uložit pole, je tabulka. Ve skutečnosti se ale jedná jen o způsob jednoduššího zápisu HTML tagu <table>, který neumožňuje žádné další operace, jako např. třídění, řazení, prohazování sloupců. selekci dat. Vícedimenzionální tabulky prakticky implementovat nelze. Jediným řešením je problém obejít tak, že obsah stránky je stažen, zpracován nějakým externím software a pak znovu uploadován. To se týká i jednodušší datové struktury, jakou je např. seznam.

Problém Wikipedie

[editovat]

Tyto problémy se netýkají jen Wikiverzity, ale i ostatních projektů, i když v méně citelné míře. Viz např. namátkou Wikipedie: Tabulky: w:Periodická tabulka, w:Volby do zastupitelstev obcí 1994, w:Výsledky Tour de France 2007, w:Seznam jezdců Formule 1, w:Tabulka rekordů Formule 1, w:Pohár UEFA 2005/06, w:Mistrovství světa ve fotbale 1998, w:Portál:Hudba/Tabulka roků v hudbě, w:Česká volejbalová extraliga žen 2006/07 či seznamy: w:Seznam mezinárodních poznávacích značek, w:Seznam planetek M, w:Seznam německých názvů obcí a osad v Česku. Udržovat takovéto struktury pomocí ručních editací je je poměrně krkolomné, udržovat je externími utilitami či roboty není o mnoho méně krkolomější. To je zřejmě jeden z důvodů, proč takové tabulky obsahují převážně historická data; udržování aktuálních dat v konsistentní podobě je daleko obtížnější.

Problémy menších projektů

[editovat]

U menších projektů je situace ještě naléhavější: projekt Wikislovník je prakticky celý založen na tabulkách; wikizprávy potřebují lepší mechanismus pro časoprostorové řazení zpráv, stávající systém kategorií, kterým se to řeší, je dost krkolomný. Wikidruhy ze své podstaty vyžadují složitější systém řazení, třídění a prohledávání. Rovněž wikiknihy, wikisource a wikicitáty by uvítaly dokonalejší systém kategorizace.

Nejtíživěji doléhá absence dokonalejších mechanismů pro správu dat na Wikiverzitu. Jako modelový příklad jsme zde založili databázi snů, na které se dá celá problematika dobře demonstrovat. Je to projekt, který zaručuje pomalé plnění celé databáze a bylo by zde možno aplikovat různá kritéria na třídění, prohledávání a generování statistik: např. podle uživatelů, ročních dob, dnů v týdnů, klíčových slov atd. Dále by bylo lze požadovat např. automatický výstup slovníku klíčových slov atd.

Databáze na Wikiverzitě jako příklad

[editovat]

Současnost

[editovat]

V současné době se na Wikiverzitě rozvíjí několik projektů, které mají databázovou strukturu a které citelně postrádají mechanismy pro další zpracování:

Příprava

[editovat]

Vážnými adepty, které vyžadují složitejší správu dat a jejichž absence je při každodenní práci již silněji pociťována, jsou:

  • katalog citací odborných článků
  • databáze fyzikálních konstant
  • kategorizace biblických odkazů
  • databáze osobností
  • databáze historických událostí
  • databáze hudebních motivů pro třídění a analýzu hudebních děl
  • databáze biosignálů

a další.

Ralizace těchto projektů je právě blokována absencí databázových mechanismů, o kterých je řeč. Proto bylo rozhodnuto s nimi prozatím počkat do doby, než se začne řešit problematika databází na Wikiverzitě jako takových.

Možnosti řešení

[editovat]

Dosavadní návrhy a diskuse

[editovat]

Problematikou databází se na Wikiverzitě zabýváme celkem často, viz např.:

O problémech, které se dotýkají problematiky administrace databázových dat, probíhají rozsáhlé diskuse již od založení Wikiverzity:

Možné modely

[editovat]

Sami jsme zatím uvažovali o několika modelech, které by bylo možno implementovat:

Tabulka na jedné stránce

[editovat]

Jedna tabulka relační databáze by byla uložena na jedné stránce, například ve formátu CSV. Vhodná extenze by ji pak mohla zobrazovat v různých vhodných tvarech, např. jako HTML tabulku nebo ve formě přímého exportu CSV dat. Formou linků by pak bylo možno nějakým způsobem implementovat případné relační vztahy mezi více takovými tabulkami. Tato extenze by implementovala alespoň nějakou základní podmnožinu dotazů, např. SQL, případně volanou jako speciální tagy či šablony (např. aritmetické a logické operace, regexpy apod.)

Záznam na jedné stránce

[editovat]

Jedna stránka by reprezentovala jeden záznam. Byla by to běžně editovatelná stránka, formátovaná určitým způsobem tak, aby bylo možné jednoznačně identifikovat její části jako pole, případně objekty. Primární přístupové klíče k takové stránce by byly součástí jejího názvu. Možnost narušení integrity dat by se redukovala možností návrhu vstupních formulářů.

Hierarchický model

[editovat]

Stromová struktura databáze by byla realizována systémem podstránek, jako je tomu v současné době např. u Sny/Databáze. Software na podporu takové databáze by umožňoval rychlejší navigaci a prohledávání takovéhoto databázového stromu, sledoval konsistenci dat, umožňoval editaci stránek pomocí formulářů, generoval statistiky atd.

XML

[editovat]

Databázová data by se ukládala na stránky ve formátu XML. Tímto způsobem by bylo možné velmi pružně implementovat různé databázové modely, relační, hierarchické i objektové databáze, jakož i zajišťovat snadný export a import stránek. Tanto způsob se jeví ze všech výše uvedených způsobů jako nejperspektivnější a nejkonzistentnější, i s ohledem na to, že XML export a import je v MediaWiky v podstatě používán. Při tomto přístupu by mohla být jedna databáze uložena jak na jedné, tak i na více stránkách, které by tvořily uzly nebo podstromy databázového modelu DOM.

Úrovně řešení

[editovat]

Lze uvažovat o řešení problému na různých úrovních:

Databáze MediaWiki

[editovat]

Řešit problém změnou struktury databáze, na které běží MediaWiki, by bylo nejradikálnější řešení, které se však zřejmě vymyká naším současným možnostem. Ani přímé spojení s jinou databází na úrovni SQL dotazů na úrovni MediaWiki asi nepřichází v úvahu.

Extenze

[editovat]

Nejschůdnějším řešením by byl návrh vhodné extenze (či sady extenzí).

Boty

[editovat]

Boty se jeví jako vhodné doplnění výše uvedeného řešení.

Import/Export

[editovat]

Požadavkem je, aby databázová data bylo možno exportovat a importovat. Bylo by ale krajně nevhodné, aby export, následné externí zpracování a opětný import byly jedinou možností, jak databázi administrovat. Podpora na úrovni extenzí, jak bylo výše řečeno, se jeví jako nevyhnutelná.

Odkazy na cizí stroj

[editovat]

Zcela okrajovým řešením by bylo řešení pomocí odkazů na jiný stroj, např. na SandboxServer, na kterém by běžel jiný SW, než MediaWiki. Ale nelze vyloučit, že i takové řešení by se mohlo ukázat být schůdné, kdyby se vypracoval takový mechanismus, aby se odkazy na databázi či její různé záznamy daly integrovat do stránek alespoň tak jednoduše, jako např. odkazy na multimediální soubory, uložené na Commons.

Proponovaný návrh

[editovat]

Z výše uvedeného vysvítá, že implementace databázových mechanismů, přístupných na uživatelské úrovni v prostředí software MediaWiki, není triviální. Z tohoto důvodu požadujeme, aby někdo, kdo se vyzná jak v problematice databází, tak problematice MediaWiki, navrhnul možná řešení, která by byla využitelná i pro ostatní projekty. Řešení problémy pak bude probíhat ve dvou fázích:

Analýza problému

[editovat]
  • Název: Možnosti implementace uživatelských databázi na projektech nadace WikiMedia
  • Priorita: 1
  • Požadavky na zpracovatele: Znalost MW, XML a problematiky relačních, hierarchických a objektových databází
  • Zadání: Zpracovatel se seznámí s problematikou organizace dat na jednotlivých projektech WM, vyjádří se k navrhovaným řešením a vypracuje vlastní návrh řešení daného problému, včetně vyčíslení předpokládané náročnosti různých možností řešení a předloží jej k obecné diskusi, které se zúčastní. V průběhu této diskuse bude ragovat na připomínky zadavatele.
  • Odměna: Jednorázová odměna 15.000,- Kč.
  • Řešení: uzavření písemné smlouvy o dílo
  • Přepokládaný termín:
    • 2 měsíce na analýzu problému
    • 2 měsíce na následnou diskusi
  • Jak se pozná, že byla tato část projektu úspěšná: Na základě vypracované a schválené analýzy bude možno přistoupit k implementaci pilotního projektu a bude možno odhadnout i náročnost praktického řešení (velikost výsledného kódu, počet člověkohodin zkušeného programátora)

Implementace

[editovat]
  • Název: Implementace uživatelských databázi na Wikiverzitě
  • Priorita: 2
  • Požadavky na zpracovatele: Znalost MW, XML a problematiky databází, praxe v programování v PHP a botů
  • Zadání: Podle výsledku předchozí analýzy bude implementován pilotní projekt, na kterém se ověří praktická funkčnost navrhovaného řešení
  • Sazba: 150,- Kč/hod
  • Řešení: uzavření písemné smlouvy o dílo
  • Jak se pozná, že byl projekt úspěšný: Software na úrovni alfa či beta testu, schopný dalšího perspektivního vývoje

--> nezahrnuto do rozpočtu.--Juandev 3. 4. 2009, 13:56 (UTC)[odpovědět]

Citováno z „https://cs.wikiversity.org/w/index.php?title=Wikiverzita:Technické_potřeby/G&oldid=62125“