XML data na disku jako databáze

Transkrypt

1 Univerzita Karlova v Praze Matematicko-fyzikální fakulta DIPLOMOVÁ PRÁCE Kamil Toman XML data na disku jako databáze Katedra softwarového inženýrství Vedoucí diplomové práce: prof. RNDr. Jaroslav Pokorný, CSc. Studijní program: Informatika Studijní obor: Softwarové systémy PRAHA 2003

2 Poděkování Na tomto místě bych chtěl poděkovat zejména svému vedoucímu diplomové práce prof. RNDr. Jaroslavu Pokornému, CSc. za řadu podnětných nápadů, pomoc při odstraňování chyb, za náměty pro zdokonalování práce a za řadu cenných rad. Prohlášení Prohlašuji, že jsem svou diplomovou práci napsal samostatně a výhradně s použitím citovaných pramenů. Souhlasím se zapůjčováním práce. V Praze dne 14. srpna 2003 Kamil Toman

3 Obsah Úvod 1 1 Základy XML Účel XML Struktura XML dokumentu Zápis XML značek Dodatečné informace dokumentu Definice typu dokumentu (DTD) Deklarace elementů v DTD Deklarace atributů v DTD Další charakteristiky XML dokumentu Model XML dokumentu Dotazovací jazyky Vznik XML dotazovacích jazyků Požadavky na XML dotazovací jazyky Historické XML dotazovací jazyky XML-QL Lorel XQL XPath Základní adresace XPath Zápis cest jmen Zkrácená forma zápisu Korelované cesty jmen XQuery SXQ Perzistentní XML data Strategie ukládání XML dat Uložení XML v systému souborů Uložení XML v relační databázi Uložení hran XML stromu Uložení hran podle jednotlivých značek Strukturální uložení dokumentu podle DTD

4 3.3.4 Vlastnosti uložení v relačních databázích Uložení XML v objektově orientovaném systému Uložení XML v objektově-relačním databázovém systému Nativní XML úložiště Číselná schémata Sekvenční číselná schémata Statická strukturální číselná schémata Trvalá strukturální číselná schémata Strategie vyhodnocení dotazu Navigační metody Metody využívající strukturální spojení Strukturální spojení element-atribut Strukturální spojení element-element Způsoby indexování XML dat DataGuide Pokrývající indexy Index SphinX Adaptivní index Experimentální databáze SXQ-DB Celková architektura systému Modul pro zpracování dotazů Zpracování dotazu Vyhodnocení dotazu XML úložiště a jeho implementace Reprezentace XML dokumentu Reprezentace kolekce dokumentů Architektura XML úložiště Fyzický přístup k souborům na vnějším médiu Uložení DTD kolekce dokumentů Uložení struktury dokumentu Vyhledávání ve struktuře dokumentu Uložení hodnot elementů a atributů Využití objektové cache

5 7 Další existující XML databáze exist Timber Závěr 76 A Uživatelský manuál SXQ-DB 77 A.1 Instalace binárních souborů A.2 Instalace ze zdrojových souborů A.3 Kolekce XML dokumentů A.4 Dotazování do kolekce A.5 Přidávání souborů do kolekce a vytváření nových kolekcí B Gramatika jazyka SXQ 81

6 Název práce: XML data na disku jako databáze Autor: Kamil Toman Katedra: Katedra Softwarového Inženýrství Vedoucí diplomové práce: Prof. RNDr. Jaroslav Pokorný, CSc vedoucího: Abstrakt: V této práci jsou shrnuty možné přístupy při návrhu systému pro práci s perzistentními XML daty. Jsou popsány některé základní XML dotazovací jazyky, včetně moderních jazyků jako jsou XPath a XQuery. Podrobně jsou rozebrány vlastnosti datového modelu XML a možnosti implementace vyhodnocování dotazů nad XML daty ve vnější paměti. Jsou popsány nejen tradiční navigační metody, ale i novější algoritmy strukturálního spojení. Vysvětleny jsou i některé indexové struktury, které si při vyhodnocení těmito technikami používají. Jsou to např. indexy DataGuide, pokrývající indexy, metody SphinX a APEX. Teoretická část práce se také zabývá některými základními číselnými schématy zachycujícími strukturální podstatu dokumentu, např. intervalovými a prefixovými schématy, a vztahy mezi nimi. Praktická část práce zahrnuje experimentální aplikaci pracující s bází XML dat. Aplikace se skládá z nativního XML úložiště a jednoduché implementace dotazovacího jazyka navrženého tak, aby pokrýval nejdůležitější konstrukce jazyka XQuery. Klíčová slova: XML, XQuery, databáze Title: XML Data as a Database Author: Kamil Toman Department: Department of Software Engineering Supervisor: Prof. RNDr. Jaroslav Pokorný, CSc Supervisor s address: pokorny@ksi.mff.cuni.cz Abstract: We survey several approaches to overall design of systems manipulating persistent XML data. We describe some of basic XML query languages including modern query languages like XPath and XQuery. In more details, we discuss the important features of XML data models and eventualities of query processing implementations working with data in external memory. We describe not only traditional navigational methods but also more recent algorithms of structurual joins. We elucidate several indexing structures used by some of these techniques during query evaluation, for instance the DataGuide index, covering indexes and approaches like SphinX and APEX. In the theoretical part of the thesis we also consider several basic structural numbering schemes, for example interval and prefix schemas, and we examine their relationships. The practical part includes an experimental application which can be used to manage XML data in external memory. The application consists of a native XML storage and more straightforward implementation of a query language which has been designed to cover the most important constructs of XQuery. Keywords: XML, XQuery, database

7 ÚVOD Úvod Jazyk XML vznikl poměrně nedávno, ale za tu dobu našel již celou řadu uplatnění. Používá se především jako standard pro elektronickou výměnu dat mezi aplikacemi a také jako flexibilní formát pro ukládání informací. S rozvojem Internetu se data získávají stále více z různých zdrojů a nelze se tedy spoléhat na jejich homogenitu, naopak je potřeba přizpůsobit aplikace, aby s daty různého tvaru dokázaly pracovat. XML dokumenty jsou logicky formátované dokumenty, které částečně stírají rozdíl mezi tradičními textovými daty bez explicitně daného formátu a pevně strukturovanými informacemi, které jsou tradičně ukládány v relačních databázích. S pomocí jazyka XML totiž lze mnohem lépe popsat strukturu dokumentů jako jsou třeba technické manuály, slovníky, různé články a další texty, ve kterých se dnes jinak můžeme orientovat jen obtížně. Obsah XML dokumentů je značkami rozdělen na menší části, elementy, které jsou určitým způsobem pojmenovány a které tvoří vždy jeden logický celek. Z tohoto pohledu se tedy můžeme na XML data dívat jako na databázi, která ovšem nemá předem danou strukturu a v níž i sama struktura XML dokumentu nese určitou informaci. O takových datech říkáme, že jsou samopopisující. Abychom s těmito daty mohli rozumně pracovat, potřebujeme nějaký nástroj s jehož pomocí lze vyhledávat, aktualizovat, případně i vytvářet nové informace nezávisle na jejich fyzické reprezentaci. Ve světě relačních databází k tomuto účelu slouží populární dotazovací jazyk SQL. V případě XML dat ovšem podobný všeobecně uznávaný standard dotazovacího jazyka zatím není k dispozici, což vede k určité roztříštěnosti. V současné době proto existuje hned několik XML dotazovacích jazyků, každý s mírně odlišnými vlastnostmi a schopnostmi. Všechny ovšem dovolují zadávat dotazy, které se mohou týkat nejen hodnot ale i struktury uložených dokumentů. Také optimalizace dotazů nad XML daty a postupy, které lze použít při jejich vyhodnocení, jsou zatím, i přes velké úsilí mnoha vývojářů, prozkoumány velmi málo. Kvůli mnohem obecnější stromové struktuře XML dat navíc nejsou bohužel ani příliš použitelné znalosti získané při dlouhodobém vývoji relačních databází. U XML dokumentů je tak kladen mnohem větší důraz na vlastnosti datového modelu a na využití moderních metod indexace dat, které by umožňovaly rychlejší přístup k objektům nezbytným pro výpočet výsledku dotazu. V teoretické části práce se proto budeme věnovat především zkoumání datového modelu XML, číselných schémat zachycujících strukturální podstatu dokumentu a možnostem vyhodnocení dotazů nad XML daty. Probereme i některé způsoby jak zajistit perzistenci XML dat v již existujících databázových systémech. Zmíníme také hlavní rysy několika dotazovacích jazyků, se zaměřením na nejpoužívanější jazyky XPath a XQuery. Z jejich podstatných konstrukcí byl vytvořen dotazovací jazyk SXQ, který je též implementován v prototypové aplikaci. Technikami logické optimalizace dotazu, či výběrem a ohodnocením možných plánů výpočtu se naopak zabývat 1

8 ÚVOD vůbec nebudeme. Praktická část práce je věnovaná implementaci experimentální aplikace SXQ-DB pro práci s datovou bází XML. Výsledná aplikace má dvě hlavní části. První z nich představuje modul, který zpracovává a vyhodnocuje dotazy jazyka SXQ, druhou část tvoří datové úložiště používající specializované postupy pro ukládání XML dat. Modul pro zpracování dotazů je implementován poněkud zjednodušeně. Cílem bylo především vyzkoušet možné postupy implementace základních konstrukcí jazyka XQuery a ověřit, zda je použitý datový model dat dostatečný pro vyhodnocení všech konstrukcí daného jazyka. Implementace druhého modulu, nativního XML úložiště, vychází ze základních prostředků implementačního prostředí pro správu XML dat realizovaného v [1], s důrazem na praktickou použitelnost modulu při vyhodnocování dotazů v databázové aplikaci. Úložiště umožňuje spravovat, modifikovat a přistupovat data uložená ve vnější paměti a poskytuje důležitá programová rozhraní pro další části systému. Narozdíl od poměrně obecných rozhraní a postupů původního implementačního prostředí je zde kladen důraz i na celkovou efektivitu přístupu k uloženým datům. V modulu jsou proto implementovány rychlejší algoritmy zajišt ující stránkování a přístup do vyrovnávacích pamětí, účinější využití objektové cache a zjednodušení datového toku při operacích iniciovaných modulem vyhodnocujícím XML dotazy. Zároveň byl modul modifikován tak, aby se zmenšilo množství spotřebovávané paměti a tím umožnilo současně zpracovávat výrazně větší množství dat. Teoretická část začíná v první kapitole uvedením základů jazyka XML. Popíšeme základní strukturu a vlastnosti XML dokumentů a vysvětlíme, jak s pomocí definice typu dokumentu přesněji stanovit vztahy mezi jeho jednotlivými částmi. Ukážeme také základní používaný model XML dat. Druhá kapitola je věnována XML dotazovacím jazykům. Obecně shrneme požadavky, které je nutno zohlednit při návrhu XML dotazovacích jazyků a ukážeme některé důležité vlastnosti zvolených dotazovacích jazyků. Uvedeme také příklady nejdůležitějších konstrukcí jazyka XPath a XQuery, resp. jejich implementované podmnožiny jazyka SXQ. Ve třetí kapitole uvedeme možné přístupy ukládání XML dat v tradičních databázových systémech a zmíníme i základní vlastnosti specializovaných XML úložišt. Ve čtvrté kapitole se budeme věnovat číselných schématům vyvinutým pro identifikaci XML dat a jejich schopnostem zachytit strukturální informaci XML dokumentů. Ukážeme také některé vztahy mezi jednotlivými očíslováními. V páté kapitole ukážeme některé základní přístupy k vyhodnocování dotazů nad XML daty. Představíme klasické postupy vyhodnocení dotazu, jako jsou např. navigační metody a podrobně probereme i postupy využívající operaci strukturálního spojení. Popíšeme i možné vylepšení původních algoritmů. Druhou část kapitoly věnujeme některým indexům specifickým pro XML data. 2

9 ÚVOD Šestá kapitola se zabývá praktickou částí práce. Uvedeme zde celkovou architekturu aplikace, zvolený datový model a detaily jeho jeho fyzické reprezentace. Popíšeme také důležité části jednotlivých modulů systému. V sedmé kapitole stručně popíšeme některé další existující XML databáze s odlišným způsobem reprezentace dat i práce s XML dokumenty. Součástí textu jsou i dva dodatky. Dodatek A je uživatelský manuál popisující instalaci a práci s programem, dodatek B je formální popis implementované gramatiky jazyka SXQ. Na přiloženém kompaktním disku se nachází programová dokumentace, popis jednotlivých tříd a jejich rozhraní. Disk dále obsahuje zdrojové texty aplikace a testovací kolekce XML dokumentů s vytvořenými databázemi pro aplikaci SXQ-DB. 3

10 ZÁKLADY XML 1 Základy XML 1.1 Účel XML Jazyk XML (extensible Markup Language) [3] je populární a dnes již velmi rozšířený standard pro vytváření přenositelných, platformně nezávislých, dokumentů a dat. Svou syntaxí je velmi podobný webovému standardu HTML, nicméně je zde několik podstatných rozdílů. Jazyk HTML byl vytvořen především pro účely formátování a zobrazování webových dokumentů. Jako takový má jasně definovanou pevnou množinu používaných značek a jejich významů pro zobrazení obsahu dokumentu. XML je v tomto ohledu spíše metajazyk pouze popisuje dokument po syntaktické stránce, samotným značkám konkrétní obsah nepřiřazuje. Sémantika XML dokumentu je tedy plně v rukou autora a jen na něm záleží, jak bude daný dokument dále zpracováván. Jako hlavní cíle návrhu XML autoři jazyka uvádějí především jeho širokou použitelnost, jednoduchost dokumentů i programů, které XML dokumenty vytvářejí a zpracovávají, čitelnost pro člověka a možnost rychlého a metodického vývoje struktury dokumentu. Naopak stručnost vyjadřování má v XML minimální důležitost. Velkou výhodou jazyka XML je jeho univerzálnost je v něm možné reprezentovat prakticky jakákoliv data. Není nutné se omezovat jen na typické textové dokumenty jako knihy, články, divadelní hry a podobně. Jazyk XML lze použít třeba i k uložení programové konfigurace, k vyjádření formátu dat přenášených po síti (web services) nebo k popisu vektorové grafiky (formát SVG). Každý dokument v sobě navíc obsahuje informaci o použitém kódování a znakové sadě, což dále umožňuje jeho další efektivní zpracování. Významným přínosem může být i fakt, že jako základní kódování XML dokumentů bylo stanoveno Unicode se znakovou sadou ISO 10646, reprezentovanou 32 bity. 1.2 Struktura XML dokumentu Každý XML dokument je jednoduchý textový soubor, jehož jeho jednotlivé části jsou logicky rozčleněny pomocí speciálních značek (tagů). Značky jsou od ostatního textu odděleny speciálními znaky < a >. Na obrázku 1 je vidět zápis jednoduchého XML dokumentu. První řádek každého XML dokumentu je vždy tzv. XML deklarace. Ta vymezuje nejzákladnější vlastnosti dokumentu především pro potřeby syntaktického analyzátoru XML. V naší ukázce obsahuje tři atributy: verzi dokumentu (version), použité kódování (encoding) a příznak úplnosti (standalone). Uvedení verze používaného standardu dokumentu je povinné, další dva atributy je možné vynechat. Pro kódování 4

11 ZÁKLADY XML <?xml version= 1.0 encoding= UTF-8 standalone= no?> <!DOCTYPE kontakt SYSTEM kontakt.dtd > <kontakt> <jméno>jan Novák</jméno> <tel> <mobil> </mobil> <domů> </domů> </tel> </kontakt> Obrázek 1: Příklad jednoduchého XML dokumentu. lze použít různé standardy 1, např. UTF-8, UTF-16, ISO UCS2, ISO atd. Pokud atribut encoding neuvedeme, předpokládá se kódování UTF-8. Atribut standalone udává, zda lze dokument použít samostatně nebo zda je potřeba současně i definice typu dokumentu DTD (Document Type Definition). Pokud tento atribut nenastavujeme, analyzátor předpokládá implicitní hodnotu no. Bezprostředně za XML deklarací může následovat nepovinná Deklarace typu dokumentu (Doctype), která XML dokumentu přiřazuje použité DTD, tj. souhrn pravidel definujících použité značky a vztahy mezi nimi. V předchozím příkladu odkazuje Deklarace typu dokumentu na řádku 2 na definice z externího souboru kontakt.dtd. XML deklarace a deklarace typu dokumentu tvoří prolog XML dokumentu, za nímž už následuje jen vlastní obsah dokumentu. 1.3 Zápis XML značek Obsah XML dokumentu je značkami rozdělen do logických celků dat, tzv. elementů. Ty mohou být dvou typů. První typ představuje element tvořený dvěma párovými značkami, mezi kterými je uzavřena část dokumentu, která tvoří obsah elementu (text, případně hnízděné elementy). Zapisujeme jej ve tvaru <název elementu> obsah elementu </název elementu>. Druhý, méně běžný typ elementu, je tvořen jen názvem značky nemá žádný další obsah. Takový element zapisujeme ve tvaru <název elementu/>. Pro vytváření elementů platí poměrně striktní pravidla. V názvech elementů nejsou povoleny mezery (lze je nahrazovat podtržítkem) a jsou rozlišována malá a velká písmena, tj. např. značka <p/> neurčuje stejný element jako <P/>. Klíčovou vlastností je, že jednotlivé značky musí být správně hnízděné, nesmí se křížit. Nelze tedy psát konstrukce jako <bf>tučné<it>tučná kurzíva<tučné> kurzíva<it>. Kvůli snazšímu zpracování a validaci dokumentů musí být navíc párové značky vždy uvedeny obě, nelze vypustit koncovou značku, jak je běžné např. v HTML. 1 XML analyzátory musí akceptovat kódování UTF-8 a UTF-16, ostatní jsou jen volitelné a nemusí být implementovány. 5

12 ZÁKLADY XML Každý element v sobě může navíc nést dodatečnou informaci v podobě atributů. Psaní atributů má stejnou syntaxi jako v prologu XML dokumentu, tj. dvojice název atributu a hodnota v uvozovkách nebo apostrofech uvedené za názvem elementu <název elementu atribut= hodnota >. Atributů může být u jednoho elementu více, jednotlivé dvojice jsou od sebe oddělený mezerami. Pro pojmenovávání atributů platí stejná pravidla jako pro pojmenovávání elementů. 1.4 Dodatečné informace dokumentu Kromě vlastního obsahu lze XML dokument vybavit i dodatečnými informacemi pro člověka resp. program, který jej bude dále zpracovávat. Jednotlivé varianty představují tzv. XML komentáře resp. instrukce pro zpracování. Smysl dokumentu nijak nemění, pouze čtenáře upozorňují např. na nějaká související fakta. Instrukce pro zpracování resp. XML komentáře uvozujeme znaky <? resp. <!-- a ukončujeme?> resp. -->. Narozdíl od jinak přísné struktury XML dokumentu, s bílým místem mezi značkami lze zacházet víceméně volně XML dokumenty tak lze vizuálně přehledně formátovat, podobně jako např. v úvodní ukázce. Pokud jsou bílé znaky významné, tj. tvoří vlastní data XML dokumentu, lze takovou datovou oblast označit v DTD. 1.5 Definice typu dokumentu (DTD) Součástí prologu XML dokumentu je i definice jeho typu. Tu je možné uvést v zásadě dvěma způsoby jako lokální (DTD je obsaženo přímo ve zdrojovém dokumentu) nebo externí (DTD je umístěno na uvedeném URL). Obě dvě možnosti se liší pouze formálně, z hlediska obsahu jsou zcela rovnocenné. Definice typu dokumentu deklaruje především úplný výčet všech názvů elementů a atributů používaných v XML dokumentu a určuje také vztahy mezi nimi. Syntaxe DTD je bohužel poněkud odlišná od syntaxe jazyka XML (a bohužel také méně čitelná), svojí funkci nicméně dokáže zastat dobře. Lepší expresivní možnosti (jako např. možnost definice datových typů, způsobu validace dokumentu, využití jmenných prostorů atp.) přinášejí až novější nástupci DTD, např. XML Schema [6]. Daní za to je ovšem podstatné zvýšení složitosti jak syntaktické analýzy dokumentu tak jeho validace a náročnější další zpracování Deklarace elementů v DTD Deklaraci XML elementu píšeme ve tvaru <!ELEMENT název elementu definice- -obsahu-elementu>. Obsah elementu může zůstat nespecifikovaný uvedením klíčového slova ANY. Přesná definice elementu musí obsahovat bud klíčové slovo EMPTY označující element nemající žádný obsah, nebo tzv. modelovou skupinu. Modelová skupina je tvořena n-ticí názvů elementů, které jsou vzájemně oddělené jedním ze dvou 6

13 ZÁKLADY XML oddělovačů, nebo. Oddělovač, značí, že dané elementy musí být v právě definovaném elementu obsaženy všechny a navíc v pořadí uvedeném v definici. Naproti tomu použití oddělovače říká, že v dokumentu se v definovaném elementu může objevit jen jeden z elementů modelové skupiny. Pokud má být obsahem elementu samotný text uvedeme namísto jména podelementu klíčové slovo #PCDATA (zkratka vznikla z anglického parsed character data). Speciální případ tvoří tzv. element se smíšeným obsahem (mixed content element), tj. element obsahující jak další podelementy, tak vlastní textová data. V definici takového elementu musíme klíčové slovo #PCDATA uvést na prvním místě a navíc v modelové skupině nesmí být žádný element uveden víckrát. Použitý oddělovač v definici navíc musí být vždy. U názvu každého elementu v modelové skupině můžeme navíc uvést ještě jeden z četnostních operátorů?, + nebo * s obvyklými významy nepovinný element s nanejvýš jedním výskytem, element s jedním a více výskyty nebo nepovinný element s libovolným počtem opakování. Četnostní operátor je možné uvést i pro celou modelovou skupinu. Ukázka definic XML elementů: <!ELEMENT br EMPTY> <!ELEMENT dokument (hlavička?,obsah,odstavec*) <!ELEMENT odstavec (#PCDATA br strukturovaný_text)* > <!ELEMENT strukturovaný_text (odstavec+,struktura) > <!ELEMENT struktura ANY> Deklarace atributů v DTD Každému elementu lze přiřadit libovolně mnoho atributů. Ty, narozdíl od XML elementů, představují pouze nestrukturovanou informaci, jejich zápis je proto mnohem jednodušší. Deklarace všech atributů jednoho elementu se píše obvykle dohromady ve tvaru <!ATTLIST jméno elementu seznam atributů>. Definice každého z atributů seznamu pak má tvar: jméno atributu typ atributu standardní hodnota příznaky. Typ atributu bývá obvykle jedna z následujících hodnot: CDATA (libovolný textový řetězec), NMTOKEN (řetězec splňující omezení kladená na vytváření XML jmen), NMTOKENS (skupina slov typu NMTOKEN), případně výčtový list ve tvaru (prvek1 prvek2...) (je povolena právě jedna z hodnot výčtu). Speciální význam atributu přiřazuje trojice typů ID, IDREF a IDREFS. Atributy tohoto typu jsou v XML dokumentech používány jako jednoduché odkazy v rámci dokumentu. Atributy typu ID fungují jako jednoznačné identifikátory elementu v dokumentu, typy IDREF resp. IDREFS pak umožňují daný element asociovat s jiným elementem resp. elementy. Standardní hodnota v deklaraci uvádí textovou hodnotu, jíž atribut implicitně nabývá. Tento údaj je nepovinný. 7

14 ZÁKLADY XML Jako poslední můžeme uvést jeden z příznaků: #REQUIRED (uvedení atributu je v dokumentu vyžadováno) nebo #IMPLIED (atribut není nutné uvádět) a #FIXED (nelze uvést jinou než standardní hodnotu atributu). Příznak #FIXED navíc tvoří drobnou výjimku, nebot se uvádí ještě před uvedením standardní hodnoty. Příklad definice XML elementu s atributy: <!ELEMENT obdélník EMPTY> <!ATTLIST obdélník šířka CDATA 10 #REQUIRED výška CDATA 20 #REQUIRED barva #IMPLIED užití #REQUIRED typ_čáry (tenká střední silná) střední #IMPLIED dimenze #FIXED 2 > 1.6 Další charakteristiky XML dokumentu Pokud jsme dodrželi všechna výše uvedená syntaktická pravidla, dostáváme tzv. správně utvořený (well formed) XML dokument. Takový dokument musí alespoň obsahovat potřebný XML prolog a splňovat požadavek na správné hnízdění syntaktických dobře pojmenovaných značek. Musí také platit, že celé tělo XML dokumentu je obsaženo v jednom jediném tzv. kořenovém elementu. Definice typu dokumentu (DTD) je úplná, deklaruje-li všechny značky použité v XML dokumentu a definuje-li i správně jejich význam. Především nesmí obsahovat více než jednu definici žádného z elementů 2 nebo více atributů stejného jména v rámci jednoho elementu. Správně utvořený XML dokument, který obsahuje syntakticky správnou a úplnou definici typu dokumentu a splňuje také všechny pravidla definovaná v DTD, nazveme platným (valid) XML dokumentem. 1.7 Model XML dokumentu Správně utvořený XML dokument se obvykle modeluje jako uspořádaný ohodnocený strom [5], kde každý vrchol přísluší k jednomu ze sedmi definovaných typů (element, atribut, komentář,... ). Jednotlivé vrcholy představují instance elementů určitého typu, hrany pak znamenají vztah otec-syn mezi elementy. Textový obsah elementů je reprezentován dalším uzlem, který modelován jako synovský uzel příslušného elementu. 2 Jestliže je některý z elementů v dokumentu obsažen na více místech, musí mít vždy stejnou strukturu bez ohledu na kontext svého výskytu! 8

15 ZÁKLADY XML Definice 1 XML strom T je uspořádaný orientovaný a ohodnocený strom T = (Σ, N, E, t), kde Σ je konečná abeceda, N resp. E jsou množiny uzlů resp. hran stromu a t N značí kořenový element stromu. Pro každý uzel u N platí: u je asociován se značkou l (značeno l(u) Σ), u je asociován s typem uzlu t(u), u je asociován s textovou hodnotou v(u), synovské uzly u jsou řazeny zleva doprava, pořadí mezi jednotlivými syny u nazýváme lokálním pořadím (značeno ), úplné uspořádání (značeno ) všech uzlů v dokumentu je dáno pořadím uzlů při preorder průchodu stromu T, hloubka uzlu u, h(u) je definována jako počet všech hran na cestě z kořene t do uzlu u. Například XML dokument uvedený na obrázku 1 můžeme tedy modelovat následovně: kontakt jméno mobil tel Obrázek 2: Model dokumentu kontakt.xml z příkladu 1. Tento model používá jako výchozí formalismus většina XML dotazovacích jazyků (viz např. [4, 13]) i programových rozhraní pro přístup k XML dokumentům (DOM, SAX). Drobné odlišnosti můžeme najít především v ohodnocení uzlů, případně reprezentaci hodnot elementů. 9

16 DOTAZOVACÍ JAZYKY 2 Dotazovací jazyky 2.1 Vznik XML dotazovacích jazyků Jedním z hlavních cílů databázových systémů je zpřístupnění potenciálně velmi rozsáhlých souborů dat takovým způsobem, aby uživatel nebo program, který je bude dále zpracovávat, nebyl závislý na jejich reprezentaci. Uživatel by dokonce ani neměl znát detaily fyzického uložení dat, aby nedocházelo k nežádoucí interakci, pokud by bylo třeba struktury uložení dat nějakým způsobem modifikovat. V klasických relačních databázích je tento problém vyřešen zavedením logického schématu veškerá data jsou rozdělena do tabulek a vztahy mezi nimi jsou modelovány pomocí logických propojení. Jednotlivé charakteristiky dat (s předem pevně stanoveným oborem hodnot) tvoří sloupce tabulky, řádky určují jednotlivé záznamy. Takto silně strukturovaná data pak poskytují dobrý základ pro jejich další efektivní zpracovávání. S rozvojem Internetu však vzniká mnohem rozmanitější informační prostředí pokrývající širokou škálu různých vzájemně nesouvisejících dokumentů, výstupů programových aplikací a uživatelských dat, to vše s různým stupněm složitosti i rozdílnou formou. Část z těchto informací tvoří nestrukturovaná data (např. některé obrazové nebo zvukové vzorky), jiné naopak nějakou strukturu mají, i když třeba ne explicitně danou a pravidelnou jako v případě relačních databází. Takový typ dat označujeme jako semi-strukturovaná data [2]. Pro vyhledávání, aktualizaci, případně vytváření nových dat nezávisle na jejich reprezentaci v databázovém systému slouží dotazovací jazyky. Ideální by samozřejmě bylo mít jediný univerzální dotazovací jazyk, který by umožňoval efektivně získávat prakticky libovolné informace, strukturované i nestrukturované. Ukazuje se ale, že takový jazyk by byl zřejmě příliš složitý na to, aby s ním mohli pracovat i nespecializovaní uživatelé nebo naopak příliš obecný a těžkopádný, aby jej bylo možné efektivně implementovat. Postupem času se proto vyvinuly různé dotazovací jazyky s různými vlastnostmi pro nestrukturované, semi-strukturované a silně strukturované informace. Společným rysem vývoje všech používaných dotazovacích jazyků je směřování k vyšší formě abstrakce. Ačkoliv procedurální přístup k datům je většinou velmi efektivní, nutí uživatele k psaní netriviálních operací, často obsahující několik úrovní cyklů. Odladění takového dotazu pak může být velice náročné. Deklarativní jazyky naproti tomu umožňují uživateli vyjádřit pouze požadovaný výsledek operace, konkrétní realizaci (sestavení skutečného plánu vyhodnocení dotazu) přenášejí na databázový systém. Výhodou je, že databázový systém může využívat informace o fyzickém uložení dat, včetně dynamických indexů pro urychlení přístupu k nim. Příkladem takového jazyka pro práci se silně strukturovanými daty je jazyk SQL, pro nestrukturovaná data jsou to pak např. regulární výrazy. 10

17 DOTAZOVACÍ JAZYKY 2.2 Požadavky na XML dotazovací jazyky Jazyky pro práci se semi-strukturovanými daty se stále ještě poměrně výrazně vyvíjejí. Silnou množinu tvoří právě jazyky zaměřené právě na XML. Jednotlivé pracovní skupiny vypracovaly seznam hlavních vlastností, které by měl XML dotazovací jazyk splňovat. Jednoduchost a snadná pochopitelnost jazyk by neměl být zbytečně komplikovaný a měl by být v krátké době srozumitelný alespoň pro ty uživatele, kteří již nějaký dotazovací jazyk, byt v jiném kontextu, používali. Syntaxe by měla být dostatečně jednoduchá na zápis, ale měla by být i dobře čitelná. Především to platí pro základní a často používané konstrukce. Zvláštní důraz se obvykle také klade na podobnost s SQL. Deklarativní přístup XML dotazovací jazyk by měl umožňovat hlavně podrobný a přesný popis požadovaných dat. Uvádění konkrétního postupu získání výsledku je pro mnoho uživatelů zbytečně obtížné. Tradiční procedurální přístup nevyhovuje také kvůli špatné škálovatelnosti systému při větších objemech dat. Robustní schéma pro adresování elementů předpokládá se, že zpracovávané dokumenty prochází postupným vývojem, že se s postupem času mění nejen jejich obsah, ale že se v menších krocích obměňuje i jejich struktura. XML dotazovací jazyk by proto měl být natolik obecný, aby bylo možné abstrahovat od méně podstatných rozdílů ve struktuře dat. Není např. výhodné, aby dotaz na autora dokumentu a jeho ovou adresu závisel na dalším obsahu dokumentu. Proto je vhodné, aby dotaz neobsahoval více kontextově závislé informace, než je bezpodmínečně nutné. Jednoznačné adresování elementů, vzhledem k pořadí, v jakém jsou uvedeny ve zdrojovém XML dokumentu rozdělení XML dokumentu na jednotlivé elementy nemusí vždy poskytovat dostatek informací, které potřebujeme k zadání dotazu. Struktura XML např. nezakazuje použití nějakého elementu víckrát v rámci téhož nadřazeného elementu. Můžeme tedy např. uvést autory článků a jejich ové adresy tak, že je v textu jednoduše uvedeme za sebou v rámci stejného elementu. Informaci, která ová adresa patří kterému autorovi, pak nelze zjistit jinak, než zkoumáním pozic elementů ve zdrojovém textu dokumentu. Je tedy vhodné, abychom v navrhovaném dotazovacím jazyce dokázali vybrat elementy podle globálního pořadí (např. druhou kapitolu knihy), případně podle lokálního pořadí ( ovou adresu uvedenou bezprostředně za hledaným autorem). Filtrování vybraných elementů a atributů podle zadaných kriterií výběr elementů a atributů samozřejmě nemusí záviset jen na struktuře dokumentu, ale může záviset i na jeho obsahu. Vybrané elementy by navíc měly zachovávat původní strukturu a pořadí uvedené v dokumentu. 11

18 DOTAZOVACÍ JAZYKY Flexibilita výstupního formátu narozdíl od tradičně silně strukturovaných dat u XML vzniká problém s množstvím různých způsobů, jak lze nějakou informaci vyjádřit. Uživatel tak často potřebuje změnit strukturu získaného výsledku, tj. mít možnost transformace částí XML dokumentů v jiné, případně moci vytvářet zcela nové, jinak strukturované údaje. Vlastní datový model všechny vstupní informace pro zpracování dotazu by měly odpovídat určenému datovému modelu. Navrhovaný jazyk by navíc měl být uzavřený nad daným datovým modelem, tj. vstupní i výstupní informace všech výrazů jazyka musí být vyjádřitelná pouze prostředky daného datového modelu, bez použití dalšího aparátu. Dotazy do dat, která nejsou obecně XML daty, jsou možné pouze za předpokladu, že existuje jednoznačné mapování do datového modelu jazyka. Dotazování do XML dat bez DTD v současné době je dispozici velké množství XML dokumentů bez explicitně určené struktury, je proto vhodné, abychom mohli navrhovaný dotazovací jazyk používat i při práci s obecnými XML daty. Pokud naopak DTD nebo schéma dokumentu existuje, měl by jej dotazovací jazyk využívat. Dotazování do kolekcí XML dokumentů jazyk by měl také umožňovat práci s několika dokumenty současně, zvolené adresování by mělo podporovat odkazy na elementy v rámci jednoho dokumentu stejně jako odkazy mezi různými dokumenty. Dobře definované chybové stavy při zpracování dotazu mohou nastat nejrůznější chyby, např. syntaktické chyby, nedostupnost externích funkcí, chyby vzniklé při průchodu strukturou dokumentu atd. Je potřeba přesně vědět, které chyby a za jakých okolností mohou nastat. 2.3 Historické XML dotazovací jazyky Ačkoliv je většina zmiňovaných požadavků na XML dotazovací jazyk poměrně logická, při bližším zkoumání narazíme u jednotlivých pracovních skupin na velmi rozdílné názory nejen ve způsobu řešení, ale často i na rozpory v tom, zda je daný požadavek vůbec nutný. Typickým sporným požadavkem je např. možnost konstrukce zcela nových elementů a uzavřenost nad daným datovým modelem. Někteří autoři [18, 8] takovou vlastnost považují za úplně základní vlastnost jazyka a uvádějí množství konstrukcí, které to vyžadují (dotazy fungující nad výsledkem nějakého poddotazu nebo funkce). Naproti tomu další skupina [9] už tento požadavek nevidí jako zásadní, naopak uvažuje využití jazyka v širším kontextu (např. v aplikacích, které pracují s objektovým modelem dokumentu [7]) zvažují spíše zpřístupnění dalších detailů (identifikátory elementů 12

19 DOTAZOVACÍ JAZYKY apod.), které jsou využitelné při složitější modifikaci nebo transformaci dokumentu. Jiní dokonce navrhují tento bod úplně vypustit a ponechat jen nestrukturovanou textovou podobu výstupu nebo namísto toho navrhují konstrukce, které dovolují předepsat způsob, jakým je datový model výsledku do výstupu serializován [10]. Sporné body vznikají mimo jiné i tím, že u dotazování nad XML se scházejí tři odlišné myšlenkové proudy, z nichž každý vychází z jiné metodiky a každý je zaměřen na jinou aplikační oblast XML-QL První z úspěšnějších XML dotazovacích jazyků pocházejí z oblasti klasických relačních databází a zaměřují se především na splnění klasických cílů správy dat obsluhu rozsáhlých souborů dat, integraci dat z různých zdrojů a definice nových pohledů na existující data. Asi nejvýraznějším zástupcem dotazovacího jazyka této skupiny je XML-QL [13]. V XML-QL se dotazy skládají ze tří hlavních částí: z výběrového vzoru, filtrovacích podmínek a zpětného konstruktoru. Informace přenášené mezi těmito jednotlivými vrstvami jsou modelovány jako klasické nestrukturované relace, navíc bez definovaného uspořádání. Všimněme si, že už to, samo o sobě, porušuje požadavek na zachování struktury dokumentu při filtrování elementů. V XML-QL nicméně lze takový požadavek v určitých případech splnit s pomocí hnízděných dotazů. Představme si například seznam literatury uložený jako XML dokument, elementy označující jednotlivé knihy jsou řazeny za sebou, obsah elementů tvoří informace o názvu knihy, autorovi, nakladateli atd. Pokud bychom chtěli získat všechny dvojice názevautor, musíme využít vázaných proměnných uvnitř vnořeného dotazu podobným způsobem jako např. v SQL: CONSTRUCT <výsledky> { WHERE <bib> <kniha> <název>$n</název> </kniha> CONTENT_AS $k </bib> IN CONSTRUCT <výsledek> <název>$n</název> { WHERE <autor>$a</autor> IN $k CONSTRUCT <autor>$a</> } </výsledek> } </výsledky> 13

20 DOTAZOVACÍ JAZYKY Operátor CONTEXT AS asociuje proměnnou k s vybraným elementem kniha. Vnitřní klauzuli WHERE pak využijeme ke spojení všech elementů autor s aktuálním elementem kniha. Zajímavou konstrukci XML-QL představují také tzv. skolemovské funkce. Skolemovská funkce je speciální funkce, která svým parametrům přiřazuje unikátní identifikátor. Vtip je v tom, že mapování je ale vždycky stejné, tj. stejným argumentům skolemovská funkce musí vždy přiřadit stejný identifikátor. Skolemovské funkce tak lze využívat např. k seskupování záznamů, aniž bychom potřebovali explicitní operátor (analogický operátoru GROUP BY známému z SQL). Pokud bychom např. potřebovali vyhledat v seznamu literatury všechny knihy a jejich autory, můžeme použít následující dotaz: CONSTRUCT <výsledky> { WHERE <bib> <kniha> <název>$n</název> <autor> <příjmení>$p</příjmení> <jméno>$j</jméno> </autor> </kniha> </bib> IN bib.xml CONSTRUCT <výsledek ID=autor($p,$j)> <název>$n</název> <autor> <příjmení>$p</příjmení> <jméno>$j</jméno> </autor> </výsledek> } </výsledky> Adresování XML elementů a atributů je v XML-QL řešeno klasicky s využitím regulárních cest podobně jako u regulárních výrazů, vybrány jsou ty elementy a atributy, které splňují (match) předepsaný vzor: CONSTRUCT <výsledky> { WHERE <(bib)+.kniha><název>$n</název></> IN bibliotéka.xml, CONSTRUCT <název>$n</název> } </výsledky> 14

21 DOTAZOVACÍ JAZYKY Ve výše uvedeném případě, by se ve tedy výsledku objevily všechny názvy knih ze seznamu, který může být libovolně zanořen v seznamu jiném. Pro navigaci v XML dokumentu bez známého schématu lze využívat velmi obecné konstrukce, tzv. proměnné pro značky. Od vázaných proměnných se liší především tím, že se vztahují na metadata, ne k vlastnímu obsahu dokumentu. Omezující podmínky na ně lze ale lze klást prakticky stejné jako na normální vázané proměnné. Díky tomu můžeme psát i velmi vágní dotazy typu: najdi v dokumentu všechny elementy s názvem končícím na or, které obsahují jméno Petr. Zápis takového dotazu v XML-QL může vypadat následovně: CONSTRUCT <bib> { WHERE <bib><kniha> <$a>petr</> </kniha></bib> IN bibliotéka.xml, $a LIKE *or CONSTRUCT <kniha><$a>petr</></kniha> } </bib> Všimněme si obecné ukončovací značky </>. Podobně jako v předchozím případě nevíme přesnou strukturu dokumentu v místě nalezení vzoru, konec značky proto musíme psát ve zkráceném neutrálním zápisu Lorel Z prostředí objektově-orientovaných databází pochází dotazovací jazyk Lorel [15]. Principy, které jsou v něm uplatňované, vychází především z požadavků na uložení obecně semi-strukturovaných dat a potřeby perzistentního ukládání objektů. Syntakticky spíše připomíná SQL nebo jeho objektovou variantu, jazyk OQL. S podivem je, že i přes rozdílnou syntaxi řeší řadu problémů v podstatě stejným způsobem, at už jde o adresování elementů s pomocí regulárních výrazů, skolemovské funkce, vázané proměnné nebo proměnné pro značky. Mírně odlišný je způsob vázání jednotlivých elementů, který je explicitní, podobně jako ztotožnění objektů v OQL. Pokud bychom například chtěli získat všechny knihy, které se vyskytují v knihkupectví i v knihovně a porovnat půjčovné s cenou knihy, dotaz v Lorelu by mohl vypadat následovně: select xml(srovnání-cen:{ select xml(srovnání-cen: { název: an, autor: aa, cena: bc, půjčovné: ap } 15

22 DOTAZOVACÍ JAZYKY from bib.kniha a, a.název an, a.autor aa, a.půjčovné ap, knihovna.položka b, b.název bn, b.autor ba, b.cena bc where an = bn and aa = ba) }) Vstupní adresu elementů prvního dokumentu představují hnízděné elementy bib a kniha, vstupní adresu druhého představují hnízděné elementy knihovna, položka. Explicitní vázací podmínka pak provede operaci spojení (join) nad obsahem elementů název a autor obou dokumentů XQL Výrazně jiné rysy má naproti tomu jazyk XQL [14], u kterého byly při návrhu požadovány i další vlastnosti, např. možnost integrace s jazyky pro transformaci XML dat. Důraz je kladen především na přehlednou adresaci elementů, fulltextové prohledávání, prohledávání závislé na struktuře dokumentu (zapouzdření v jazyku XSL) a možnost různých projekcí XML dat (například HTML reprezentací dokumentu). Prohledávání a adresace XML dokumentu připomíná spíš navigaci v adresářové struktuře souborových systémů. Filtry nemají vlastní klauzuli, namísto toho jsou umístěny lokálně k části dat, kterou omezují. Následující dotaz například vybere všechny elementy autor, které se vyskytují kdekoliv v obsahu elementu kniha (tj. v libovolném podelementu mezi počáteční a koncovou značkou), u kterého je navíc uveden atribut stav s hodnotou nová : document( )/bib/kniha[@stav = nová ]//autor Elegantně jdou také vyjadřovat dotazy, ve kterých je u výsledku potřeba zachovávat pořadí dané v XML dokumentu. Např. první příklad uvedený u XML-QL, vyhledání dvojic název-autor, by šel v XQL zapsat následovně: document( )/bib->výsledky { kniha->výsledek { název autor } } Naopak mnoho jiných konstrukcí, které předchozí jazyky nabízejí, v XQL není vůbec k dispozici. Nelze například výsledky sdružovat podle elementů nebo je třídit. 2.4 XPath Jazyk XPath [11] je dnes patrně nejpoužívanějším a nejčastěji implementovaným XML dotazovacím jazykem. Syntakticky a ideově je podobný především jazyku XQL, ovšem narozdíl od něj se jazyk XPath specializuje na problémy adresace a výběru elementů a atributů XML dokumentu. Tento způsob práce s XML daty pak rozvíjejí současné pokročilejší jazyky pro práci s XML, především mnohem komplexnější XML dotazovací jazyk XQuery (viz 2.5) a rodina transformačních jazyků XSL. 16

23 DOTAZOVACÍ JAZYKY Základní adresace XPath Základním stavebním prvkem jazyka XPath je, podobně jako v XQL, posloupnost jmen názvů elementů a atributů seřazených tak, jak jsou jednotlivé elementy v sobě hnízděny. Takovou posloupnost budeme nazývat jednoduchá cesta jmen. Zobecněnou cestou jmen pak míníme konstrukci, kde v jednoduché cestě jmen nahradíme některá jména atributů nebo elementů zástupnými znaky: * pro libovolné jméno, // pro přechod na libovolného potomka, případně.. pro přechod na otcovský element. Je dobré si uvědomit, že cesty jmen představují jen posloupnosti názvů elementů a atributů. Konkrétní cesty v grafu XML dokumentu (tedy posloupnosti konkrétních uzlů) nazýváme jejich instancemi. Ke každé cestě jmen (jednoduché i zobecněné) tedy může v dokumentu existovat nula, jedna nebo více jejích instancí. Např. cesta /kontakt/jméno/tel/mobil má v XML dokumentu na obrázku 1 jednu instanci, naproti tomu cestě /kontakt/jméno/tel/práce v daném dokumentu neodpovídá žádná instance. Množinu všech elementů nebo atributů, do kterých se dostaneme přechodem po dané cestě jmen ve stromu dat, budeme nazývat cílovou množinou cesty jmen Zápis cest jmen Každou cestu jmen v jazyce XPath můžeme složit z jednotlivých kroků, jejichž vyhodnocením zleva-doprava dostaneme uzly tvořící cílovou množinu. Každý krok je přitom vyhodnocován s ohledem na výsledky předchozích podvýrazů, které udávají kontext daného kroku. Popis jednotlivých kroků je dán: osou výrazu, testem na jméno nebo na typ uzlu, nepovinnými predikáty. Osa výrazu je specifikována strukturálním vztahem mezi uzly požadovanými v daném kroku a uzly aktuálního kontextu je to množina jen takových uzlů, které daný vztah splňují. Test na jméno nebo na typ uzlu pak určuje, které uzly v rámci dané osy mají být vybrány. Uvedením dodatečných predikátů můžeme výběr ještě dále zúžit jen na ty uzly, které mají ještě nějaké další požadované vlastnosti. Obecná syntaxe pro zápis jednoho kroku cesty je následující: jméno-osy :: jméno-nebo-typ-uzlu [ predikát1 ] [ predikát2 ]... XPath definuje poměrně velké množství strukturálních vztahů, které můžou definovat osy v kroku cesty jmen, ovšem ne všechny musí nutně každá implementace podporovat. Uved me proto jen několik základních os: 17

24 DOTAZOVACÍ JAZYKY self osa obsahující jen aktuální kontextový uzel, attribute osa obsahující všechny atributy aktuálního kontextového uzlu, pokud kontextový uzel není elementem, osa je prázdná, child osa obsahující synovské elementy aktuálního kontextového uzlu, descendant resp. varianta descendant-or-self osa obsahující všechny potomky aktuálního kontextového uzlu resp. osa obsahující všechny jeho potomky i samotný kontextový uzel, ancestor resp. varianta ancestor-or-self osa obsahující všechny předky aktuálního kontextového uzlu resp. osa obsahující všechny jeho předky i samotný kontextový uzel. Každý uzel na dané ose pak můžeme dále přesněji specifikovat jménem (zástupnému znaku * vyhovuje jakékoliv jméno) nebo typovým rozlišením (viz sekci 1.7): node() pro libovolný uzel, text() pro textový uzel, comment() pro komentář atd. Zápis dotazu, který např. vybere všechny elementy autor knih v knihovně, u nichž je uveden atribut stav s hodnotou nová, by v XPath mohl vypadat následovně: /child::bib/child::kniha[attribute::stav = nová ]/descendant:: autor Lze psát ale i mnohem obecnější dotazy. Např. následující dotaz vybere všechny syny elementů autor, kteří mají za předka element book: /descendant::autor/child::*[ancestor::book] Zkrácená forma zápisu Ačkoliv je syntaxe XPath přesnější a obecnější předchozí zápisy, je také bohužel delší a méně přehledná. Proto je možné u některých konstrukcí využívat i zkráceného zápisu, který je mnohem jednodušší a v podstatě odpovídá syntaxi XQL. Pro mapování do standardního zápisu stačí jen několik pravidel: v každém kroku považujeme prefix child:: za implicitní, vynecháme-li jej, bude automaticky prohledávána osa child, prefix attribute:: můžeme ve zkráceném zápisu nahradit krok cesty self::node() můžeme zapsat jako., krok cesty parent::node() můžeme zapsat jako.., 18

25 DOTAZOVACÍ JAZYKY root() autor název* jméno příjmení Obrázek 3: Příklad dotazu XPath s korelovanými cestami jmen. konstrukci /descendant-or-self::node()/child::jméno můžeme zkráceně zapisovat jako //jméno. Např. zkrácený zápis výrazu:.//kniha[@stav]/../bib/text() tedy chápeme jako ekvivalent self::node()/descendant-or-self::node()/child::kniha[ attribute::stav]/parent::node()/child::bib/child::text() Standardní i zkrácený zápis je samozřejmě možné libovolně kombinovat, dokonce i v jednotlivých krocích jednoho dotazu Korelované cesty jmen Specifickou třídu dotazů XPath tvoří dotazy cestami jmen uvedenými v podmíněných výrazech, tzv. korelované cesty jmen. Pro tyto dotazy není cílová množina vybírána přímo, ale na základě složitějších strukturálních vztahů v konkrétním dokumentu. Např. nová and //autor[ jméno= Karel and příjmení= Čapek ] ]/název tento dotaz vybere všechny elementy název elementu kniha, u kterého je uveden atribut stav s hodnotou nová a u kterého se zároveň v podstromu vyskytuje element autor s podelementy jméno a příjmení s danými hodnotami. Dotaz se vlastně skládá z několika cest: //kniha/@stav, //kniha//autor/jméno, //kniha/autor/příjmení a //kniha/název. Tyto cesty však na sobě nejsou 19

26 DOTAZOVACÍ JAZYKY vzájemně nezávislé z DTD může například vyplývat, že má-li autor uvedeno jméno, musí mít uvedeno i příjmení. Díky hnízděným závislostem lze modelovat korelované cesty jmen jako jednoduché stromové vzory. Výběrový vzor pro výše uvedený dotaz je znázorněn na obrázku 3. Korelované cesty tvoří jednu z nejpoužívanějších konstrukcí XPath. Důležité jsou zejména pro transformační jazyky XSL, které kromě výrazů XPath nepoužívají žádné další adresování elementů a atributů v XML dokumentech. 2.5 XQuery Jazyk XQuery je vyvíjen v rámci konsorcia W3 jako univerzální XML dotazovací jazyk. Přestože se na jeho návrhu pracuje již několik let, nemá zatím ještě definitivní podobu a je zatím diskutován pouze v pracovních verzích. Jeho základy jsou nicméně postaveny na společných principech všech doposud diskutovaných jazyků, především osvědčených modelů dotazů Lorelu, XML-QL, XPath a Quilt [16]. Základem XQuery jsou konstrukce FOR-LET-WHERE-RETURN (FLWR), které představují analogii základní stavby SQL dotazů. Klauzule FOR využívá adresování jazyka XPath k svázání hodnot jedné nebo více proměnných s uzly v XML dokumentech. Výsledkem vyhodnocení každého výrazu XPath je množina uzlů XML dokumentu, klauzule tedy produkuje posloupnost n-tic všech takových ohodnocení proměnných, které splňují uvedené výrazy XPath. Klauzule WHERE specifikuje další dodatečné podmínky, které musí vytvořené n-tice splňovat. S pomocí získaných hodnot proměnných pak v klauzuli RETURN lze vygenerovat nový XML dokument (nebo jeho část). Klauzule LET je jen syntaktickým cukrem konstrukce pouze sváže proměnnou s nějakým podvýrazem XQuery (typicky s nějakou cestou XPath). Narozdíl od klauzule FOR tedy nepředstavuje posloupnost n-tic všech ohodnocení proměnných, ale pouze hodnotu daného podvýrazu. Následující dotaz např. vybere všechny různé elementy kniha ve specifikovaném dokumentu pokud je autorem Karel Čapek a pokud stojí víc peněz než je průměr. Ze seznamu takových knih je pak vytvořen nový úsek XML dokumentu: for $b in distinct document( )//kniha, $a in $b/autor let $c in document( )//cena where $a/jméno = Karel and $a/příjmení = Čapek and avg($c) < $b/cena return <výsledek> $b </výsledek> Syntaxe XQuery je opravdu hodně bohatá a jazyk jako takový je mimořádně komplikovaný. Kromě FLWR výrazů a výrazů jazyka XPath obsahuje také kvantifikované 20