XML jako databáze ve Windows prakticky (2)

4. října 2009 v 1:39 | Ing. Oldřich Oplatek |  XML
Další pokračování úvah o využití XML jako databáze ve Windows začnu otázkou z klasického vtipu:
Mám pro vás dvě zprávy: - dobrou a špatnou - kterou chcete slyšet dřív?
- pro optimisty tu dobrou: Program pro práci s XML formátem už funguje celkem obstojně a bude se jmenovat xmlAdminOpl.exe
- pro pesimisty tu špatnou: Program ještě není připraven k obecnému použití jako demonstrační nástroj pro doprovod tohoto textu, takže jej ještě není možné poskytnout případným zájemcům.

- pro optimisty i pesimisty: - Ale den D poskytnutí programu se už blíží a v závěru tohoto dílu se můžete podívat alespoň na několik obrázků s náhledy z tohoto programu.

Teď ale zpět k "vážné" práci. Minule jsem se zmínil, že na Internetu je skutečně řada reálných souborů ve formátu XML. Je jich vlastně neskutečně mnoho, ale jejich obsah není na první pohled zřejmý. Začneme tedy několika soubory, které jsou veřejně k dispozici na Internetu, mají v názvu příponu .xml, a tedy si je můžete prohlédnout a posoudit, zda jste moudří z jejich zobrazení v internetovém prohlížeči.

Klasickým příkladem databázové struktury v XML je nabídka titulů nakladatelství BEN na adrese BEN-ceník, resp. přímo souboru XML na adrese BEN-cenik-XML.

Poněkud složitější soubor s velmi dobře navrženou strukturou, která využívá vlastností XML, poskytuje Státní opera v Praze. Jedná se o program všech představení na měsíc s uvedením všech důležitých základních údajů, včetně postav, interpretů a odkazů na další podrobnosti o interpretech. Převod těchto dat do klasické databáze by už nebyl elementární záležitostí, protože každé představení má různý počet postav, takže základní datové schema není fixní, čili pevně dané, jako tomu bývá u evidence položek typu "zboží". Zajímavý a velmi dobře napsaný je i úvod na adrese XML exporty. Program představení na měsíc v jazyku XML si zobrazíte na adrese Program pro tento měsíc.

Výše uvedené příklady nejsou asi hned "stravitelné" pro začátečníka, ale poskytují alespoň první přiblížení k praktickému využití XML.

Nyní se vrátíme k našemu příkladu z minulého dílu o evidenci knihovny.

Takže náš kompletní databázový soubor v jazyku XML s knihovnou a s jedinou knihou vypadá takto:


<?xml version="1.0" encoding="windows-1250"?>
<knihovna>
<kniha>
<nazev>Babička</nazev>
<autor>Němcová, Božena</autor>
<cislo>1</cislo>
<umisteni>velký pokoj</umisteni>
</kniha>
</knihovna>


Další knihu přidáme velice snadno zkopírováním bloku mezi tagy <kniha> a </kniha> a změnou
údajů příslušných položek. Po přidání knihy číslo 2 "Na západní frontě klid" autora "E. M. Remarque" bude soubor vypadat následovně (vložený text je kvůli názornosti vyznačen červeně):

<?xml version="1.0" encoding="windows-1250"?>
<knihovna>
<kniha>
<nazev>Babička</nazev>
<autor>Němcová, Božena</autor>
<cislo>1</cislo>
<umisteni>velký pokoj</umisteni>
</kniha>
<kniha>
<nazev>Na západní frontě klid</nazev>
<autor>Remarque, E., M.</autor>
<cislo>2</cislo>
<umisteni>velký pokoj</umisteni>
</kniha>
</knihovna>


V knihovně už tedy máme dvě knihy a stejným způsobem umíme přidat libovolný počet dalších.

Nyní se pokusíme nahlédnout na naše data z pohledu stromové struktury (tree structure), která je vlastní jazyku XML. Protože první řádek deklarace do vlastních dat nepatří (je pouze informací pro procesor zpracovávající XML), představuje až druhý řádek informaci o vstupních datech a je to vlastně hlavní definice našich dat. Ve stromové struktuře je to tzv. kořenový uzel (root node). Veškeré údaje mezi tagy <knihovna> a </knihovna> představují v XML tzv. element. Elementy jsou tedy i údaje mezi vloženými tagy do knihovny, tedy jednotlivé knihy s údaji mezi tagy<kniha> a </kniha>. Každá kniha je tedy elementem, který obsahuje další elementy. Ve stromové struktuře pak kořenový uzel obsahuje další uzly obsahující elementy. Tyto uzly jsou potomky nadřazeného uzlu, tedy "dětmi" (child), resp. dětskými uzly (child node). Každé dítě tak má svého "rodiče" (parent), resp. rodičovský uzel (parent node).
Uzly mají různou povahu. Buď jsou "jednoduché" a obsahují pouze textové elementy nebo jsou "složené" a obsahují další vnořené uzly, které mohou být opět"jednoduché " nebo "složené".

Přidáním jedné knihy navíc se původní velice jednoduchá konstrukce trošičku zkomplikovala.
Proto stromová struktura zavádí ještě další pojem "sourozenec". Knihy už máme v knihovně dvě, takže tu máme dva dětské uzly, čili dvě děti, tedy dva sourozence.

Jak už to v životě bývá, nic není tak jednoduché, jak by se na první pohled zdálo. Knihy jsou obsahově i svojí povahou stejného typu. Přitom nezáleží na tom, zda např. u některé knihy není znám autor. V databázových systémech by byl v položce autor uveden prázdný text, tedy "nic". Z toho by bylo zřejmé, že autor není znám. V našem případě však stačí vynechat tag <autor> a autor prostě nebude. Ale stejně tak můžeme vložit prázdný element mezi tagy <autor></autor> nebo zkráceně jen <autor/>. Aspoň je tak zřejmé, že jsme autora nezapomněli uvést, ale opravdu není znám či není uveden.

Ať je tedy počet vnořených údajů stejný nebo ne, kniha zůstává knihou, ať stará či nová, roztrhaná nebo zachovalá, s názvem nebo bez názvu s autorem či bez autora, prostě - kniha je kniha, i když se údaje mohou maličko lišit. Knihy jsou tedy svou povahou rovnocenné a jsou všechny sourozenci. Ale i v životě se objeví další "prezenti" a to - nevlastní sourozenci. Jedná se tedy v našem případě o sourozence vlastní nebo nevlastní, když například nemají autora? V našem případě jsou to jednoznačně sourozenci vlastní, i když "s trochu jiným DNA". Vlastní sourozenci se označují pojmem kolekce "collection". Proč toto označení zavádět a jak tedy mohou vzniknout nějací nevlastní "bastardi"?

Představme si, že opravdu evidujeme knihovnu, zapisujeme vzorně ve formátu XML a najednou dole na polici objevíme z dětství hromadu "Čtyřlístků", které už asi nikdy nebudeme číst a přesto se s nimi nechceme rozloučit. Co teď? V databázovém systému bychom se asi vrátili zpět k návrhu struktury dat a přidali do tabulky knihovna ještě novou položku"druh" a do ní bychom zapisovali údaj "kniha" nebo "časopis" - a je zameteno a všechno je jasné, až na to, že se musí stávající databáze přetransformovat do nové struktury.

V XML můžeme udělat samozřejmě totéž a vložit do elementu "kniha" další element "druh". Zase bude trochu matoucí, že řada záznamů, označených jako kniha, bude obsahovat element se jménem uzlu "druh" do kterého budeme zapisovat údaj "kniha". Takže v knize bude "kniha" - nic hrozného, vše je v pořádku, jen je to trochu matoucí. Můžeme "kniha" přejmenovat na "položka" a už je vše bezpochyby zřejmé, tak jak to ostatně je ve většině praktických příkladů, kde se opakovaně objevují označení "položka" či angl. "item".

V XML však máme v takovém případě ještě další možnost.
Všechnu svou dosavadní evidenci ponecháme beze změny a místo elementu (záznamu) <kniha> vložíme element <casopis> se stejnou strukturou. A můžeme klidně pokračovat bez jakýchkoliv zásahů do dřívějších záznamů. Přitom stejná struktura není podmínkou, ale je třeba také vzít v úvahu následné zpracování, takže použití stejné struktury je vhodné.
Protože <kniha> a <casopis > mají stejného rodiče, ale nenesou stejné označení, máme tu najednou ty "bastardy", tedy nevlastní sourozence angl. "sibling". Kdo je vlastní či nevlastní, to je lhostejné - vznikla jakási nehomogenní množina potomků.
Potom množina knih a množina časopisů představují samostatné kolekce "collection".
V programovacích jazycích existují nástroje, které umožňují procházet v jednom cyklu všemi nevlastními sourozenci, takže v našem případě je možné společně zpracovávat knihy i časopisy.

Já osobně jsem poplatný klasickým databázovým systémům, a asi bych tento způsob nevolil a skutečně zůstal u položek v knihovně s rozlišením jejich druhu. Vše mi tak připadá jasnější bez vzniku vyjímek, pokud je to možné. Někdy se však uvedenému postupu nevyhneme a naopak je ho možné s výhodou využít.

Naše databáze by tedy mohla vypadat třeba takto (vložený text je kvůli názornosti vyznačen modře):

<?xml version="1.0" encoding="windows-1250"?>
<knihovna>
<kniha>
<nazev>Babička</nazev>
<autor>Němcová, Božena</autor>
<cislo>1</cislo>
<umisteni>velký pokoj</umisteni>
</kniha>
<kniha>
<nazev>Na západní frontě klid</nazev>
<autor>Remarque, E., M.</autor>
<cislo>2</cislo>
<umisteni>velký pokoj</umisteni>
</kniha>
<casopis>
<nazev>Čtyřlístek 1988</nazev>
<autor>neuveden</autor>
<cislo>3</cislo>
<umisteni>velký pokoj</umisteni>
</casopis>
</knihovna>

Máme tedy XML databázi knihovny se dvěma knihami a jedním časopisem. Přitom je třeba upozornit na to, že značkovací jazyk XML byl vytvořen zejména pro oblast zpracování dokumentů, o kterých často není předem nic známo. Všimněte si, že jsme se vůbec nezatěžovali definováním typu položek, jejich přípustných rozsahů a ani nevíme, co je číslo nebo není číslo, co se dá sečítat, co ne, co obsahuje věcné chyby - prostě nic. Vše ostatní závisí na dalším zpracování. Ale záznamy máme pěkně pohromadě a pokud bude úplně jiný počítačový systém schopen přečíst např. naše kódování češtiny, můžeme se souborem směle přejít jinam, a tam ho přečíst také.
Právě tak můžeme svá data poslat jinému uživateli, třeba Vonáskovi, vyzbrojenému nástroji pro práci s XML, přinejmenším prohlížečem, a ten s přehledem zjistí, kdože mu vlastně jeho chybějící knihu nevrátil...

V předchozím textu jsem se zmínil o tom, že k XML neodmyslitelně patří stromová struktura z matematické teorie grafů. A také jsem uvedl, že nemám stromovou strukturu rád. Nepřipadá mi jako přehledný a všeobecně srozumitelný prostředek pro běžného uživatele, který chce vědět, kolik vydělal, kolik utratil a kolik mu zbývá na dovolenou. To vše ve stromové struktuře by bylo poněkud neobvyklé, pokud nepoužiji přímo odborného termínu "praštěné".
Žádné noviny, ani časopis, ani televizní program Vám nikdo nepodstrčí jako strom. Zůstávají pořád jen ty rodokmeny...

XML však má strom jako základní vyjadřovací prostředek. Proto vznikají pomocné nástroje, které mají v názvu angl. slovo "path", tedy "cesta". Pro pohyb a hledání v datech je třeba hledat a uchovávat "pěšinky" od kořene k nejvyšším větvím, aby se našlo, co je třeba. Tomu se prostě nedá vyhnout. Hledat v souboru XML záznam, jehož umístění je odvozeno od pořadí uložení, je prostě v tomto případě nemyslitelné, ba přímo zcestné.

Pokusil jsem se ve svém novém programu xmlAdminOPL poskytnout zájemcům prostředek pro práci se soubory XML, ale netradičním způsobem zobrazování stromové struktury, a to formou tabulek. Není to univerzální nástroj, ale kupodivu splňuje řadu požadavků, které jsem si určil v 1. díle tohoto textu. Tedy hlavním účelem je ukládání nepříliš rozsáhlých dat v programech, pracujících pod Windows.

xmlAdminOPL je nástroj, který především umožní vytvoření databáze a její naplnění. Samozřejmě následné zpracování takto připravených dat závisí na dalších návazných programech.

Program bude v Trial (zkušební) verzi zdarma a můžete si o něj napsat, zašlu Vám ho emailem. Chtěl bych mít představu o zájemcích a jejich názorech, proto prozatím není přímo ke stažení na Internetu.
Trial verze programu umí vše upravovat, opravovat i rušit, ale neumí nic uložit. Ani vstupní soubor nelze zadat libovolně, pouze lze vybrat z nabídky souborů XML na mém serveru. Počet těchto ukázkových souborů se bude rozšiřovat. Máte tak možnost dostat do rukou "nástroj ke hraní" a seznámení s možnostmi XML i vlastního programu. Nemusíte žádná data zadávat ručně, ale můžete si je stáhnout ze serveru a pak je v klidu a pohodě "ničit". Obsah i strukturu ukázkových souborů se budu snažit popsat v následujících kapitolách.

Prozatím skončím odkazy na několik sejmutých obrazovek programu s naší knihovnou a to bez dalšího komentáře.







 

1 člověk ohodnotil tento článek.

Nový komentář

Přihlásit se
  Ještě nemáte vlastní web? Můžete si jej zdarma založit na Blog.cz.
 

Aktuální články

Reklama