Nativní XML databáze – nástin teorie

20. února 2003

•

Dostatečně hlasitý příchod XML standardu mezi nás nechal jen málokoho na pochybách, že se budeme v budoucnu s tímto standardem setkávat stále častěji. Ve svém článku nebudu opakovat slova chvály nebo se zabývat spletitostmi syntaxe tohoto jazyka, ale zaměřím se na možné způsoby uchovávání XML dokumentů a dat v nich obsažených.

Před návrhem vhodného způsobu uchování XML dokumentů bychom si měli nejprve ujasnit, jaký hlavní účel pro nás bude plnit nasazení XML jazyka v dané aplikaci. Současné nasazení XML v aplikacích se odehrává převážně ve dvou rovinách:

zaměřené na data (data based)
zaměřené na dokument (document based)

Žádný ze zmíněných směrů nemá samozřejmě naprosto pevné mantinely, ale vždy bychom měli být schopni určit, který z nich převažuje. Bude to pro nás vodítkem, které nám pomůže determinovat typ vhodného datového úložiště.

„Data based“ XML dokumenty

Tímto pojmenováním můžeme označovat XML dokumenty, které plní funkci samopopisné obálky pro přenos či manipulaci s daty. Samotná struktura dokumentu je vedlejší, protože hlavním cílem je „vydolovat“ data a zcela jednoznačně pochopit relace mezi nimi. Jedním z typických příkladů tohoto pojetí je bezesporu využívání XML při přenosu tabulek bez ztráty informace o vzájemných relacích.

„Document based“ XML dokumenty

U této varianty nasazení využíváme především možnosti sémantického strukturování tímto způsobem napsaného dokumentu. XML nám v tomto případě pomáhá pracovat s dílčími částmi dokumentu podle jejich významu. DocBook či DITA schémata jsou praktickou ukázkou tohoto směru.

Datová úložiště pro „data based“ XML dokumenty

Jelikož data jsou u tohoto směru to hlavní, co nás zajímá, nebude se ani v otázce datového úložiště jednat o žádný převrat. Relační databáze zůstávají prozatím nejvhodnější variantou. Na tomto místě nás budou zajímat nástroje, které nám pomohou při zacházení s „data based“ dokumentem. Většina komerčních relačních databázi se již může v dnešní době pyšnit nálepkou „XML enabled“, což znamená, že zpracování dat v XML podobě jim již žádný problém nedělá. Případy, kdy datové úložiště není ještě zcela vybaveno XML podporou, uvolňují prostor pro komponenty (mezičlánky), které můžeme použít pro zpracování XML dat. V nejužším slova smyslu jsou asi nejznámějším zástupcem ADO.NET komponenty.

Charakteristickým rysem je skutečnost, že databáze nám data může poskytnout zpět v rozdílně strukturovaném XML dokumentu, než jsme jí poskytly my. S tímto rysem se často setkáme pod pojmem „round-tripping“. Důvodem jsou převodní algoritmy (table based, object based a podobně), které ze své podstaty nejsou schopny předat informace o specifických, pro data nepodstatných elementech.

Nativní XML databáze

Právě existence relativně nového směru vývoje dokumentů, který můžeme spatřovat v rovině „document based“ XML dokumentů, zapříčinil vznik nového typu databázových serverů (Native XML databases). Hlavním úkolem nativních XML databází (dále jen NXD) je uložit XML dokument včetně jeho logické struktury a podoby. Dokument obdržíme zpět přesně v takové podobě, v jaké jsme jej předali databázi, včetně všech poznámek apod.

Princip fyzického ukládání dat je různý. Nativní XML databáze může využívat buď své proprietární řešení nebo využít služeb relační databáze. V současné době nebude neobvyklé, když narazíte na NXD, která bude směřována pouze jako přístupová vrstva, umístěná nad relační databáze. Způsob fyzického ukládání dat ale není podstatný a většina NXD ho před námi bude úspěšně skrývat.

Mnohem podstatnější jsou funkce, které nám NXD přináší. Patří mezi ně například možnost indexování uložených dokumentů pro výrazné zvýšení výkonu a možnost provádění dotazů napříč sadou dokumentů umístěných v takzvané kolekci. Pro lepší představu si můžeme přirovnat jeden XML dokument k jedné řádce v relační databázi a kolekci k jedné tabulce v relační databázi. Nemusíme jít ani příliš daleko a již objevíme rozdíl – v NXD můžeme umístit dokumenty založené na různých XML schématech do jedné kolekce (Schema independent). To nám může přinést zvýšení flexibility, ale ve většině případů to spíše přinese problémy a nekonzistence, proto mohou být kolekce závislé také na XML schématu (Schema dependent).

Dotazovací jazyk

Již jsem zmínil spojení „provádět dotazy“, ale jakým jazykem? Odpověď není zdaleka tak jednoduchá, jak by se mohlo zdát. V současnosti je často využívaným společným jazykem XPath, který se již hojně využívá při XSL transformacích, ale bohužel neimplementuje takové funkce, které by se lépe hodily na skupiny XML dokumentů (agregace…). S vědomím tohoto nedostatku se vyvíjí hned několik lepších variant dotazovacích XML jazyků (XQuery, XQL, viz například XML-QL). Bohužel ještě žádný z nich nemá takovou podporu, abychom ho mohli použít jako odpověď na naši otázku. Nyní je tedy situace taková, že dotazovací jazyk je silně závislý na použité NXD, dokonce některé NXD mohou implementovat vlastní verze dotazovacích jazyků. Mým osobním favoritem je XQuery (XML Query), ale již jsem se zmýlil v životě mnohokrát.

Obecně lze ale říci, že pokud jste zvyklí pracovat s XML dokumentem (DOM, SAX at.), nebude pro vás žádným problémem zvyknout si na práci s jakoukoli NXD.

Možnosti využití nativních XML databází

Osobně jsem si vyzkoušel Tamino Server, což je již dostatečně etablovaný zástupce popisovaných NXD. Mohu opět jen zdůraznit, že zda zvolíte NXD či relační databázi, záleží v první řadě na cílech, které mají vaše XML dokumenty plnit („data based“ či „document based“). Nativní XML databáze jsou tedy „pouze“ dalším příjemným přírůstkem, který rozšiřuje portfolio XML nástrojů a při jeho využívání je potřeba dobře zvážit všechny klady a zápory zvoleného řešení.