XML databáze: současný stav a perspektivy

Transkript

1 Jaroslav POKORNÝ Katedra softwarového inženýrství, MFF UK Praha Malostranské nám. 25, Praha Abstrakt. Vývoj v komerční sféře ukazuje, že existuje potřeba ukládat XML data databázovým způsobem. Cílem příspěvku je ukázat možnosti použití XML jako nového databázového modelu. Jsou ukázány současné možnosti vývoje XML databází. V první jsou XML data ukládána v (objektově) relační databázi jako texty nebo pomocí speciálních uživatelem definovaných datových typů, nebo jsou dekomponována do více tabulek. Přirozenější řešení poskytují tzv. nativní XML databáze s vlastní fyzickou implementací XML dat. K XML datům se přistupuje pomocí speciálních dotazovacích jazyků, jako jsou XPath nebo XQuery. Pro praxi je však užitečné i přibližné vyhledávání, podobně jak je tomu v dokumentografických informačních systémech. Možnost integrace XML dat s daty v tabulkách nabízí vyvíjená varianta jazyka SQL pro XML (SQL/XML). Jazyky jsou ukázány na příkladech, zmíněna je jejich vyjadřovací síla. Poslední část příspěvku je věnována některým produktům pro XML databáze. Klíčová slova: XML databáze, model XML dat, XPath, XQuery, databáze zpřístupňující XML data, nativní XML databáze. 1 Úvod Jako většina výsledků v informatice i vznik XML databází má ryze praktické důvody. Některé aplikace, např. webová místa pro B2C a B2B, webové služby, aplikace využívající řízení obsahu, jakož i integrace dat a aplikací, vyžadují ukládání XML dat perzistentním způsobem [1], [9]. Databázová správa XML dat umožňuje sofistikovanější přístup k nim, a to nejen pro dotazování, ale i pro jejich aktualizaci. Bez databázové podpory jsou vývojáři nuceni pro ukládání XML dat využívat souborové systémy, případně je reprezentovat nestrukturovaně jako znakové objekty, což ztěžuje tvorbu aplikací. Jaké jsou technické možnosti ukládání a manipulace XML dat? Známí výrobci (objektově) relačních systémů řízení databází (SŘBD) ukládají XML data do tabulek (pro přehled viz např. [8]). Tato technika může být přínosná např. když XML data pocházejí z relační databáze, nicméně v širším pohledu jde o směr, který nelze použít pro všechny typy úloh. Protože se jedná o navzájem odlišná proprietární řešení, nelze tyto SŘBD jednouše použít pro úlohy vyžadující pracovat současně s databázemi od různých výrobců. Také vyhledávání v takových databázích může být v mnoha případech neefektivní. Indexy relačních databází totiž nejsou pro použití na obecných Karel Ježek (ed.), DATAKON 2004, Brno, , pp

2 stromových strukturách XML dat vhodné. Aby bylo možné efektivně vyhodnotit určité dotazy, je nutné sledovat navigaci ve stromové struktuře XML dat, umožnit realizaci vztahů mezi uzly XML stromu, jako jsou rodič-dítě či předchůdce-následník a další. Tyto problémy se snaží řešit tzv. nativní XML databáze, které ne nutně závisí na použití (objektově) relačních datových struktur. Již dnes pro ně existuje řada praktických uplatnění v informačních portálech, v realizaci katalogů zboží, správě záznamů o pacientech apod. V ukládaní XML dat do databáze tedy existují dvě základní architektury: databáze zpřístupňující XML data a nativní XML databáze. Nahlédneme-li do seznamu, který udržuje na svých webových stránkách R. Bourret [2], zjistíme, že existuje alespoň 16 komerčních produktů prvního druhu a 36 produktů druhého druhu. XML data lze do databází ukládat s respektováním jejich schématu, ale i bez něj. Připomeňme, že roli databázového schématu zde hraje popis XML dat pomocí DTD anebo v poslední době pomocí více propagovaného jazyka XML Schema. Poněkud nešťastně zvolený název jazyka 1 vede k tomu, že se schéma v něm vytvořené nazývá XML Schema dokument nebo XML Schema definice. V obou případech lze použít zkratku XSD. Jako dotazovací jazyk se prosazují XPath [12] a XQuery [13]. První z nich hraje významnou roli pro současné XML databáze, druhý bezpochyby pro XML databáze budoucí. Dalším jazykem je SQL/XML definovaný v části standardu SQL:2003 [6]. Cílem článku je ukázat současné technologické možnosti ukládání a manipulace XML dat v databázovém přístupu. Ukážeme, jak ukládat XML data do databáze a jak se k novému trendu staví současné standardy. Ze standardů jsou důležitá zejména doporučení konsorcia W3C, zvláště pak jeho pracovní skupiny XML Query WG, a aktivity týmů rozvíjejících pod ISO a ANSI relační jazyk SQL. Další významnou průmyslovou iniciativou je XML:DB 2, která se zabývá hlavně návrhem API k XML databázím. Významný je i její návrh neprocedurálního jazyka XUpdate pro aktualizaci XML dat. V kapitole 2 popíšeme dva základní typy XML dat a jejich vztah k architektuře XML databáze, zvláště pak k okruhu aplikací, pro něž má být použita. Diskutují se zde blíže dvě základní architektury XML databází. Kapitola 3 pojednává o (objektově) relačních databázích zpřístupňujících XML data. Zmíněny jsou také problémy zobrazení XML dat do relací a naopak. Dotazování nad XML daty je diskutováno v kapitole 4. Kapitola 5 pojednává o komerčních databázích podporujících XML data. V závěrečné kapitole 6 se zmíníme o některých dalších možnostech, ke kterým směřuje budoucí vývoj. Článek je rozšířenou verzí práce [10]. Pro hlubší pohled na problematiku XML databází lze doporučit stále aktualizovanou práci R. Bourreta [1]. Dobrý úvod do problematiky poskytuje kniha [3]. 2 Typy XML dat a správa XML dat Jazyk XML je používán pro značkování dat minimálně dvojího druhu. V prvním reprezentují XML data semistrukturovaná data, tj. data mají nepravidelnou strukturu 1 Jazyk XML Schema se též neformálně nazývá schéma pro schémata. 2

3 Zvaná přednáška a požadují uspořádání elementů. Cílem zde je podchytit logickou strukturu dokumentů. Další variantou jsou XML data, která obsahují data pravidelně strukturovaná, o nichž se předpokládá, že budou spíše zpracovávána strojově než dotazována člověkem. Typicky může jít o data z relační databáze, která jsou transportována v B2B úlohách. Praxe rozlišila oba typy XML dat na dokumentově orientovaná (angl. document-oriented nebo document-centric) a datově orientovaná (angl. data-oriented nebo data-centric). XML data lze také pojmout jako text. Pak lze použít prostředky pro práci s textovými daty umožňující indexaci, vyhledávání podle klíčových slov apod. 2.1 Model XML dat Jak pro ukládání tak pro dotazování XML dat je vhodné zavést pojem modelu XML dat. V prvním případě můžeme lépe operovat s tím, co vlastně ukládáme, ve druhém případě nám model XML dat dává šanci popsat smysluplně sémantiku dotazovacího jazyka na XML daty. Většinou jde o nějakou formu stromu, kde lze rozlišit nejméně mezi uzly - atributy a uzly - elementy. Uzlům v modelu může být přiřazen OID. Jednoduchým modelem je např. objektový model, který lze získat na základě API DOM (Document Object Model) 3. V tomto API je specifikována logická struktura dokumentu, tj. jaké jsou typy uzlů objektů spolu s jejich vlastnostmi a jaký typ uzlu může být po daný typ uzlu následníkem. Odpovídající vlastnosti umožňují k uzlům přistupovat a realizovat tak např. průchod stromem. Příklad XML dat a jejich modelu (à la DOM) ukazují obrázky 1 a 2. <biblio> <zpráva> <autor>w3c</autor> <název> XHTML</název> <číslo>info320</číslo> </zpráva> <článek > <název> Lehký úvod do XML </název> autor W3C <autor národnost= CZ > Jiří Kosek </autor> <zdroj>slt 2001</zdroj> </článek> </biblio> Obr. 1: Fragment XML dokumentu název zpráva INFO32 XHTML biblio článek číslo název autor zdroj Lehký úvod do XML Jiří Kosek Obr. 2: Model XML dokumentu SLT 2001 národnost= CZ Pokročilejší modely jsou grafové. Umožňují vyjádřit vztahy dané atributy typu ID/IDREF(S). Mezi modely XML dat lze zařadit i Infoset 4 (XML Information Set) poskytující množinu informačních prvků pro každý dobře sestavený XML dokument

4 2.2 Datově orientovaná XML data Datově orientovaná XML lze jednoduše ukládat do (objektově) relační databáze. Důležitá je i jejich jemná "zrnitost", tj. nejmenší jednotky dat se nacházejí na úrovni hodnot typu PCDATA a atributů. Pořadí sourozeneckých elementů nebývá podstatné. Často se v této souvislosti uvádí i možnost generovat XML data z ne-xml databáze. V praxi se setkáváme se systémy, které zahrnují obě možnosti. Mezi příklady datově orientovaných XML dat můžeme uvést informace z telefonního seznamu, rozvrh odletů letadel, data zákaznických smluv, ale i např. zprávy v protokolu SOAP. Datově orientovaná XML data tedy často vznikají v aplikacích. Není tedy nutné pro ně nasazovat specializované XML prostředky. Vystačí se i se softwarem, který ukládá XML data jako text buď v souborovém systému nebo jako údaje typu BLOB (Binary Large OBject) 5 v relační databázi. Pro extrakci XML dat lze použít nějaký middleware nebo komponentu, která formátuje do XML odpověď získanou pomocí jazyka SQL. Tato funkčnost je dnes základem koncepce SQL/XML. Je dále možné integrovat data poskytnutá z XML i ne-xml zdrojů (např. ADO+ firmy Micorsoft) či provádět konverzi relačních dat daných SQL dotazem do XML (např. DatabaseDom firmy IBM). Více databázový přístup poskytují databáze zpřístupňující XML (angl. XML-enabled databases), které dokáží konvertovat XML data do tabulek a naopak (viz kapitola 3). 2.3 Dokumentově orientovaná XML data Mezi příklady dokumentově orientovaných XML dat můžeme zahrnout záznamy o vyšetřeních pacienta, webová místa jako je stránka Amazon.com, ale i data ve formátu XHTML (následník protokolu HTML). Data mohou být co se týče struktury velmi nepravidelná. Např. záznamy pacientů mohou obsahovat vždy odlišné druhy vyšetření, nasazení léků apod. Dokumentově orientovaná XML data vznikají ručně značkováním nebo z nějakého jiného formátu (RTF, PDF či SGML), obsahují smíšený obsah (střídaní textu a vnořených elementů) a obvykle v nich záleží na pořadí elementů v posloupnosti. Mezi datově orientovanými a dokumentově orientovanými XML daty je však někdy hranice nezřetelná. Např. XML data webové stránky si můžeme představit jako několik vyplněných šablon (datově orientované) doplněných XSL tabulkami stylů. Dokumentově orientovaná XML data je výhodné ukládat pomocí speciálního software, který se nazývá nativní XML databáze. Tyto databáze mohou ukládat XML data také jako texty, nicméně častějším přístupem je použít vlastní proprietární fyzický datový model, který míří za možnosti známých API jako jsou již zmíněný DOM či SAX (Simple API for XML) 6 nebo JAXB (Java Architectural Binding for XML firmy Sun). Nativní XML databáze umožňují mimo jiné zobrazit XML data do diskových stránek a indexaci, která podporuje vyhodnocení dotazů v XML dotazovacích jazycích. 5 V SQL:2003 je CLOB podtypem CHAR. CHAR a BLOB jsou podtypy STRING. 6

5 Zvaná přednáška 2.4 Typy databázových architektur pro XML data Možné postupy pro realizaci XML databáze jsou dva: přizpůsobit databázový stroj XML strukturám a příslušným dotazovacím jazykům (databáze zpřístupňující XML) nebo vybudovat speciální implementaci databázového stroje (nativní XML databáze). Pro uložení XML dat do databáze hraje v prvním případě roli cílový databázový model, který je většinou relační nebo objektově relační, tak jak jej známe ze standardu SQL:2003 a jeho verzí implementovaných výrobci objektově relačních SŘBD. Jakkoliv je tento přístup kritizován, má jednu nespornou výhodu. Umožňuje totiž zpracovávat XML data společně s relačními daty. Jinou, spíše méně využitou možností, je použít objektově orientovanou databázi. Reprezentace XML dat ovšem není jediným problémem, který je v popředí zájmu tvůrců XML databází. Hned další, možná ještě důležitější problém je dotazování XML dat. Uvažujme kolekci XML dokumentů. Nejde pouze o to vybrat z ní dokumenty vyhovující daným podmínkám. Často jsou vyžadovány pouze části XML stromu, případně je třeba zkonstruovat nová XML data z těch, která jsou v kolekci. Připomeňme, že tato funkčnost se v relačních databázích pomocí jazyka SQL realizovala mnohem jednodušeji. Výstupem totiž byla vždy tabulka. Dalším požadavkem může být aktualizace XML dat v databázi. Rigidnost databázového schématu znemožňuje složitější aktualizace XML dat. Připomeňme zde jazyk XUpdate, který však zatím nemá mnoho implementací. Jiným obtížným problémem je zajištění efektivního uzamykacího mechanismu pro souběžné použití XML databáze více uživateli. Je-li XML dokument dekomponován do více tabulek, je uzamykaní řádků ve více tabulkách značně nepružné. 3 (Objektově) relační SŘBD zpřístupňující XML Ve vývoji databází zpřístupňujících XML data jsou patrné dva základní přístupy: rozšiřující moduly (objektově) relačního SŘBD (např. cartridge v ORACLE, extender v DB2, datablade v INFORMIX), rozšířený jazyk SQL (SQL/XML). Co se týče druhé možnosti, jazykové prostředky se v proprietárních řešeních daných výrobců od SQL/XML často liší. Pro uložení XML dat využívají hlavní výrobci podpory XML v (objektově) relačních databázích některé z následujících technik (zobrazení) [7]: nestrukturovaně, kdy je umožněno ukládat celý XML soubor v jedné komponentě řádku tabulky 7, rozkládání XML dokumentu (shredding) 8, při kterém jsou XML data dekomponována do řádků a sloupců více tabulek. Zobrazení může být implicitní nebo definované uživatelem. 7 V terminologii XML Extenderu v DB2 se tento způsob označuje jako XML Column. 8 V terminologii XML Extenderu v DB2 se tento způsob označuje jako XML Collection.

6 strukturovaně (nativně), kdy jsou zachovány hierarchie XML dat, umožněna je jejich kombinace s relačními daty. Nestrukturované ukládání je zobrazení vhodné pro data, která nejsou často měněna, je však požadováno, aby jejich reprezentace umožňovala přesně rekonstruovat originál. Jde o tzv. round-tripping problém. Zde budeme hovořit o reverzibilitě zobrazení. Z původních XML dat by neměly být ztraceny mezery, pořadí elementů, což je vyžadováno např. u dokumentů závislých na elektronickém podpisu či obsahujících lékařská nebo právnická data. Vyhledávání, založené obvykle na nějakém fulltextovém nástroji, lze urychlit indexací. Problémem je ovšem aktualizace takových dat. V nejhorším případě to znamená zkonstruovat k XML textu model (např. DOM), provést na něm změny a znovu vytvořit XML text. Dekompozice XML dat do tabulek je vhodná pro data, která jsou často měněna a tato změna musí být provedena rychle. Reverzibilita dekompozice zde není základním požadavkem. Je zřejmé, že nejpokročilejší je strukturované ukládání. Pro dodavatele relačních databází podporující XML je významným cílem. Způsob, jakým je v konkrétních případech zajištěno, může být ale dost zvláštní. Např. se udržuje přímo XML dokument spolu s tabulkami popisujícími jeho strukturu. Nad těmito tabulkami může být vytvořen ještě index, např. klasický B-strom. Jakkoliv se zdá daná klasifikace přirozená, není příliš přesná. Je třeba rozlišovat logickou úroveň, fyzickou úroveň a zobrazení mezi nimi. Např. (objektově) relační SŘBD využívají i pro strukturované ukládání tabulky, ze kterých lze rekonstruovat jak hierarchie, tak uspořádání elementů v sekvenci. Důležité je, co vše je z původního XML dokumentu pro výstup z databáze garantováno. Pak je výhodnější uvažovat model XML dat (např. DOM nebo InfoSet). Garantovat takový model znamená, že je tentýž jak pro původní dokument, tak pro ten rekonstruovaný z databáze. Z praktických důvodů jsou v daném SŘBD uvedené techniky obvykle k dispozici všechny. Je možné je použít v závislosti na druhu aplikace. 3.1 Zobrazení XML dat do (objektově) relační databáze V nejjednodušším případě lze XML data uložit jako hodnotu typu VARCHAR nebo CLOB. Tento způsob samozřejmě zachovává vše, co původní XML dokument obsahuje. Strukturální transformace XML dat může být prováděna bez znalosti jejich popisu pomocí DTD nebo XSD nebo na základě znalosti tohoto popisu. Hovoříme pak o generických metodách resp. metodách řízených schématem. Generické metody využívají několik tabulek pro uložení XML dat bez ohledu na jejich strukturu. Přímočará je transformace zvaná tabulkové zobrazení pro datově orientovaná XML data. Tato data obsahují element <database>, který obsahuje elementy <table> skládající se z elementů <row> a jejich elementů <column>. Podle SQL/XML se generické značky table a column v praxi nahrazují odpovídajícím jménem tabulky a jménem sloupce. Naopak, jednoduché elementy (typu PCDATA) a/nebo atributy se mapují na sloupce tabulek. Určení jmen sloupců závisí na použitém software. Je zřejmé, že tento jednoduchý způsob je vhodný tam, kde se pomocí XML pracuje s daty z relační databáze.

7 Zvaná přednáška Známým představitelem metod řízených schématem je zobrazení v [1] nazývané (poněkud nevhodně) objektově relační. Typy elementů se mapují na třídy a ty následně do relačního nebo objektově relačního modelu dat. Třídy jako prostředník samozřejmě nejsou nutné. Vztahy mezi tabulkami (referenční integrita) jsou založeny na umělých klíčích (odpovídají OID objektů objektového modelu), které je nutné při plnění tabulek databáze generovat. Existuje-li vhodný XML atribut, je možné jej použít také jako primární klíč. Pro reversibilní proces ovšem nemusí být vždy rozlišitelné, co klíčům a cizím klíčům z tabulek odpovídá, tj. zdali jde o umělý nebo přirozený klíč. Umělý klíč by se měl vlastně ignorovat. Obrázek 3 ukazuje jednoduchou situaci s přirozeným primárním klíčem. <objednávka> <číslo_o>4711</číslo_o> <zákazník>mff UK</zákazník> <datum> </datum> <řádek číslo_ř="1"> <zboží>a10</zboží> <počet_kusů>12</počet_kusů> <cena>1090</cena> </řádek> <řádek číslo_ř="2"> <zboží>b43</zboží> <počet_kusů>600</počet_kusů> <cena>400</cena> </řádek> </objednávka> Objednávky číslo_o zákazník datum 4711 MFF UK Řádky číslo_o číslo_ř zboží počet_kusů cena A B Obr. 3: XML data a jejich vyjádření pomocí tabulek Na obrázku 4 je ukázána transformace DTD s opakujícím se podelementem. Atribut číslo-k je umělým primárním klíčem v tabulce Knihy a cizím klíčem v tabulce Autoři. Speciálním problémem je zachování uspořádání. Připomeňme, že v tabulkách nehraje uspořádání řádků ani sloupců roli. To potom vede, např. u opakujících se podelementů, k nutnosti zavést speciální atribut, který čísluje reprezentace podelementů. S příchodem objektově relačních databází se zmíněné postupy dají implementovat jednodušeji pomocí vnořených polí či tabulek nebo dalších typů kolekcí. Ve standardu SQL/XML k tomu v současné době slouží konstruktory Array a Multiset. Zdůrazněme že uvedená zobrazení nejsou reverzibilní. Problémy mohou vzniknout s již zmíněnými umělými klíči. Objektově relační zobrazení je realizováno u řady výrobců SŘBD zpřístupňujících XML. Pouze ORACLE však využívá XSD.

8 Uvedené postupy se nehodí pro dokumentově orientovaná XML data. Jedním z důvodů např. je, že neumožňují jednoduše realizovat smíšený obsah. Pro podrobný přehled diskutovaných metod a řady dalších je dostupná výzkumná zpráva [8]. Dotazovací jazyky, které se používají nad daty v databázích zpřístupňujících XML data, jsou jednak založeny na šablonách, jednak odrážejí vývoj jazyka XML/SQL. Další možností je využít SQL přímo na vygenerovaných strukturách (objektově) relační databáze. Přínosná je i možnost použít nástroj pro zpracování textu v případě, že jsou XML data uložena v řádku tabulky jako text daného sloupce. <!ELEMENT kniha (autor*, název, ISBN)> <!ELEMENT autor (#PCDATA)> <!ELEMENT název (#PCDATA)> <!ELEMENT ISBN (#PCDATA)> Knihy Autoři autor číslo-k číslo-k název ISBN Obr. 4: DTD a jeho vyjádření pomocí schématu relační databáze 3.2 Zobrazení (objektově) relačních dat do XML Konverzi RMD XML chápejme spíše jako SQL XML, tj. vychází se z transformace toho, co nabízí současná verze standardu SQL. Např. pro data daná definicemi CREATE TABLE Řádky_obj( Číslo CHAR(6) Zboží TypZboží); // typ atributu zboží je definován // uživatelem CREATE TYPE TypZboží( název VARCHAR(100) počet_kusů INTEGER); má korespondující XML dokument element zboží s podelementy název a počet_kusů. 4 Dotazování nad XML daty V sekci 4.1 popíšeme některé charakteristiky dotazování nad XML daty, které ovlivnily vývoj odpovídajících dotazovacích jazyků. Z dotazovacích jazyků pro XML data zmíníme v sekcích 4.2 a 4.3 základy XPath a XQuery. V sekci 4.4 jsou zmíněny základní rysy jazyka SQL/XML. Sekce 4.5 je věnována problémům efektivního vyhodnocení XML dotazů. V sekci 4.6 krátce diskutujeme nepřesné dotazování, které vychází z principů dokumentografických informačních systémů (DIS).

9 Zvaná přednáška 4.1 Základní rysy dotazovacích jazyků nad XML daty Klíčovým konstruktem, který se vyskytuje v XML dotazovacích jazycích je cesta. Pro proměnnou x a značku l má krok po cestě tvar x/l y a označuje, že proměnná y má za obor hodnot uzly (elementy) l, které je následníky uzlu v x. Vyhodnocením kroku po cestě tedy obdržíme obecně množinu uzlů (resp. jejich OID) nebo podstromů odpovídajících těmto uzlů. Obsahuje-li x atomický objekt, nebo l není následníkem uzlu z x, je výsledkem prázdná množina. Cesta je seznam kroků po cestě. Cesty lze zadávat obecně pomocí regulárních výrazů určujících cestu. Např. biblio/(zpráva článek), autor/křestní_jméno?, zpráva/reference+ umožňují po řadě realizovat větvení, částečnou informaci a vícenásobnou referenci. Značení R+, kde R je regulární výraz určující cestu, je zkratkou za R/R *. Kleeneho uzávěr *, tj. R*, znamená 0 nebo několik opakování R. Používané symboly jsou shrnuty na obrázku 4. Jazyky XPath a XQuery nepodporují v plném rozsahu regulární výrazy určující cestu. Např. Kleeneho uzávěr se musí simulovat. symbol funkce symbolu - jakýkoliv jednotlivý uzel / separátor mezi uzly na cestě sjednocení uzlů? 0-1 výskyt uzlu + 1-více výskytů uzlu * 0-více výskytů uzlu [] uzavírá logickou označuje atribut ( ) indikují precedenci Obr. 4: Symboly regulárních výrazů 4.2 Jazyk XPath XPath umožňuje vyjádřit lokalizaci různých fragmentů XML dokumentu velmi kompaktním a složitým způsobem. K tomu slouží jisté relace zvané osy, které k danému uzlu u v XML stromu S přiřazují specifikovanou množinu uzlů. Mezi nejdůležitější patří: ancestor (předci) uzly ležící na cestě od u do kořenu, ancestor-or-self (předci včetně mne) u a uzly ležící na cestě od u do kořenu, parent (rodič) první uzel ležící na cestě od u do kořenu, child (děti) bezprostřední následníci uzlu u, descendent (potomci) všechny uzly, pro které je uzel u předkem, preceding-siblings (předcházející sourozenci) sourozenci uzlu u předcházející u při průchodu S do hloubky, following-siblings (následující sourozenci) sourozenci uzlu u následující u při průchodu S do hloubky,

10 preceding (předchůdci) uzly předcházející u (kromě jeho předků) při průchodu S do hloubky, following (následníci) uzly následující po u (kromě jeho potomků) při průchodu S do hloubky. Tyto relace se ve speciální i zkrácené notaci také používají při formulaci cest ve výrazech jazyka XQuery. Díky významu cest pro dotazování bylo věnováno mnoho úsilí (jak ve výzkumu, tak v praktických implementacích) problému jejich efektivního vyhodnocení. Teoreticky je dobře prozkoumána třída dotazů založených na jednoduchých cestách. Dotaz jednoduchá cesta je založen pouze na relaci předek-následník. Nechť dokumenty v biblio jsou strukturovány do hloubky včetně obrázků. Příkladem jednoduché cesty je dotaz D1: biblio//obrázek Hledají se všechny obrázky ve všech dokumentech. Znak * v XPath slouží jako zástupný znak. Dotaz D1 : biblio/*/obrázek slouží pro hledání obrázků přesně ve druhé úrovni za výchozí úrovní kořenového elementu biblio. Výraz dotazu v XML dotazovacích jazycích obsahuje specifikace vzoru i zadání tvaru výsledku. Pro jednoduchou cestu je tvar výstupu velmi jednoduchý. Ve srovnání s relačními jazyky je možné i v XPath nalézt výrazy odpovídající jisté selekci a projekci. Pro vyjádření logických podmínek lze do zadání cesty zakomponovat pomocí závorek [] tzv. filtry, které omezují výběr elementů či atributů. Na atributy se odkazuje jménem předsazeným Jednoduchou cestou s filtrem je D2: //článek[autor= Jiří Kosek ] určený pro nalezení všech článků, které napsal Jiří Kosek. Dotaz D3: //článek[název = Lehký úvod do XML ]/autor vede k nalezení autorů, kteří napsali článek s názvem Lehký úvod do XML. Selekce //článek[název = Lehký úvod do XML ] vede k vybrání článků s názvem Lehký úvod do XML, pomocí //článek/autor se vybírají autoři článků (výstup). Dotaz D3 je vlastně jistou kombinací dvou cest, přičemž typ relace mezi elementy název a autor není předek-následník, nýbrž sourozenci. Cesty lze kombinovat pomocí znaku. Např. dotaz D4: //zpráva //článek vrací sjednocení uzlů odpovídajících zprávám a článkům ve zdrojových datech. Všimněme si, že dotaz si lze snadno představit také jako stromovou strukturu. Ta je u jednoduchých cest skutečně grafem - cestou. Současný výzkum se dále soustřeďuje na dotazy, pro něž je vzor obecným stromem, přičemž se vlastně hledá jeho přesné vnoření do stromu XML dokumentu. 4.3 Jazyk XQuery Obecnější dotazy než v XPath lze konstruovat v jazyku XQuery. Na rozdíl od XPath, XQuery obsahuje konstruktor pro vytváření nových XML dat. Konstruovaný výstup dotazů, tj. nový XML dokument (nebo množina XML dokumentů), může být

11 Zvaná přednáška komponován ze zdrojové databáze zcela obecným způsobem (včetně agregačních funkcí, GROUP-BY apod.). Výrazy určující cestu použité v XQuery vycházejí z jazyka XPath. Rozdílný je v XQuery model 9 dat a dotazu. Zatímco výraz v jazyce XPath vrací množinu uzlů (tedy není nijak určeno pořadí), v jazyce XQuery tento výraz vrací posloupnost uzlů. Ta je setříděna podle toho, jak jsou jednotlivé uzly uspořádány v dokumentu. SELECT z SQL připomínají tzv. FLWOR (for-let-where-order by-return) výrazy. Obsahují proměnné, volání funkcí, kvantifikátory. Ukážeme jeden dotaz založený na FLWOR výrazech. Budeme uvažovat XML data odpovídající obrázku 1, tj. soubor biblio.xml obsahující zprávy a články, dále pak soubor knihy.xml obsahující element knihy s podelementy kniha strukturálně odpovídajícími DTD na obrázku 4. Uvažujme dotaz D5: Najdi ty autory zprávy nebo článku, kteří jsou spoluautory více než čtyř knih. for $i in distinct(document("biblio.xml")//autor) let $b := document("knihy.xml")/*/kniha[autor = $i] where count($b) > 4 return <populární-autor> { <jméno> $i/text()</jméno> <počet-titulů> {count ($b)} </počet-titulů> } </populární-autor> Odpovědí bude posloupnost elementů (bez duplicit) označených <popularníautor> se dvěma podelementy. Funkce document vrací kořen daného dokumentu. FLWOR výraz se skládá z jedné nebo více FOR a/nebo LET složek, přičemž FOR váže proměnnou s posloupností hodnot určenou obvykle pomocí výrazu určujícího cestu a iteruje přes všechny hodnoty této posloupnosti. LET také váže proměnné, ale bez iterace tak, že obsahují celé výsledky výrazů (zde např. všechny knihy autora zprávy nebo článku). Dále následují nepovinné složky WHERE a ORDER BY. Složka RETURN obvykle obsahuje konstrukce nových elementů a proměnné. Volá se pro každou sadu uzlů daných FOR/LET/WHERE složkami. FLWOR výrazy lze řetězit. XQuery je navržen tak, aby bylo možné ze vstupního XML dokumentu zkonstruovat jakýkoliv XML dokument za použití síly predikátové logiky 1. řádu. Rekurzivní funkce dále zvyšují sílu jazyka. Jazyk XPath 2.0 (na rozdíl od XPath 1.0) je již koncipován tak, že je podmnožinou XQuery. Zdůrazněme, že zmiňované prostředky, ač silné ve formulaci logických podmínek, se hodí stylem vyhodnocení spíše pro datově orientovaná XML data než pro obecné XML dokumenty. XQuery je v české literatuře detailněji popsán v článku [11]. 4.4 SQL/XML SQL/XML [6] (též SQLX) je vyvíjen skupinou H2.3 Task Group 10, v rámci číslovaných standardů SQL v části 14 (XML-related Specifications). Ve skupině 9 Model je společný i pro XPath 2.0. Blíže viz 10 Skupina se původně nazývala SQLX Group. Po názvem H2.3 Task Group funguje skupina od r

12 participují firmy Oracle, IBM, Microsoft 11, DataDirect Technologies a Sybase. Ve verzi SQL:2003 jde o rozšíření objektově relačního jazyka SQL, jak je známe z verze SQL:1999. Obsahuje: funkce pro vytváření XML dat, datový typ XML, mapovací pravidla. Funkce pro vytváření XML dat se používají přímo v příkazu SELECT, datový typ XML umožňuje přiřadit typ výsledku dotazu, který obsahuje XML data. Mapovací funkce určují jak reprezentovat SQL data jako XML data a jak zobrazit relační metadata do konstruktů jazyka SQL/XML a naopak. Metadata pro XML data jsou vyjádřena v jazyku XML Schema. Rozebereme zde podrobněji první rozšíření SQL. Je zřejmé, že zatím v SQL:2003 není v řeč o dotazování. To ovšem ve vývoji standardu existuje a např. v ORACLE XML DB je implementováno. Jde o operátory extrakt() a extractvalue() založené na použití výrazů jazyka XPath. Podobná je situace s aktualizací XML dat (operátor updatexml()) Vytváření hodnot typu XML z relačních dat K dispozici jsou operátory XMLELEMENT, XMLFOREST, XMLCONCAT, XMLAGG, XMLGEN použitelné přímo v příkazech SELECT. XMLELEMENT Aplikací XMLELEMENT se vytvoří nový XML element daného jména. XMLATTRIBUTES Umožňuje ze sloupců definovat atributy vytvářeného elementu. XMLFOREST Má podobnou funkci jako XMLATTRIBUTES. Zjednodušuje a zpřehledňuje tvorbu posloupnosti (lesu) XML elementů vytvářených z SQL výrazů vracejících hodnotu. XMLCONCAT Ze seznamu XML výrazů, které byly zkonstruovány nezávisle, např. pomocí XMLELEMENT, vytvoří jednu hodnotu obsahující les elementů. XMLAGG Konstruuje posloupnost elementů z kolekce řádků obsahujících jednotlivou XML hodnotu. Umožňuje v XML vyjádřit vztahy s kardinalitou 1:N. XMLROOT Vytváří kořen XML dokumentu. XMLCOMMENT Vytváří XML komentář. XMLPI Vytváří XML zpracovatelnou instrukci. XMLPARSE Rozkládá řetězec jako XML a vrací výslednou XML strukturu. Uveďme příklady uvažujíce tabulky Objednávky a Řádky podobné těm v obrázku 3. Elementy <objednávka> se třemi podelementy obdržíme způsobem z obrázku SQL/XML je odlišný od jazyka SQLXML firmy Microsoft. Jde o proprietární řešení v SQL Serveru. Microsoft neplánuje implementovat SQL/XML.

13 Zvaná přednáška SELECT XMLELEMENT( NAME objednávka, XMLFOREST ( o.číslo_o AS id, o.datum AS datum o.adresa AS adresa ) ) FROM Objednávky AS o WHERE stav = otevřená Obr. 5: Použití funkce XMLFOREST Výraz na obrázku 6 vede k získání všech objednávek spolu s informacemi o objednaných kusech zboží. SELECT XMLELEMENT( NAME objednávka, XMLATTRIBUTES(o.číslo_o AS id ), XMLAGG( XMLELEMENT(NAME produkt, XMLATTRIBUTES(r.číslo_ř AS číslo ) XMLFOREST(r.zboží AS název, d.počet_kusů AS množství ))) ORDER BY r.číslo_ř) FROM Objednávky AS o, Řádky_obj AS r WHERE o.číslo_o = r.číslo_o GROUP BY o.číslo_o <objednávka> <id>4711</id> <datum> </datum <adresa> </adresa> </objednávka> <objednávka id= <produkt číslo= > <název> </název> <množství> </množství> </produkt> <produkt> </produkt>. </objednávka> Obr. 6: Použití funkce XMLAGG Datový typ XML V SQL/XML je možné uložit XML dokument jako hodnotu typu VARCHAR nebo CLOB. Dále byl zaveden nový datový typ nazvaný XML. Hodnotou tohoto typu může být dokument, element, posloupnost (les) elementů, textový uzel nebo smíšený obsah. Atributy jsou pouze součástí elementu. Např. v tabulce Objednávky je typu XML sloupec objednávka. CREATE TABLE Objednávky (číslo_o integer, datum date zákazník varchar[20], objednávka XML); 4.5 Vyhodnocování dotazů nad XML daty Omezíme-li se zatím na jednoduché cesty, je žádoucí umět rychle nalézt v daném kontextu uzly ve vztahu předek-následník. Speciální metody se objevují v indexaci. Vedle indexace úplného textu se indexují pozice značek nebo řetězců typu PCDATA, relace pro vybrané osy, strukturální číselná schémata apod. Z širšího pohledu je zřejmě vhodné vidět indexy spíše jako logické struktury. To umožňuje řešit jejich

14 implementaci např. pomocí zvláštních tabulek v relační databázi, jak tomu je v komerčních SŘBD ORACLE nebo DB2. Pro indexaci těchto tabulek lze již využít B-stromů a jejich variant. Mohou být ale potřebné i indexy zcela speciální, jak dokládá např. relační databáze TransBase 12 s indexací, která je založena na UBstromech. V nativní XML databázi mohou být takové speciální indexy budovány přímo nad nativní reprezentací XML dat. Detailnější informace lze nalézt v [10]. 4.6 Nepřesné vyhledávání v XML datech V otevřených prostředích, jako např. web či intranety velkých podniků, je dotazování na přesnou či částečnou shodu nevyhovující či dokonce nemožné. XML data jsou v těchto případech spíše dokumentově orientovaná. Požadovány jsou prostředky, kterými lze specifikovat shodu pouze přibližně. Např. nevíme, že článek, který hledáme, se jmenuje Lehký úvod do XML. Slovo XML by mělo pouze být součástí názvu. Pak je ovšem nutné zavést určité hodnocení prvků odpovědi na dotaz. V oblasti DIS to znamená, že každý obdržený hit vážíme. Váha hitu vyjadřuje jeho relevanci vzhledem k uživatelovu dotazu. Rozšířit možnosti dotazování je dále možné pomocí tezaurů či ontologií. Další inspirací pro zavádění relevance jsou tzv. vágní predikáty. Výsledky jejich vyhodnocení závisí na nějaké metrice, jako např. "near_by" pro vzdálenost. Užitečné jsou i predikáty podobnosti výslovnosti, např. "sounds_like". Často nám ale ani o přesný tvar odpovědi nejde a zajímá nás spíše co nejrelevantnější úsek dat, bez ohledu na to, zdali se XML vyskytuje někde v názvu nebo v nadpisu kapitoly či sekce nějakého textu. I zde bychom chtěli mít výsledek setříděný podle relevance. Zřejmě je užitečné zavést do dotazování nad XML daty predikát podobnosti mezi výrazem dotazu a XML dokumentem. Takto může být pojato vyhledávání nad kolekcí dokumentů. Pak může být dotaz chápán tak, že se vybírají z množiny nějakých dokumentů ty relevantní, kde hodnota relevance může být dokonce zdola omezena nějakou prahovou hodnotou. Na rozdíl od textů v DIS je pro XML dokumenty novým prvkem struktura XML dat. Důležitý je rovněž způsob zacházení s popisem XML dokumentu, tj. s jeho DTD či XSD. Zcela odlišně můžeme přistupovat k datům, pokud známe jejich přesnou strukturu. Reálné je i dotazování dat z různých zdrojů, tedy s různými schématy. Detailnější informace lze nalézt v tutoriálu [5]. 5 XML v komerčních databázích Podle klasifikace uvedené v odstavci 2.3 popíšeme, jakých výsledků dosáhli dodavatelé (objektově) relačních databází zpřístupňující XML data a zmíníme několik reprezentantů nativních XML databází. Zdůrazněme, že úspěšná XML databáze by měla podporovat přijímání, ukládání, prohledávání a generování XML dat. Na tyto rysy je zaměřena pozornost v následujícím stručném přehledu. 12

15 Zvaná přednáška 5.1 Zpřístupnění XML dat u hlavních dodavatelů (objektově) relačních SŘBD Správa XML dat se objevuje v komerčních produktech známých výrobců databází. Jedná se zejména o produkty IBM DB2 Universal Database V8.1, Oracle Database 10g, Sybase ASE a MS SQL Server Všechny systémy podporují nestrukturované ukládání a rozkládání XML dat. Kromě MS SQL Serveru, se ostatní produkty hlásí k podpoře nativního uložení XML dat. Zmíněné systémy se také hlásí k podpoře částí dotazovacích jazyků XPath a XQuery. XML Extender v DB2 Pro nestrukturovanou variantu ukládání jsou definovány tři uživatelem definované typy (UDT): XMLVARCHAR (do 3Kbyte), XMLCLOB (do 32Kbyte) a XMLFILE, pro který je každý dokument uložen v jednom souboru lokálního souborového systému. XML Extender používá pro tvorbu XML dokumentů specifikaci zvanou Document Access Definition (DAD), která je sama o sobě XML dokumentem. DAD mapuje XML elementy a atributy do tabulek DB2. DAD může být také použita pro indexaci elementů a atributů, pro vytváření XML dokumentů z relačních dat v DB2, dále pak pro dekompozici XML dat do tabulek. Pro XML sloupec definuje DAD pomocí XPath indexy a části dokumentu, které mají být indexovány. Pro XML kolekce definuje DAD převod mezi obsahem XML dokumentu a jednotlivými sloupci a tabulkami. Pro vazbu s SQL se dají použít dvě zobrazení SQL a RDB_Node (Relational DataBase), které se liší pouze v úvodní fázi definice dat ke zpracování. První z nich se používá pro sestavení XML dokumentu, druhé jak pro jeho sestavení, tak pro dekompozici. Zobrazení SQL. Obsahuje SQL dotaz a instrukce, jak má být výsledek dotazu interpretován pomocí značek XML. Zobrazení RDB Node. Obsahuje seznam tabulek, jejichž obsah má být značkován, dále pak referenční integrity mezi tabulkami. Stejně jako v předchozím případě následuje informace, jak má být výsledek zpracování tabulek upraven pomocí značek XML. Uvažujme tabulku, ve které hodnoty sloupce mailbox obsahují uživatelské ové zprávy. CREATE TABLE mail_user( user_name VARCHAR(20) NOT NULL PRIMARY KEY password VARCHAR(10) mailbox XMLVARCHAR); V SQL dotazu SELECT user_name FROM mail_user WHERE extractvarchar(mailbox,"/mailbox/inbox/ /subject") LIKE "%MFF UK%"; je funkcí extractvarchar získán předmět zprávy a ten je testován, zdali obsahuje zmínku o MFF UK. Výsledek obsahuje uživatelská jména těch, kteří mají takovou zprávu ve své schránce.

16 Ze standardu SQL/XML jsou k dispozici funkce XMLELEMENT, XMLATTRIBUTE a XMLAGG. ORACLE XML DB XML data mohou být uložena pomocí nestrukturovaně jako CLOB nebo dekompozicí pomocí (objektově) relační databáze. Ve druhém případě je garantován model DOM. První technika je vhodná pro případy, kdy k XML datům neexistuje XSD. Pro vyhledávání v hodnotách typu CLOB je použit OracleText nástroj pro indexaci a prohledávání textových dokumentů. Další způsob indexace, tzv. funkcionální, využívá SQL/Path dotazy. Pro správu dokumentově orientovaných XML dat se uplatňuje datový typ XMLType, tj. UDT v souladu se standardem SQL:2003 (v terminologii ORACLE jde o typ objektů). Je tedy možné mít sloupec tabulky typu XMLType, ale i tabulku řádků typu XMLType. Existuje-li pro XML data jejich XSD, ORACLE XML DB automaticky generuje schémata tabulek, do kterých budou odpovídající XML data uložena. V opačném případě jsou uložena jako data typu CLOB. Nativní přístup abstrahuje od paměťové techniky, nicméně v implementaci je založen na objektovém rozšíření relačního stroje. Při implementaci XMLType se s výhodou využívá datový typ VARRAY (totéž co ARRAY v SQL:2003) a NESTED TABLE. Další variantou práce s XML daty je XML repozitář, který umožňuje centralizovanou správu obsahu ve složkách (obdobně jako v souborovém systému), údržba verzí XML dat apod. Kromě toho dává možnost ukládat XML data v obou paměťových verzích současně (CLOB a množina tabulek). Toto řešení může pro některé úlohy jistě znamenat velké paměťové nároky. Použití XMLType v SQL pohledu (view) umožňuje např. vidět XML data spolu s relačními jako nová XML data. V definici tabulky nebo sloupce lze XML data typu XMLType omezit pomocí jazyka XML Schema. XMLType nabízí funkce createxml() a getclobval() pro ukládání resp. vybírání dokumentu jako hodnoty atributu dokumentu. Na dotazování obsahu daných příslušných XML dat slouží již zmíněné metody extrakt() a extractvalue(). Dotazovací funkčnost založená na výrazech XPath nad XML daty v rozloženými v tabulkách vede k volání sekvence příkazů SQL (je-li transformace výrazu možná) nebo k vyhodnocení výrazu nad reprezentací DOM, která se pro příslušný dokument vygeneruje. Je zřejmé, že druhý způsob vyhodnocení může být značně neefektivní. Funkce ze SQL/XML jsou k dispozici jako stejné jako v DB2 včetně dalších vlastních. Sybase ASE Sybase ASE umožňuje ukládat XML data třemi způsoby: jako dokument, po elementech a hybridně kombinací obou předchozích metod. Má-li XML dokument být uložen jako dokument, provádí se to pomocí typu text, generická Java třída, nebo uživatelská Java třída. Hybridní metoda zachovává XML dokument a navíc lze použít jeden nebo několik SQL sloupců pro uložení některých dat z XML dokumentu pro jejich rychlé použití. ASE používá pro XML data patentovaný Fast Index, kterým se indexuje jakýkoliv XML element, atribut nebo cesta.

17 Zvaná přednáška SQL Server Speciální přístup k XML v relační databází má firma Microsoft. XML data mohou být produkovány z tabulek pomocí klauzule FOR XML. Ta má tři módy: RAW, AUTO a EXPLICIT. Pomocí RAW můžeme získat z každého řádku odpovědi na SQL dotaz element se značkou <row> a odpovídajícími atributy. Mód AUTO vrací odpověď jako hnízděnou XML strukturu, kde každá hodnota atributu je v XML pojmenována podle toho, ze které tabulky a kterého sloupce je hodnota extrahována. Hierarchie je určena podle pořadí sloupců za SELECT. V módu EXPLICIT je hierarchie řízena dotazem. SQL Server také poskytuje klauzuli OPENXML, pomocí které lze formulovat dotazy nad XML daty. V reprezentaci BLOB lze text XML předzpracovat (garantuje se Infoset) a pomocí OPENXML využít možnosti dotazu v XPath 1.0 a SQL. MS SQL Server 2000 není explicitně koncipován jako nativní XML databáze. Ta má být obsažena v očekávané verzi Yukon. 5.2 Nativní XML databáze Termín nativní XML databáze vznikl v komerční sféře a jako takový nemá jasnou definici. Základní charakteristiky nativních XML databází podle ového adresáře skupiny XML:DB jsou tyto: Pro ukládání a dotazování XML dat se používá logický model XML dat. Takový model zahrnuje minimálně elementy, atributy, obsah elementů typu PCDATA a uspořádání elementů. Modely jsou obvykle implementovány pomocí DOM či SAX. XML dokument je základní jednotkou logické paměti na rozdíl od relační databáze, kde je touto jednotkou řádek tabulky. Relační, síťový či hierarchický datový model (ve smyslu příslušných databází) nemusí být pro uložení XML dat využit. Nativní XML databáze mají původní implementaci s vlastními indexy či vlastní kompresí dat. Tyto databáze umožňují zpracovávat i smíšený obsah elementu a data, kterým odpovídá rekurzivní DTD, což se u ostatních uložení XML dat realizuje jen obtížně. Je výhodné je použít tam, kde je využívána stromová struktura zdrojových dat. V nativních XML databázích se snáze provádějí aktualizace XML dat, uspokojivě je řešen je problém reverzibility zobrazení. Ze strany uživatele (správce databáze) není nutné řešit problém zobrazení XML dat do alternativních databázových struktur. Podporován je pojem kolekce, tj. XML data lze vidět jako kolekci "podobných" dokumentů. Jako dotazovací jazyk se v nativních XML databázích používá XPath, ale hlavně XQuery. Bohužel XPath má z hlediska databází několik zásadních omezení, jako např. nemožnost realizovat spojení XML dokumentů, třídění a seskupování. Velmi zhruba řečeno, XPath je podmnožinou jazyka XQuery, který řeší uvedené problémy. Implementace XQuery je cílem všech dodavatelů nativních XML databází. Zatím však není jasná finální verze jeho standardu, s nemalými problémy se řeší efektivní implementace. Nativní databáze umožňují ve větší či menší míře též aktualizace databáze, snahou je realizovat i pojem transakce, uzamykání dat a souběžný přístup.

18 5.2.1 Komerční produkty s nativní XML databází SŘBD Tamino firmy Software AG 13 dnes patří ve světě k nejcitovanějším. XSD se v něm definuje pomocí podmnožiny jazyku XSchema. Ve verzi najdeme prototypovou implementaci XQuery nazývanou QuiP. Tamino XML server není zaměřen pouze na datově orientovaná XML data. Je možné provést změnu uzlu XML stromu, aniž by bylo nutné číst celý XML strom do vnitřní paměti. Vícenásobný přístup je však zatím realizován tak, že se provádí zamykání stránek (bloků) a nikoliv částí stromů, tak jak by se předpokládalo ve stromovém datovém modelu. Tamino provádí indexaci úplných textů, které jsou reprezentovány v XML. Za zmínku stojí, že nativní XML databáze je vybudována na základech starého databázového produktu ADABAS, kterým byl Software AG slavný v době sálových počítačů. Nelze se však příliš divit, protože původní ADABAS implementoval hierarchický model dat. Jmenovat lze dále produkty jako XIS (extendible Information Server) integrovaný do produktů Sonic Software firmy Progress Software Corp. 14 nebo X-Hive/DB firmy X-Hive Corporation 15. Mezi citované implementace patří exist 16 (viz též [3]). Všechny tři systémy disponují pro dotazovaní jazykem XQuery. Dalším zajímavým systémem je open source software Xindice firmy The Apache Software Foundation 17. Využívá jazyk XPath. Jako poslední uvádíme novější pokus o nativní XML databázi dbxml poskytovanou dbxml Group 18. Umožňuje práci s jazyky XPath, XSLT, XUpdate, a fulltextové vyhledávání. XUpdate je součástí exist a Xindice. Specifickým problémem nativních XML databází jsou jejich API. Každý produkt má své vlastní. Připomeňme, že v relačních SŘBD tuto situaci řeší rozhraní ODBC a JDBC. Jak Tamino tak exist mají implementováno API podle iniciativy XML:DB Další typy nativních XML databází Širší funkčnost mají systémy pro řízení obsahu (Content Management Systems - CMS). Tyto systémy se liší od systémů pro řízení dokumentů zejména v tom, že umožňují pracovat s částmi dokumentu, s jeho metadaty apod., tedy nejen s dokumentem jako celkem. CMS jsou vhodné pro tvorbu manuálů, memorand, sborníků apod. CMS bývají budovány nad nativní XML databází. Vedle nižších databázových funkcí nabízejí možnosti pro: řízení verzí, revizí a přístupu, znovupoužití dokumentů v různých formátech, spolupráci uživatelů, publikování na webu, podporu pro různé formáty textů a editorů, indexační a vyhledávací funkce

19 Zvaná přednáška Strom, který poskytuje rozhraní DOM, může být i 10 větší než vlastní XML data, takže se nemusí vejít do vnitřní paměti, kterou DOM pro uložení stromu využívá. PDOM (Persistent DOM) řeší tento problém. 6 Závěr Je zřejmé že nevyřešena zůstává řada dalších problémů. Jak např. navrhovat XML databáze? Objevují se pokusy o (staro)nové konceptuální modely upravené pro XML [4] a nástroje, které z konceptuálního schématu automaticky vygenerují XSD. Možnosti databázového přístupu k XML datům evokují pro uživatele otázku, který přístup použít v konkrétní situaci. Je zřejmé, že pro datově orientovaná XML data se většinou vystačí s (objektově) relačním SŘBD. Něco jiného jsou XML dokumenty. Z hlediska aplikace může jít o správu dokumentů nebo o správu obsahu. Jestliže je struktura těchto dat potřebná v dotazech, pak začnou být přínosné nativní XML databáze. Další důležitou otázkou je, jak systematicky a efektivně provádět integraci relačních dat a XML dat. SQL/XML je vhodný pro programátory využívající SQL, kteří potřebují výstup v XML. XQuery je vhodnější pro programátory nativních XML databází případně vyžadující pracovat současně s XML databází a relační databází. Inspirací může být strategie IBM, která vidí budoucnost DB2 v bilingvním přístupu. Staví jazyky SQL a XQuery v SŘBD na jednu úroveň. Dokazuje to projekt Xperanto, který nabízí možnost integrovat nativní XML databázi do DB2. Důvodů po takový přístup je více. Některé úlohy se provádějí prostřednictvím relačního SŘBD dost těžko (viz rekurzivní dotazování, smíšený obsah v XML datech apod.). Vědecká komunita intenzivně pracuje v oblasti návrhu a testování nových efektivních datových struktur pro XML databáze. Výzvou také je nalézt vhodné techniky pro efektivní implementaci dotazovacího jazyka XQuery. Poděkování Práce byla částečně financována z prostředků projektu GAČR 201/02/1553. Literatura 1. Bourret, R.: XML and Databases Bourret, R.: XML Database Products Chaudhri, A.B., Rashid, A., Zicari, R. (ed.): XML Data Management Native XML and XML-Enabled Database Systems. Addison-Wesley, Doshi, R., Sriram, M., Sengupta, A.: XER - Extensible Entity Relationship Modeling. In: Proc. of XML Conf. & Exposition 2003, Philadelphia, 2003

20 5. Húsek, D., Pokorný, J., Snášel, V., Řezanková, H.: Metody vyhledávání v rozsáhlých kolekcích dat. In: Proc. of the Annual Database Conf. DATAKON'2003, L. Popelínský (Ed.), Brno, 2003, pp ISO: Information technology - Database languages - SQL - Part 14: XML- Related Specifications (SQL/XML), ISO/IEC : McCown, S.: Databases Flex Their XML. InfoWorld, April 26, Issue 17, Mlýnková, I., Pokorný, J.: XML in the World of (Object-) Relational Database Systems. In: Information Systems Development Advances in Theory, Practice and Education, 13th Int. Conf. on ISD, Vilnius, Lithuania, Sep. 2004, to appear. 9. Pokorný, J.: XML: a challenge for databases? Chap. 13. In Contemporary Trends in Systems Development, M. K. Sein (Ed.), Kluwer Academic Publ., 2001, pp Pokorný, J.: XML databáze. In: Sborník XXIV. konference EurOpen, Hotel Sněžník, Dolní Morava, 2004, pp Toman, K.: XQuery. In: Sborník XXIV. konference EurOpen, Hotel Sněžník, Dolní Morava, 2004, pp XML Path Language (XPath) Version 1.0. W3C Recommendation 16 November 1999, W3C: XQuery 1.0: An XML Query Language. W3C Working Draft 02 May Annotation: XML databases: the state of art and perspectives A development of commercial applications shows that there is a need to store XML data in a database way. The goal of this contribution is to discuss possibilities of using XML as a new database model. The state-of-art of XML databases approaches is presented. In the first one XML data is stored in an (O)RDBMS as texts or with the help of special user-defined types, or it is decomposed into more tables. A more natural approach is applied in XML native databases with a special implementation of XML data store. XML data are approached by special query languages, such as XPath or XQuery. The practice considers also approximate retrieval as useful. So, an influence of information retrieval techniques is remarkable in this context. Another possibility is offered by the variant of SQL (under development) for XML (SQL/XML). All the languages are introduced by examples. An attention is also paid to their expressive power. Finally we mention some product for XML databases and conclusions.