DIPLOMOVÁ PRÁCE. Petr Melichárek Analytické zpracování XML dokumentů

Transkript

1 Univerzita Karlova v Praze Matematicko-fyzikální fakulta DIPLOMOVÁ PRÁCE Petr Melichárek Analytické zpracování XML dokumentů Katedra softwarového inženýrství Vedoucí diplomové práce: Prof. RNDr. Jaroslav Pokorný, CSc. Studijní program: Informatika, Softwarové systémy 2007

2 Chtěl bych poděkovat vedoucímu této diplomové práce, kterým byl Prof. RNDr. Jaroslav Pokorný, CSc., za mnoho užitečných rad při psaní této práce a několikanásobné pečlivé přečtení celého textu. 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 a jejím zveřejňováním. V Praze dne 3. prosince 2007 Petr Melichárek 2

3 Obsah Úvod 5 1 OLAP a XML OLAP Analytické konstrukce XML Rozdíly OLAP a XML Problémy analytického zpracování dat v XQuery Jazyk XQuery Nedostatky jazyka XQuery Rozšíření jazyka XQuery Implementace analytických konstrukcí Databáze exist Konstrukce Group by Konstrukce Roll up Konstrukce Cube Praktické testy Testovací prostředí Group by Roll up Cube Závěr 54 Literatura 55 A Popis přiloženého CD 56 B Instalace 57 3

4 Název práce: Analytické zpracování XML dokumentů Autor: Petr Melichárek Katedra (ústav): Katedra softwarového inženýrství Vedoucí diplomové práce: Prof. RNDr. Jaroslav Pokorný, CSc. vedoucího: Abstrakt: V této práci se zabýváme rozšířením jazyka XQuery o analytické konstrukce známé z jazyka SQL group by, roll up a cube. Navíc zavádíme novou konstrukci topologický roll up. Implementačním prostředím je nativní XML databáze exist, kterou jsme rozšířili o modul obsahující zmíněné konstrukce. Při dotazování nad dokumenty databáze v jazyce XQuery tak můžeme použít implementované konstrukce jako uživatelské funkce. Testování ukázalo, že funkce jsou využitelné v praxi, a to i na velkých XML dokumentech a pro složité dotazy. Klíčová slova: Analytické zpracování, XML, OLAP, group by, roll up, cube Title: Analytical Processing of XML documents Author: Petr Melichárek Department: Department of Software Engineering Supervisor: Prof. RNDr. Jaroslav Pokorný, CSc. Supervisor s address: Jaroslav.Pokorny@mff.cuni.cz Abstract: In this diploma thesis we present XQuery analytic extension containing clauses well known from SQL language group by, roll up and cube. In addition we introduce new clause, called topological roll up. The native XML database exist is an environment for the extension implementation. We add a module, containing earlier mentioned clauses, to the exist database. We can use implemented clauses as user defined functions in XQuery language for querying database s documents. Tests have proved that functions are useful in practice. Even for large XML documents and complex queries. Keywords: Analytical processing, XML, OLAP, group by, roll up, cube 4

5 Úvod Značkovací jazyk XML (Extensible Markup Language) [9], který vznikl pro potřeby elektronického publikování a snadnou výměnu dat, získává v posledních letech na stále větší oblibě. Svědčí o tom jeho použití v nejrůznějších oblastech: od zdravotní péče přes geologii až po elektronické obchodování. Navzdory velmi širokému použití XML existuje jen málo nástrojů pro analýzu XML dat. Při analýze se můžeme na XML dokumenty dívat dvěma způsoby. Buď jako na sémanticky bohatý textový dokument, nebo na semistrukturovaný dokument. V současné době je běžnější první způsob a jsou využívány poznatky z vyhledávání informací (například vyhledávání klíčových slov v textu). Jak uvádí Bordawekar a Lang [1], pro semistrukturovaná data by bylo vhodné použití OLAP (Online Analytical Processing), které je známé z relačních databází. Bohužel tradiční OLAP se hodí pouze na strukturovaná data a při používání XML dokumentů jsme tak ochuzeni o zajímavé možnosti (seskupování dat na základě společných vlastností, strukturální agregace, analýzy trendů), které nabízí. Využít XML dokumenty při analýze dat lze třemi způsoby: 1. XML dokumenty jsou použity pro uložení výsledků analýzy provedené relační databází. 2. Vstupní data jsou uložena v XML dokumentech. Před jejich analytickým zpracováním jsou však data transformována (např. pomocí XSLT) do podoby vhodné pro OLAP zpracování. Výsledky analýzy mohou být poté uloženy do XML souborů. 3. XML dokumenty jsou použity jak pro uložení dat, tak pro jejich zpracování. V této diplomové práci se budeme zabývat posledním případem. Zaměříme se na konstrukce group by, roll up a cube, které jsou nejčastěji využívané pro analytické zpracování dat v relačních databázích. O tyto konstrukce se pokusíme rozšířit jazyk XQuery a provedeme praktické testy nad nativní XML databází exist [3]. V první kapitole povíme něco o OLAP, XML a základních analytických konstrukcích. V kapitole druhé představíme jazyk XQuery a seznámíme se s obtížemi při jeho použití pro analytické zpracování XML dokumentů. V třetí kapitole se podíváme na řešení některých problémů. V poslední kapitole se na základě měření a testů dozvíme, jak rychlá jsou naše navrhovaná řešení, a jestli jsou v praxi dobře použitelná. 5

6 Kapitola 1 OLAP a XML V této kapitole se seznámíme s OLAP a XML. Vysvětlíme, co tyto pojmy znamenají a jaké mají využití. Seznámíme se také se základními konstrukcemi pro analytické zpracování dat. 1.1 OLAP OLAP (Online Analytical Processing) je přístup k rychlému zjišťování odpovědí na analytické dotazy, které jsou ve své podstatě multidimenzionální. Typickou oblastí využití OLAP přístupu jsou obchodní zprávy o prodejích, marketingu, managementu, plánování rozpočtu, předpovídání trendů a podobně. Potřebná data jsou uložena v relačních databázích tak, aby bylo možno v co nejkratším čase vracet odpovědi na jednoduché dotazy a rychle provádět aktualizace záznamů. Tento přístup se však příliš nehodí pro složité analytické dotazy. Je potřeba postavit datové úložiště, které zohlední požadavky na analytické zpracování záznamů. Podle způsobu uložení dat v tomto datovém úložišti rozlišujeme OLAP na ROLAP (relační OLAP) data jsou uložena v tabulkách relační databáze, MOLAP (multidimenzionální OLAP) data jsou organizována pomocí multidimenzionálního datového modelu, a HOLAP (hybridní OLAP), který kombinuje předchozí dva přístupy. Nyní se blíže podíváme na ROLAP a MOLAP tak, jak jej popisuje J. Pokorný [6]. Uvažujme datové úložiště koncipované pro uchování dat o prodejích aut. Jistě zde budou existovat informace o prodejci, datu prodeje a typu auta. (nazveme je dimenze), které nám určují hodnoty (zvané fakty) jako je prodané množství, cena apod. Dimenze obvykle tvoří hierarchie, např. den měsíc rok, jejichž členy jsou vhodnými kandidáty pro agregaci dat (faktů). Schéma uvedeného příkladu najdeme na následujícím obrázku. V terminologii OLAP nazýváme takové schéma jako hvězdicové schéma. O tvorbě schématu hovoříme jako o modelování Modelování pomocí tabulek a vztahů Základními používanými pojmy jsou fakty, dimenze a atributy. Dimenzionální schéma obsahuje popis jedné tabulky s víceatributovým klíčem, jde o tabulku faktů, a popisy tabulek, které se nazývají dimenzionální. Každá dimenzionální 6

7 Obrázek 1.1: Hvězdicové schéma tabulek. tabulka má jednoatributový klíč, který koresponduje právě s jednou komponentou klíče tabulky faktů. Atributy v dimenzionální tabulce slouží jako zdroj pro různá omezení formulovaná v dotazech. Hlavním předmětem zájmu jsou však fakty, které jsou modelovány neklíčovými atributy tabulky faktů. Výskyt každé takové hodnoty závisí na n-tici hodnot odpovídajících dimenzí. Tabulky obou typů lze chápat podobně jako v SQL. Uvažují se však libovolné kombinace hodnot dimenzí (prvky kartézského součinu odpovídajících domén hodnot). Ne pro každou je ale definován fakt. Nahlížíme-li na kartézský součin jako na reprezentaci multidimenzionální krychle, je to totéž, jako bychom řekli, že krychle je řídce obsazená. Dimenze obsahují spíše textové hodnoty a fakty jsou naopak většinou numerické. Protože je agregace většinou aditivní proces, je vhodné, aby fakty byly aditivní. Aditivita atributu znamená možnost sumarizovat jeho hodnoty vzhledem ke všem dimenzím. Pokud atribut není aditivní vzhledem k jedné nebo více dimenzím, nazýváme jej semiaditivní. Neaditivní atributy nejsou aditivní vzhledem k žádné dimenzi. I ty lze ale agregovat, například pomocí funkce průměr. Obrázek 1.2: Hvězdicové schéma tabulek s explicitními hierarchiemi. Dimenze mohou tvořit jisté hierarchie. Například čas může být chápán v hierarchii den, měsíc, rok. Tento přístup pak umožňuje chápat dimenzi jako cestu v grafu. Cesta zároveň ukazuje možnosti agregace faktů v souladu s členy hierarchie, např. prodej za den, měsíc atd. Hierarchie mohou být implicitní, jak zachycuje obrázek 1.1, nebo explicitní, jak je vidět z obrázku 1.2. Z obrázků je patrné, že první schéma vede k nenormalizovaným tabulkám, kdežto druhé 7

8 k normalizovaným. Pohyb nahoru v hierarchii se nazývá roll up, pohyb dolů drill down Modelování pomocí krychlí Multidimenzionální databáze může být založena i na jiném modelu než relačním. Musí však být navržena pro pružné zpracování velkých objemů dat, která jsou vzájemně vztažena a analyzována z různých perspektiv. Tyto perspektivy nazýváme dimenze. Potud se přístup neliší od modelování pomocí tabulek. Uvažujme příklad s prodejem automobilů, přičemž sledujeme počet prodaných kusů v závislosti na modelu auta, jeho barvě a roku prodeje. V relačním modelu bychom měli atributy model, barva, rok, které představují dimenze a atribut množství, jehož hodnoty by byly agregovány. Při modelování pomocí tabulek bychom tedy vytvořili tabulky pro modely automobilů, možná pro barvu a rok (v případě jejich dalších atributů) a následující tabulku faktů. PRODEJ(model, barva, rok, množství) Přidáme-li atributy prodejce a oblast, získáme další dimenze. O množině dat závisejících na n dimenzích říkáme, že je n-rozměrná. Při modelování pomocí krychlí se data místo v tabulce zobrazují pomocí vícerozměrných polí. V terminologii OLAP se také hovoří o datových krychlích, multidimenzionálních krychlích, či hyperkrychlích. Každá dimenze v poli odpovídá jedné dimenzi n-rozměrné množiny dat. Každý prvek v dimenzi (hodnota atributu v relačním přístupu) se nazývá pozice. Vícerozměrná data odpovídající nějaké kombinaci pozic jednotlivých dimenzí jsou umístěna v buňkách pole. Na obrázku 1.3 jde o hodnoty atributu množství. Obrázek 1.3: Agregace v podprostorech vícerozměrného pole. 8

9 1.2 Analytické konstrukce Představíme základní konstrukce pro analytické zpracování dat, které byly uvedeny v SQL 1999 [7]. Jako první ukážeme jednoduchou konstrukci group by. Následovat budou složitější konstrukce roll up a cube. Jak tyto konstrukce pracují, předvedeme vždy na krátkém příkladu. Všechny tři konstrukce jsou dobře známé pro práci nad relační databází. My se v dalších kapitolách pokusíme implementovat tyto konstrukce i pro použití nad XML dokumenty Group by Pomocí konstrukce group by lze seskupit záznamy, které mají stejné hodnoty ve vybraných sloupcích relační tabulky. Ke každé, takto vzniklé, skupině lze vypočíst agregáty nad hodnotami záznamů této skupiny. Použití konstrukce group by ukážeme na příkladu. Mějme následující relační tabulku T. A B C Tabulka 1.1: Příklad konstrukce group by relační tabulka T Nad touto tabulkou položme dotaz, který vytvoří skupiny na základě hodnot ve sloupcích A a B a pro každou skupinu sečte hodnoty ve sloupci C. select A, B, sum(c) from T group by A, B Výsledek si můžeme prohlédnout v další tabulce. A B C Tabulka 1.2: Příklad konstrukce group by výsledek dotazu V našem případě jsou ve výsledku zastoupeny všechny možné kombinace hodnot ze sloupců A a B. Obecně to neplatí a některé kombinace mohou chybět z důvodů neexistujícího záznamu s takovou kombinací hodnot v tabulce Roll up Konstrukce roll up funguje podobně jako konstrukce group by, ale navíc vrací agregované hodnoty pro hierarchii požadovaných sloupců. Funkci si ukážeme na příkladu. Mějme následující dotaz. 9

10 select A, B, C, sum(d) from T1 group by rollup (A, B, C) Výsledek bude obsahovat agregované hodnoty pro skupiny vytvořené na základě shodných hodnot ve sloupcích (A, B, C), (A, B), (A) a (). Stejný dotaz lze zapsat jako sjednocení dotazů s konstrukcí group by následovně. select A, B, C, sum(d) from T1 group by A, B, C union all select A, B, null, sum(d) from T1 group by A, B union all select A, null, null, sum(d) from T1 group by A union all select null, null, null, sum(d) from T1 Hodnoty null místo sloupců jsou použity proto, aby mohlo proběhnout sjednocení Cube Konstrukce cube vychází z konstrukce roll up, ale na rozdíl od ní vrací agregáty pro všechny kombinace vybraných sloupců. U konstrukce cube mluvíme o sloupcích jako o dimenzích. Také tuto konstrukci lze zapsat s použitím méně složité konstrukce. Uvažujme následující dotaz, který vrací součty hodnot ve sloupci D pro skupiny vytvořené na základě všech kombinací sloupců A, B, C včetně příslušných hierarchií. select A, B, C, sum(d) from T2 group by cube (A, B, C) Tento dotaz přepíšeme za využití konstrukce grouping sets, která zastupuje sjednocení dotazů s konstrukcí group by. Výsledný dotaz tedy vypadá následovně. select A, B, C, sum(d) from T2 group by grouping sets ( (A, B, C), (A, B), (A, C), (A), (B, C), (B), (C), () ) 1.3 XML Jazyk XML (Extensible Markup Language) je značkovací jazyk vyvinutý a standardizovaný W3 konsorciem [9]. Původním účelem bylo vytvořit jazyk pro snadný přenos informací mezi systémy. V dnešní době slouží jako univerzální datový formát a je využíván v nejrůznějších oblastech lidské činnosti. Jazyk XML je založen na starším značkovacím jazyce SGML. Ten však pro svou značnou složitost není příliš používán. Že je jazyk značkovací znamená, že uložená data mají u sebe informaci, která tato data popisuje. Protože je navíc jazyk XML rozšiřitelný (extensible), můžeme tyto popisy dat sami vytvářet dle potřeby. XML dokument může obsahovat následující části: elementy a atributy, entity, komentáře, instrukce pro další zpracování, sekce CDATA a deklaraci typu dokumentu (DTD). Blíže si popíšeme elementy a atributy, s kterými budeme dále pracovat. Element je tvořen počáteční a koncovou značkou. Název elementu je uzavřen mezi znaky <, > a zpravidla popisuje data, která obklopuje obsah elementu 10

11 (např. <jméno>jan</jméno>). Název musí začínat písmenem, podtržítkem nebo dvojtečkou a může pokračovat písmeny, číslicemi, pomlčkami, podtržítky, dvojtečkami a tečkami. Název nesmí obsahovat mezery. Obsahem elementu může být další element, smíšený obsah, znaková data nebo může být obsah prázdný. Elementy se smíšeným obsahem mohou obsahovat znaková data proložena elementy. Například: <odstavec> následuje <tučně>zvýrazněné</tučně> slovo </odstavec> Pokud je element prázdný, lze použít zápis <jméno />. Každý element může ve své počáteční značce obsahovat atributy, což jsou dvojice název atributu a hodnota. Hodnota atributu musí být vždy uzavřena do uvozovek. Například <zaměstnanec třída="1" />. Element nemůže obsahovat dva atributy se stejným názvem. XML dokument obsahuje právě jeden element, nazývaný kořen, který se neobjevuje v obsahu žádného jiného elementu. Pro ostatní elementy platí, že pokud je počáteční značka elementu v obsahu jiného elementu, pak koncová značka elementu je v obsahu téhož elementu. To znamená, že elementy jsou v sobě navzájem správně zanořeny (zahnízděny). Z toho vyplývá, že pro každý element s, který není kořen, existuje v dokumentu element r takový, že s je v obsahu r, ale není v obsahu žádného jiného elementu, který je v obsahu r. Element r nazýváme rodič elementu s, element s nazýváme syn elementu r. Když potřebujeme s XML dokumentem pracovat, musíme jej nějakým způsobem reprezentovat. K tomu se používají dva základní přístupy (modely): stromová reprezentace a událostmi řízený model. Stromová reprezentace DOM (Document Object Model) předpokládá reprezentaci dokumentu ve formě stromu. XML parser čte XML dokument a v paměti vytváří stromovou reprezentaci dokumentu. Tento přístup je vhodný, pokud potřebujeme zpracovávat dokument pomocí náhodného přístupu, neboť nad stromovou reprezentací máme k dispozici traverzovací funkce. Nevýhodou je velká prostorová náročnost. Událostmi řízený model SAX (Simple API for XML) převádí XML dokument na sled událostí. XML parser čte XML dokument a postupně generuje události reprezentující dokument (například začátek elementu, textový obsah, konec elementu,... ). Tento přístup najde uplatnění při sekvenčním zpracování XML dokumentu, neboť části dokumentu jsou přístupné pouze v době vyvolání události a nelze se tak vracet k předchozím částem dokumentu. Výhodou je malá paměťová náročnost. 1.4 Rozdíly OLAP a XML Tradiční OLAP používá multidimenzionální model s nezávislými dimenzemi, které tvoří kontext pro příslušné numerické míry a jejich agregaci. Dimenze mohou 11

12 tvořit hierarchie (např. časová dimenze může mít členy rok, čtvrtletí, měsíc, den a hodinu). Multidimenzionální OLAP se vyznačuje následujícími rysy: 1. Vstupní data jsou organizována do nezávislých dimenzí a numerických měr. 2. Adresování numerických měr odpovídá poli. 3. Ve výpočtech převažují strukturované agregační operace nad numerickými mírami: (a) mezi úrovněmi jednotlivých dimenzí (b) mezi dimenzemi Při zpracování XML dokumentů narazíme na zcela odlišné problémy než u tradičního OLAP. XML analýza se liší jak v datovém modelu, tak i ve způsobu dotazování. Nyní si ukážeme některé rozdíly Rozdíly v datovém modelu 1. Sémanticky bohatý obsah: Stromový datový model XML (DOM) pohlíží na XML dokumenty jako na stromy, jehož vnitřní uzly odpovídají elementům, listy odpovídají textovému obsahu a hrany vyznačují vztahy mezi entitami. Pro účely analýzy můžeme na vnitřní uzly XML stromu pohlížet jako na členy dimenzí, kde jejich rozsah je určen jejich rodičovským elementem, a na hodnoty v listech jako na odpovídající míry. V tomto modelu mají členové dimenzí mezi sebou vztah odpovídající hierarchické struktuře dokumentu. Na rozdíl od tradičního OLAP není rozdělení na dimenze a míry pevně dáno. Každý XML element může být spojen s množinou atributů, které nesou nějakou dodatečnou informaci, a tyto informace můžeme také využít pro analytické účely. Jinými slovy, některé dimenze mohou být analyzovány i jako míry. 2. Semistrukturovaný datový model: Na rozdíl od relačních dat mohou mít XML dokumenty nepravidelnou strukturu. Současně ale dokumenty odpovídají XML stromu s definovaným pořadím uzlů v něm. Kontext míry je určen hierarchií, ve které je zkoumán. V XML dokumentu se může míra vyskytnout ve více kontextech. Tedy operace nad mírou v jednom kontextu nemusí být proveditelná nad toutéž mírou v jiném kontextu. Navíc, mohou být míry sémanticky spřízněné díky danému pořadí uzlů v XML dokumentu. 3. Způsob adresování: Pro navigaci v abstraktním stromě, reprezentující XML dokument, používáme jazyk XPath. Ten umožňuje navigaci pomocí pěti různých os. Ať už po explicitních hranách (otec syn), nebo po implicitních hranách (hrany mezi sourozenci). Každý uzel XML stromu lze tedy adresovat mnoha způsoby, což je ve velkém kontrastu s OLAP adresováním. Ukážeme to na příkladu. Mějme následující strom reprezentující XML dokument a požadavek na získání elementu barva. 12

13 prodeje prodej1 prodej2 typ barva Cestu k požadovanému elementu lze v jazyce XPath vyjádřit například následujícími způsoby: (a) /prodeje/prodej2/barva (b) /prodeje/prodej1/following-sibling::prodej2/barva (c) //typ/parent::prodej2/barva 4. Nenumerické míry: Tradiční OLAP zahrnuje analýzu pouze numerických měr (zejména obchodních dat). Protože XML dokumenty obsahují i nenumerická data (např. řetězce reprezentující amino kyseliny v databázi genomů), je potřeba operací pracujících i nad těmito daty Rozdíly v charakteru dotazu 1. Dotazy závislé na pořadí: Datový model XML zahrnuje uspořádání uzlů dokumentu. Toto uspořádání je například využíváno jazykem XPath k určení prvního syna uzlu apod. Podobně ale také můžeme zkonstruovat dotaz pro analýzu takových množin dat, jejichž uspořádání má nějaký sémantický význam. 2. Obecnější sdružování dat: U typického OLAP přístupu jsou operace group by, roll up nebo cube prováděny nad hodnotami ze sloupců tabulek. Při analýze XML dokumentů však můžeme jednotlivé entity sdružovat také na základě atributů jejich cesty k nim. Atributy cesty mohou být specifikovány například XPath výrazem. 3. Dotazy na nenumerických mírách: Nenumerické (textové) míry mohou být použity ve dvou typech dotazů: (a) Ve strukturovaných dotazech, které zahrnují agregační operace nad textovými řetězci, jako je například zjištění maximální nebo průměrné délky řetězce. (b) V aproximativních dotazech, které zahrnují porovnávání řetězců s využitím určité podobnosti (například pomocí Levenshteinovy vzdálenosti). 13

14 Kapitola 2 Problémy analytického zpracování dat v XQuery V této kapitole se seznámíme s jazykem XQuery. Na motivačním příkladu si ukážeme, jaké operace bychom rádi s XML dokumenty prováděli, a které z nich nám jazyk XQuery umožní. Nakonec si popíšeme možná vylepšení a rozšíření jazyka, která by nám umožnila a usnadnila analytické zpracování XML dokumentů. 2.1 Jazyk XQuery Jazyk XQuery je dotazovacím jazykem a byl vyvinut W3C XQuery Working Group [10]. V současné době je standardem pro dotazování nad XML dokumenty. Datový model jazyka je založen na uspořádaných stromech, neboť XML data jsou přirozeně uspořádaná. Centrálním prvkem modelu je sekvence. Dotaz jako svůj vstup přijímá sekvenci atomických hodnot (založeny na primitivních typech XML Schema) a/nebo XML uzlů (element, atribut, text, dokument,... ) a výstupem je opět sekvence. XQuery je funkcionální jazyk a jako ostatní funkcionální jazyky sestává z prologu a těla. Výsledek dotazu je pak dán vyhodnocením výrazu těla v prostředí definovaném v prologu. Výrazem XQuery mohou být jednoduché výrazy jako primitivní konstanty, proměnné, aritmetické výrazy, volání funkcí, nebo výrazy vyjadřující cestu (XPath výrazy). Mohou ale také být kombinované, složené pomocí operátorů, funkcí a syntaktických konstrukcí. XQuery má bohatou podporu pro navigaci uvnitř vstupního XML dokumentu, kombinaci dat z několika vstupních XML dokumentů a generování XML struktur z jednoho nebo více XML vstupů XQuery výrazy Podívejme se blíže na výrazy, jež jazyk XQuery poskytuje. Konstanty a proměnné: "Novák", 156, $var Operace a funkce: x+y, fce(x,y) 14

15 Operace s typy: TYPESWITCH typ CASE... DEFAULT Kvantifikátory: EVERY/SOME proměnná IN výraz SATISFIES výraz Podmíněné výrazy: IF... THEN... ELSE Výrazy s cestami: //zaměstnanec[jméno="novák"]/plat Konstruktory: <zaměstnanec id="1"> FLWOR výraz: Patrně nejdůležitější výraz, který je obdobou select - from - where - order by dotazu v SQL. Jednotlivé části FLWOR výrazu jsou: Klauzule for, která generuje sekvence hodnot a tyto sekvence váže k proměnným dotazu. Tato klauzule hraje podobnou roli jako from klauzule v SQL. Klauzule let váže dočasné proměnné k výsledkům dotazu. Jistou obdobou jsou v SQL dočasné pohledy. Klauzule where obsahuje booleovský predikát, který omezuje vázání proměnných for klauzule. Tato klauzule má stejný význam jako where klauzule v SQL. Klauzule order by obsahuje seznam výrazů, které určují uspořádání výstupu FLWOR výrazu. Analogií v SQL je order by klauzule. Klauzule return specifikuje požadovaný XML výstup. Tato klauzule je obdobou select klauzule v SQL, ale umožňuje specifikovat mnohem bohatší struktury. Obecně může FLWOR výraz obsahovat libovolné množství for a let klauzulí následovaných volitelně jednou where klauzulí, volitelně jednou order by klauzulí a povinně jednou return klauzulí Funkce a typy Jazyk XQuery nám umožňuje kromě vestavěných funkcí (například id, name, distinct-values, min, max, sum, avg,... ) dodefinovat funkce vlastní. Ty jsou definovány v jazyce XQuery, jsou typované a mohou být rekurzivní. Přetížit lze jak vlastní funkce, tak funkce vestavěné. Typy v jazyce XQuery jsou založeny na typech XML Schema. Základními typy jsou například xs:boolean, xs:double, xs:float, xs:decimal, xs:string, xs:anyuri,... (xs značí jmenný prostor XML Schema /XMLSchema). Zvláštním typem je xdt:untypedatomic pro netypovaná data. Je odvozen od typu xdt:anyatomictype a obvykle se chová jako xs:string, pokud nedojde k implicitnímu přetypování (xdt = 11/xpath-datatypes). XQuery je silně typový jazyk, což znamená, že v případě nestejných typů proběhne implicitní přetypování, nebo je hlášena chyba. Jazyk také umožňuje 15

16 odvozování typů, ale jen za použití restrikce, a typovou substituci, takže do výrazu vyžadujícího typ T můžeme dosadit jeho podtyp T. Další vlastností jazyka je typová propagace, která však může vést ke ztrátě přesnosti. Pro práci s typy jsou v jazyce XQuery dostupné například následující operátory: cast as: Zpravidla se používá jen pro konstantní výrazy. Provádí se při běhu dotazu. castable as: Vrací hodnotu pravda tam, kde lze provést cast as. treat as: Provádí přetypování proti směru typové hierarchie (down casting). Cílový typ musí být odvozen od původního. Provádí se při překladu. instance of: Testuje, zda posloupnost odpovídá zadanému typu. 2.2 Nedostatky jazyka XQuery Jazyk XQuery je velmi vhodný na dotazování nad strukturovanými daty, neobsahuje však žádné pokročilé nástroje pro sdružování dat do skupin dle požadovaných podmínek. Nedostatky XQuery pro analytické zpracování XML dokumentů si předvedeme na krátkém příkladu. Mějme XML dokument s následující strukturou: <zákazník> <zákazník_id>001</zákazník_id> <jméno>john</jméno> <příjmení>smith</příjmení> <věk>30</věk> <stát>ma</stát> <země>usa</země> </zákazník> Nad tímto dokumentem nyní položíme dotaz na průměrný věk našich zákazníků dle státu a země. Dotaz v XQuery sestavíme dle vzoru doporučeného W3 konsorciem. for $z in distinct-values(//zákazník/země) for $s in distinct-values(//zákazník/stát) let $zs-skupina := //zákazník[země = $z and stát = $s] return if (exists($zs-skupina)) then <avg-věk země="{$z}" stát="{$s}"> { fn:avg($zs-skupina/věk) } </avg-věk> else () Pro srovnání ještě uvedeme tentýž dotaz na průměrný věk zákazníků v jazyce SQL. select země, stát, avg(věk) from zákazníci group by země, stát 16

17 Na první pohled je patrné, že dotaz v SQL je mnohem čitelnější. Protože má SQL vestavěnou podporu pro sdružování do skupin (operátor group by), můžeme jednoduše vybrat zemi, stát a průměrný věk sdružené do skupin dle země a státu. V XQuery musíme na totéž jít trochu jinou cestou a skupiny dle země a státu si vytvořit sami. Takový dotaz není pro uživatele jednoduchý ani na napsání, ani na pochopení. V dotazu vidíme iterace přes všechny různé kombinace zemí a států. Pro každou dvojici země-stát jsou vypočteni zákazníci, jejichž hodnoty země a státu souhlasí s daným párem. Pokud není sekvence zákazníků prázdná, je zkonstruován výsledek, v němž je uvedena příslušná země, stát a průměrný věk zákazníků. Navíc výsledky dotazu zapsaného v XQuery neodpovídají výsledkům dotazu zapsaném v jazyce SQL. Předpokládejme, že ne všechny země jsou rozděleny na státy. To znamená, že element <stát> může být prázdný, nebo zcela chybět. V SQL tomu odpovídá hodnota null. V případě dotazu v SQL by zákazníci bez uvedeného státu byli stále sdruženi dle země (a jako hodnota státu by byla uvedena hodnota null). Naproti tomu, uvedený dotaz v XQuery by takové zákazníky vynechal z výsledku, neboť proměnná $s iteruje pouze nad neprázdnými elementy. Pokud chceme tyto zákazníky vrátit do výsledku, musíme přeformulovat dotaz v XQuery následujícím způsobem. for $z in distinct-values(//zákazník/země) return ( for $s in distinct-values(//zákazník/stát) let $zs-skupina := //zákazník[země = $z and stát = $s] return if (exists($zs-skupina)) then <avg-věk země="{$z}" stát="{$s}"> { fn:avg($zs-skupina/věk) } </avg-věk>, let $zx-skupina := //zákazník[země = $z and empty(stát)] return if (exists($zx-skupina)) then <avg-věk země="{$z}" stát=""> { fn:avg($zx-skupina/věk) } </avg-věk> ) Takový dotaz již pak skutečně není jednoduchý a s požadavkem na sdružování do skupin dle většího počtu atributů by se stal již téměř nečitelným. Pro ostatní analytické operace jako je roll up nebo cube bychom museli použít ještě složitější konstrukce včetně uživatelsky definovaných funkcí. Nelze tedy očekávat, že uživatelé budou využívat jazyk XQuery k analytickým dotazům nad XML dokumenty. 17

18 2.3 Rozšíření jazyka XQuery Výše nastíněné potíže v posledních letech řešilo několik autorů. Navrhovaná řešení si jsou velmi podobná a spočívají v přidání nové konstrukce group by do jazyka XQuery. Liší se potom způsobem implementace této konstrukce. Například Bordawekar a Lang [1] uvádějí jako příklad jejich řešení následující dotaz. for $z in //zaměstnanec group by(//zaměstnanec/narozen) let $p := avg( $z/plat ) return <věkováskupina> <narozen> $z/narozen </narozen> <avgplat> $p </avgplat> </věkováskupina> Dotaz předpokládá existenci elementů zaměstnanec a jejich podelemtů pro rok narození zaměstnance (element narozen) a pro jejich plat (element plat). Výsledkem dotazu je potom průměrný plat zaměstnanců dle roku jejich narození. Autoři se také snaží o rozšíření jazyka XQuery o konstrukce, jež mají být analogií konstrukcí roll up a cube v SQL. Ukážeme si konstrukci roll up a její následné vylepšení pro potřeby analýzy XML dokumentů. var o, o1=oddělení for $r in //rozpočet group by rollup( //divize//skupina, //divize/$o//skupina, //divize/$o/$o1/skupina ) let $s := sum( $r/value() ), $n := $r/../name() return <úroveňskupiny> <jméno> $n </jméno> <celkovýrozpočet> $s </celkovýrozpočet> </úroveňskupiny> Dotaz předpokládá dokument, jenž obsahuje hierarchii divizí, oddělení a skupin. Nejvýše stojí divize (element divize), která obsahuje oddělení (elementy oddělení). Každé oddělení pak může obsahovat buď přímo skupinu (element skupina), nebo další oddělení. Každá skupina obsahuje informaci o svém rozpočtu (element rozpočet). Dotaz poté vrací jako výsledek rozpočet každé skupiny a sumy rozpočtů na vyšších úrovních. Nakonec ještě autoři zavádí konstrukci topologický roll up, která zjednodušuje zápis předchozí konstrukce roll up. Místo zápisu group by rollup(//divize//skupina, //divize/$o//skupina, //divize/$o/$o1/skupina) můžeme použít zkrácený zápis: group by topological rollup(//divize/$o/$o1/skupina) Obdobně lze definovat i konstrukce pro cube a topologickou cube. Další, kdo řeší rozšíření jazyka XQuery o konstrukci group by jsou Borkar a Carey [2]. Syntaxe se tentokrát mírně liší. Jako příklad použijeme dotaz na průměrný věk zákazníků, který již známe z předchozí části práce. 18

19 for $z in //zákazník group $z as $zs-skupina by $z/země as $zeme, $z/stát as $stat return <avg-věk země="{$zeme}" stát="{$stat}"> { fn:avg($zs-skupina/věk) } </avg-věk> Navrhovaná konstrukce má dvě části. V první je specifikováno, co se má sdružit do skupin a výsledná sekvence je svázána s proměnnou pro pozdější použití v dotazu. V druhé části je seznam atomických hodnot, dle kterých se tvoří skupiny, a také jejich svázání s proměnnými pro pozdější využití v dotazu. Implementací předchozích rozšíření se autoři dále nezabývají. Jiným typem práce, než byli předchozí zmíněné, je Grouping in XML [5]. Zde autoři nepřidávají do jazyka XQuery žádnou další konstrukci, ale řeší problém, jak efektivně vyhodnocovat sdružování do skupin zapsané dle návrhu W3 konsorcia. Nejdříve autoři zmiňují naivní variantu vyhodnocení pomocí vnořených cyklů, aby posléze představili své řešení, založené na stromové algebře. Podstatou je vytvoření stromu reprezentujícího dotaz a hledání svědeckých stromů z XML dokumentu, které odpovídají stromu dotazu. Další možný přístup zvolili autoři ve své práci Complex Group-By Queries for XML [4]. Nejdříve z částí XML dokumentu, které odpovídají dotazu, sestaví jeden velký strom a následně v tomto stromu slévají uzly a tvoří tak požadované skupiny. Autoři se také zaobírají dalšími věcmi známými z SQL pohyblivým oknem a podmínkou having u operátoru group by. My se v této práci vydáme trochu jiným směrem. Nebudeme rozšiřovat jazyk XQuery o další konstrukci, ale pokusíme se některá nastíněná vylepšení implementovat jako uživatelské funkce. Obecně bude vstupem funkcí identifikace entit, které budeme chtít sdružit do skupin, a specifikace parametrů, dle kterých se budou tyto skupiny tvořit. Výstupem pak bude fragment XML dokumentu, nad kterým se můžeme dále dotazovat. Konkrétní řešení si ukážeme v 3. kapitole. 19

20 Kapitola 3 Implementace analytických konstrukcí V této kapitole se nejdříve seznámíme s databází exist, kterou budeme využívat jako platformu pro naše řešení. Dále si postupně probereme jednotlivá vylepšení jazyka XQuery a podíváme se na jejich silné a slabé stránky. 3.1 Databáze exist Databáze exist [3] je volně šiřitelná nativní XML databáze s efektivním vyhodnocováním XQuery dotazů. Databáze podporuje automatické indexování, má podporu pro full-textové prohledávání, XUpdate a další moduly. Současná verze implementuje pracovní návrhy XQuery 1.0, kromě podpory importu a validace schémat, která je v návrhu volitelná. Pro vyhnutí se paměťově náročným operacím během vyhodnocování dotazu používá databáze efektivní indexovou strukturu, která je založena na numerickém schématu indexování pro identifikaci jednotlivých XML uzlů v indexu. Databáze exist podporuje přidávání dalších modulů napsaných v jazyce Java. My tohoto využijeme a přidáme náš modul grouping, obsahující funkce pro analytické zpracování XML dokumentů. Budeme pracovat s aktuální verzí databáze Konstrukce Group by Jako první vylepšení si představím analogii operátoru group by z SQL. Klasický group by je založen na sdružování do skupin dle hodnot. My k tomu přidáme i sdružování do skupin na základě struktury strukturální group by. Implementujeme postupně dvě varianty. První bude přímočařejší a povede na práci s vnořenými cykly při vyhodnocováni XQuery dotazu, u druhé varianty se pokusíme odstranit vnořené cykly a urychlit tím výpočet. 20

21 3.2.1 Řešení pomocí vnořených cyklů V první variantě konstrukce group by vyjdeme z ukázky pro sdružování dat do skupin uveřejněné v pracovním návrhu jazyka XQuery. Idea Volání funkce přetransformujeme na XQuery dotaz, který odpovídá ukázce z pracovního návrhu jazyka XQuery. Dotaz využívá vnořené cykly pro generování všech možných kombinací hodnot, dle kterých se tvoří skupiny. Pokud existují záznamy s touto kombinací hodnot, je na nich provedena příslušná agregace a výsledek této agregace je zařazen do výsledku dotazu. Po provedení dotazu databází, je výsledek dotazu dán na výstup. Funkce groupby Nejprve ukážeme hlavičku funkce a seznámíme se s jednotlivými parametry volání funkce. Ty nám napoví o možnostech a omezení použití naší funkce. grouping:groupby(string cesta, string+ skupiny, string agregát, string operace) grouping: Název jmenného prostoru. Při použití databáze exist je potřeba u volání funkcí uvádět i z kterého jmenného prostoru funkce je. groupby: Název funkce. cesta: Cesta ke společnému elementu, vůči kterému se vztahují požadavky na tvorbu skupin (parametr skupiny) a na agregovanou veličinu (parametr agregát). Jde o XPath výraz, který může navíc ve složených závorkách obsahovat alternativy pro strukturální group by. Tyto alternativy jsou odděleny znakem. Cesta nesmí končit znakem /. skupiny: Sekvence cest k hodnotám elementů (tříd), dle kterých chceme sestavit skupiny pro agregaci. Sekvence je uzavřena do kulatých závorek. Jednotlivé cesty (XPath výrazy) jsou od sebe odděleny čárkami. Pokud je zadán jen jeden požadavek na skupinu (jedna cesta), nemusí být uzavřen do závorek. Při provádění strukturálního group by nemusíme požadavek na tvorbu skupin uvádět. Půjde tak o čistě strukturální group by. V tomto případě jako hodnotu parametru funkce uvedeme prázdný řetězec. agregát: Cesta k hodnotě elementu (třídy), kterou chceme agregovat. operace: Název agregační funkce. K dispozici jsou následující funkce: sum, avg, min, max, count, echo. Z uvedených názvů funkcí je zřejmé, co která dělá. Snad jen u funkce count uvedeme, že udává počet prvků ve skupině. Mírně bokem těchto tradičních funkcí stojí funkce echo, kterou můžeme použít pro výpis hodnot, které jsou v dané skupině. 21

22 Příklad použití Nyní se podíváme na ukázky různých způsobů použití této funkce. U každého způsobu uvedeme fragment vstupního souboru, příslušné volání funkce, fragment výstupu a také si ukážeme, na jaký XQuery dotaz bylo volání funkce přetransformováno. Tradiční group by na hodnotách Předpokládejme vstupní dokument, obsahující informace o zaměstnancích, s následující strukturou: <zaměstnanci> <zaměstnanec třída="1"> <narozen>1974</narozen> <plat>3000</plat> </zaměstnanec>... </zaměstnanci> Nad tímto dokumentem položíme dotaz: Jaký je průměrný plat zaměstnanců narozených ve stejném roce a patřících do stejné třídy? Budeme tedy chtít sestavit skupiny na základě hodnot elementu narozen (obsahuje rok narození zaměstnance) a atributu třída elementu zaměstnanec. Pro každou skupinu pak spočítat průměrnou hodnotu elementu plat. Výsledek vrácený funkcí by tedy měl mít podobu: <result> <narozen>1965</narozen> <třída>2</třída> <avg-plat>2650</avg-plat>... </result> Volání funkce vypadá následovně: grouping:groupby("//zaměstnanec", ("narozen", "@třída"), "plat", "avg") Toto volání funkce přetvoří na XQuery dotaz, který nechá vyhodnotit XML databázi. XQuery dotaz má tvar: for $var0 in fn:distinct-values(//zaměstnanec/narozen), $var1 in fn:distinct-values(//zaměstnanec/@třída) let $res := //zaměstnanec[narozen = $var0 = $var1] order by $var0, $var1 return if (fn:exists($res)) then <narozen>{$var0}</narozen> <třída>{$var1}</třída> <avg-plat>{fn:avg($res/plat)}</avg-plat> else () 22

23 Čistě strukturální group by V tomto případě nebudeme tvořit skupiny na základě hodnot elementů a tříd, ale využijeme struktury dokumentu. Tento přístup nelze aplikovat v relačním světě SQL a je tak rozšířením specifickým pro XML dokumenty. Nechť máme vstupní dokument s následující strukturou: <divize> <oddělení> <oddělení> <zaměstnanec> <narozen>1974</narozen> <plat>3000</plat> </zaměstnanec> </oddělení> </oddělení> <oddělení> <zaměstnanec> <narozen>1965</narozen> <plat>5000</plat> </zaměstnanec> </oddělení>... </divize> Máme tedy dokument obsahující informace o zaměstnancích (podstromy elementů zaměstnanec) spolu s jejich rozdělením do oddělení (elementy oddělení). Povšimněme si zejména toho, že oddělení může obsahovat přímo zaměstnance, nebo další oddělení. Na základě toho sestavíme náš dotaz. Bude nás zajímat: Jaký je minimální plat na každé úrovni oddělení? Očekáváme výsledek následujícího tvaru: <result> <level>0</level> <min-plat>2600</min-plat> <level>1</level> <min-plat>3000</min-plat> </result> Dotaz přeformulovaný na volání funkce: grouping:groupby( "//divize/{oddělení oddělení/oddělení}/zaměstnanec", "", "plat", "min") V tomto případě funkce sestaví dva dotazy, které se vyhodnotí databází, jejich výsledky se sloučí a dají na výstup. Dotazy jsou jednoduché a vypadají následovně: 1. <level>0</level> <min-plat> {fn:min(//divize/oddělení/zaměstnanec/plat)} 23

24 </min-plat> 2. <level>1</level> <min-plat> {fn:min(//divize/oddělení/oddělení/zaměstnanec/plat)} </min-plat> Kombinace strukturálního a hodnotového group by Posledním případem využití naší funkce je kombinace předchozích dvou postupů. Budeme chtít vytvořit skupiny na základě, jak hodnot elementů a tříd, tak i struktury dokumentu. Za vstupní XML dokument vezmeme ten z předchozího případu. Nad tímto dokumentem položíme dotaz: Jaký je průměrný plat zaměstnanců dle úrovně oddělení, do kterého patří, a dle roku jejich narození? Výsledek může vypadat například následovně: <result> <level>0</level> <narozen>1965</narozen> <avg-plat>2650</avg-plat> <level>1</level> <narozen>1965</narozen> <avg-plat>3000</avg-plat>... </result> Požadovaný dotaz zapsaný jako volání funkce má tvar: grouping:groupby( "//divize/{oddělení oddělení/oddělení}/zaměstnanec", "narozen", "plat", "avg") Při spojení strukturálního a hodnotového požadavku na skupiny funkce sestaví několik dotazů, podobných dotazům při hodnotovém group by. Tyto nechá vyhodnotit databází a výsledky z nich sloučí a dá na výstup. Dotazů je tolik, kolik je různých cest v požadavku na strukturální group by. V našem případě by vznikly následující dva dotazy: 1. for $var0 in fn:distinct-values(//divize/oddělení/narozen), let $res := //divize/oddělení/zaměstnanec[narozen = $var0] order by $var0 return if (fn:exists($res)) then <level>0</level> <narozen>{$var0}</narozen> <avg-plat>{fn:avg($res/plat)}</avg-plat> 24

25 else () 2. for $var0 in fn:distinct-values( //divize/oddělení/oddělení/zaměstnanec/narozen), let $res := //divize/oddělení/oddělení/zaměstnanec[narozen = $var0] order by $var0 return if (fn:exists($res)) then <level>1</level> <narozen>{$var0}</narozen> <avg-plat>{fn:avg($res/plat)}</avg-plat> else () Výhody a nevýhody řešení Pokud se nejdříve zaměříme na výhody tohoto řešení konstrukce group by, vidíme, že je poměrně přímočaré a jednoduché. Navíc uživateli ušetří spoustu času, který by musel věnovat vymýšlení mnohem složitějšího XQuery dotazu. Nespornou výhodou je také fakt, že funkce vrací opět fragment XML dokumentu, a lze tedy funkci použít v jakémkoliv XQuery dotazu a nad výsledkem funkce dále pracovat a dotazovat se. Hlavní nevýhodou našeho řešení je použití vnořených cyklů u sestaveného XQuery dotazu. Vše ale ještě závisí na schopnosti vyhodnocení takového dotazu databází exist. Pokud databáze rozpozná v dotazu vnořené cykly a použije nějakou chytřejší metodu vyhodnocení, nemuselo by mít použití těchto cyklů žádný dramatický vliv na rychlost vyhodnocení dotazu. Jestli tomu tak je, nebo nikoliv, si ukážeme v 4. kapitole věnované praktickým zkouškám a měření. Dalšími nevýhodami, které stojí za uvážení je volání vícero dotazů při vyhodnocování čistě strukturálního group by a kombinace strukturálního a hodnotového group by. Další vadou je opomenutí elementů a tříd při zpracování, pokud nemají žádnou hodnotu (jsou prázdné). Například u uvedeného hodnotového group by by zaměstnanci, kteří nemají uvedenou žádnou třídu, byli ze zpracování vynecháni. To je rozdíl proti SQL, kde by chybějící hodnota byla nahrazena hodnotou null a skupiny by vznikaly i na základě této hodnoty Řešení bez vnořených cyklů K další implementaci konstrukce group by nás vedl nedostatek předchozího řešení v podobě použití vnořených cyklů. Pokud se nám podaří odstranit vnořené cykly, mohla by tato varianta být rychlejší. Na to se podíváme až ve 4. kapitole. Idea Prvním krokem je tvorba XQuery dotazu pro získání příslušných dat z databáze. Získané záznamy obsahují hodnoty, dle kterých se budou tvořit skupiny 25

26 a agregovanou hodnotu. Záznamy jsou setříděné dle hodnot pro tvorbu skupin a vráceny jako XML fragment. Tento XML fragment zpracujeme pomocí SAX parseru. Při zpracování dalšího záznamu se podíváme, jestli neměl stejné hodnoty pro tvorbu skupin jako předchozí záznam. Pokud ano, tyto dva záznamy agregujeme. Jinak dáme předchozí záznam na výstup. Funkce groupby2 Volání funkce a její parametry jsou totožné jako u předchozí verze. Jen název funkce je jiný, a to groupby2. Možnosti použití jsou taktéž stejné jako u funkce groupby, můžeme tak tvořit skupiny jak dle hodnot, struktury, tak i dle jejich kombinace. Příklad použití Rozdílem proti předchozí variantě je transformace předaných parametrů na dotaz, který neobsahuje vnořené cykly. Kromě dotazu pro čistě strukturální group by, který je stejný jako u předchozí varianty. Nejlépe si vše předvedeme na příkladu. Mějme následující XML dokument: <zaměstnanci> <zaměstnanec třída="1"> <narozen>1974</narozen> <plat>3000</plat> </zaměstnanec>... </zaměstnanci> Nad tímto dokumentem položíme dotaz Jaký je průměrný plat zaměstnanců narozených ve stejném roce a patřících do stejné třídy? Dotaz převedený na volání funkce vypadá následovně: grouping:groupby2("//zaměstnanec", ("narozen", "@třída"), "plat", "avg") Nyní přichází na řadu naše funkce a toto volání funkce přemění na XQuery dotaz, který následně vyhodnotí databáze. Výsledky tohoto dotazu dále zpracujeme a konečný výsledek dáme na výstup. Nejprve se podívejme, jaký XQuery dotaz získáme. for $var in //zaměstnanec[narozen and plat] order by $var/narozen, $var/@třída return {$var/narozen} <třída>{data($var/@třída)}</třída> <avg-plat>{data($var/plat)}</avg-plat> Jak můžeme z dotazu vidět, získáme všechny údaje o zaměstnancích (elementy zaměstnanec), kteří mají podelement s rokem narození (element narozen), atribut třída a podelement plat, který budeme agregovat. Zaměstnanci budou setřídění dle požadavků na tvorbu skupin. V našem případě dle hodnoty elementu narozen a dle hodnoty atributu třída. 26

27 Za povšimnutí ještě stojí, že ve výsledku dotazu jednoduše vypíšeme hodnoty elementů ({$var/narozen}), ale pro vypsání hodnoty atributu musíme zvlášť zkonstruovat příslušný element a použít vestavěnou funkci data. Navíc, agregovanou hodnotu vypíšeme pomocí vestavěné funkce data, abychom si sami mohli určit název elementu. To je proto, aby se zmenšila pravděpodobnost, že se agregovaná hodnota jmenuje stejně, jako nějaká z hodnot, dle kterých tvoříme skupiny. Výsledkem dotazu bude následující seznam údajů o zaměstnancích: <result> <narozen>1980</narozen> <třída>1</třída> <avg-plat>5000</avg-plat> <narozen>1980</narozen> <třída>1</třída> <avg-plat>3000</avg-plat>... </result> Nyní nám již stačí jediný sekvenční průchod, při kterém sami rozlišíme, jestli už začala nová skupina, či nikoliv. Nesmíme také zapomenout počítat pro skupinu patřičnou agregační funkci. Výsledek pak vypadá následovně: <result> <narozen>1980</narozen> <třída>1</třída> <avg-plat>5000.0</avg-plat> <narozen>1980</narozen> <třída>2</třída> <avg-plat>4000.0</avg-plat>... </result> Výhody a nevýhody Hlavní nevýhodu předchozího řešení, vnořené cykly, se nám povedlo odstranit. Ostatní nevýhody, jako například více pokládaných dotazů při strukturálním seskupování, přetrvávají. Výhodami je opět zejména jednoduchost použití a možnost další práce nad výsledkem v rámci XQuery dotazu. 27

28 3.3 Konstrukce Roll up Konstrukce roll up slouží k agregaci hodnot na základě hierarchie. Konstrukce nám poskytuje hodnoty od nejnižší úrovně až po konečný agregát všech hodnot na nejvyšší úrovni. Můžeme si to představit například tak, že na nejnižší úrovni máme údaje o měsíčních prodejích, na vyšší úrovni máme tyto prodeje agregovány na čtvrtletní a nejvyšší úroveň nám tvoří roční prodeje, jež jsou agregátem čtvrtletních prodejů. Kromě klasického roll up si představíme ještě topologický roll up, jež je opět specialitou analýzy XML dokumentů Roll up Nejdříve se podíváme na variantu konstrukce roll up tak, jak ji známe z relačních databází. Příkaz potřebuje pro svou práci specifikaci agregovaných hodnot, přičemž záleží na pořadí, v němž jsou uvedeny. Čím je agregovaná hodnota uvedena více vlevo, tím výše bude v hierarchii pro agregaci, a naopak. To znamená, že roll up je asymetrický. Idea Volání funkce přetransformujeme na XQuery dotaz, kterým získáme z databáze záznamy pro agregaci. Každý záznam obsahuje hodnoty, dle kterých se budou tvořit skupiny, a agregovanou hodnotu. Pořadí těchto hodnot je stejné u všech záznamů. Záznamy jsou také abecedně setříděny. Na získaná data budeme pohlížet jako na frontu. Ze začátku fronty odebíráme záznamy, dokud mají stejné hodnoty pro tvorbu skupin. Přitom agregujeme požadovanou hodnotu. Výsledek agregace těchto záznamů dáme na výstup, ze záznamu odstraníme poslední hodnotu, dle které se tvoří skupiny, a takto upravený záznam vložíme na konec fronty. Tímto způsobem zpracováváme frontu, dokud obsahuje nějaké záznamy. Funkce rollup Nyní ukážeme, jak vypadá hlavička funkce a jaké parametry přijímá. grouping:rollup(string cesta, string+ skupiny, string agregát, string operace) grouping: Název jmenného prostoru. Při použití databáze exist je potřeba u volání funkcí uvádět i z kterého jmenného prostoru funkce je. rollup: Název funkce. cesta: Cesta ke společnému elementu, vůči kterému se vztahují požadavky na tvorbu skupin (parametr skupiny) a na agregovanou veličinu (parametr agregát). Jde o XPath výraz. skupiny: Sekvence cest k hodnotám elementů (tříd), dle kterých chceme sestavit skupiny pro agregaci. Sekvence je uzavřena do kulatých závorek. Jednotlivé cesty (XPath výrazy) jsou od sebe odděleny čárkami. Pokud je 28

29 zadán jen jeden požadavek na skupinu (jedna cesta), nemusí být uzavřen do závorek. agregát: Cesta k hodnotě elementu (třídy), kterou chceme agregovat. operace: Název agregační funkce. K dispozici jsou následující funkce: sum, avg, min, max, count a echo. Připomeňme, že funkce echo slouží k vypsání všech hodnot ve skupině a jde o rozšíření vůči relačnímu operátoru roll up. Příklad použití Předpokládejme, že máme následující XML dokument, který obsahuje záznamy o prodejích aut. <prodeje> <prodej> <model>chevy</model> <rok>1994</rok> <barva>bílá</barva> <kusy>10</kusy> </prodej> <prodej> <model>ford</model> <rok>1995</rok> <barva>černá</barva> <kusy>25</kusy> </prodej>... </prodeje> Nad tímto dokumentem budeme chtít zjistit Kolik aut se prodalo dle značky, roku, barvy a agregovaně dle značky/roku, pouze značky a celkem? Zavoláme naši funkci s následujícími parametry: grouping:rollup("//prodej", ("model", "rok", "barva"), "kusy", "sum") Volání funkce následně přetvoříme na volání XQuery dotazu, kterým získáme potřebná data pro agregaci. Data budou setříděna dle hierarchie uvedené ve volání funkce a dle které budeme agregovat. Dotaz tedy vypadá následovně: for $var in //prodej[model and rok and barva and kusy] order by $var/model, $var/rok, $var/barva return <rollup> {data($var/model)} {data($var/rok)} {data($var/barva)} {$var/kusy} </rollup> Po vyhodnocení dotazu získáme seznam hodnot pro agregaci. Pořadí hodnot odpovídá pořadí v parametru volání funkce a navíc je přidána agregovaná veličina. Jednotlivé řádky seznamu jsou setříděny dle stejného pořadí. Ukázku takového seznamu nalezneme níže. <rollup>chevy 1994 černá 20</rollup> <rollup>chevy 1994 černá 15</rollup> 29

30 <rollup>chevy 1994 bílá 10</rollup> <rollup>ford 1995 černá 25</rollup>... Nyní nám stačí seznam procházet a agregovat. K tomu se budeme na seznam dívat jako na frontu. Ze začátku fronty odebíráme prvky, dokud nám prvky spadají do jedné skupiny a agregujeme příslušnou veličinu. V našem případě bychom například odebrali první dva prvky seznamu, protože budou tvořit jednu skupinu a sečetli agregovanou hodnotu. Když máme dokončenou skupinu, dáme ji na výstup. Víme tak nyní, že aut značky Chevy se v roce 1994 prodalo v černé barvě 35. Nyní se v hierarchii posuneme o úroveň výše poupravíme získanou skupinu a vložíme ji na konec fronty. Úprava spočívá v odstranění poslední hodnoty určující skupinu. Odstraníme tedy hodnotu černá a do fronty vložíme záznam obsahující údaje Chevy, 1994, 35. Tento postup opakujeme, dokud fronta není prázdná. Po vyprázdnění fronty máme na výstupu požadovaný výsledek, jehož ukázku vidíme níže. <result> <název>chevy 1994 černá</název> <sum-kusy>35.0</sum-kusy>... <název>chevy 1994</název> <sum-kusy>90.0</sum-kusy>... <název>chevy</název> <sum-kusy>290.0</sum-kusy>... <název>_final_</název> <sum-kusy>510.0</sum-kusy> </result> Výhody a nevýhody Výhodou našeho řešení je, že lze nyní nad XML databází jednoduše použít konstrukci roll up, která je často potřeba při analytickém zpracování dat. Hlavní nevýhodou je absence jakékoliv podpory pro využití znalostí struktury dokumentu. Nelze tak kombinovat klasický a strukturální roll up podobně, jak tomu bylo u konstrukce group by. Další nevýhodou je použití znaku jako oddělovače. Pokud bude nějaká hodnota, dle které tvoříme skupiny, obsahovat tento znak, může to vést k neočekávanému chování funkce. 30

31 3.3.2 Topologický roll up Tato varianta je zjednodušením klasického roll up. Pro svou funkci si vystačí s jedním XPath výrazem, který nám určí hodnoty pro agregaci. Vlastní agregace pak probíhá dle hierarchie dané cestou k agregovaným hodnotám, tzn. po hranách XML stromu od listů až po kořen. Idea Nejdříve pomocí XQuery dotazu získáme z databáze hodnoty pro agregaci a k nim příslušné číselné reprezentace cest. Tato data postupně procházíme. Záznam vždy dáme na výstup, upravíme jej a vrátíme ke zpracování. Úprava spočívá v odstranění posledního identifikátoru cesty k agregované hodnotě. Tím se posuneme ve stromě, reprezentující XML dokument, o úroveň výše. Takto upravený záznam uložíme pro další zpracování s tím, že pokud již máme jiný záznam se stejnou cestou jako je ta upravená, tak tyto dva záznamy agregujeme a výsledný záznam uložíme. Tento proces opakujeme, dokud nezpracujeme všechny záznamy (nedostaneme se až ke kořeni stromu). Funkce topo-rollup Nejprve se seznámíme s tím, jak vypadá hlavička funkce a jaké přijímá parametry. grouping:topo-rollup(string cesta, string operace) grouping: Název jmenného prostoru. Při použití databáze exist je potřeba u volání funkcí uvádět i z kterého jmenného prostoru funkce je. topo-rollup: Název funkce. cesta: Cesta k hodnotám (elementů či tříd), které se budou agregovat. operace: Název agregační funkce. K dispozici jsou následující funkce: sum, avg, min, max, count a echo. Připomeňme, že funkce echo slouží k vypsání všech hodnot ve skupině. Příklad použití Předpokládejme, že máme následující XML dokument, popisující uspořádání oddělení a skupin ve firmě spolu s rozpočtem pro skupiny. Povšimněme si, že oddělení může obsahovat skupinu, nebo také další oddělení. <divize> <oddělení> <oddělení> <skupina> <rozpočet>5000</rozpočet> </skupina> </oddělení> </oddělení> <oddělení> <skupina> 31

32 <rozpočet>5000</rozpočet> </skupina> </oddělení>... </divize> Nás nyní bude zajímat Jak velký je rozpočet každé skupiny a oddělení? Zavoláme tedy naši funkci s následujícími parametry: grouping:topo-rollup("//rozpočet", "sum") Toto volání funkce přetvoříme na XQuery dotaz, kterým získáme agregované hodnoty a identifikátory k elementům obsahující tyto agregované hodnoty. Dotaz pro databázi vypadá následovně. for $value in //rozpočet let $parent := $value/.., $node := util:node-id($parent) order by fn:string-length($node) descending, $node return <rollup> {$node},{$value} </rollup> Výsledkem dotazu je seznam cest, vyjádřených identifikátory uzlů po cestě, a příslušné agregované hodnoty. Tento seznam je setříděn dle cesty k uzlu tak, že nejdříve jsou uvedeny uzly vlevo a z větší hloubky (při klasickém nakreslení XML stromu). Ukázku takového seznamu máme zde. <rollup> ,10000</rollup> <rollup> ,12000</rollup> <rollup> ,15000</rollup>... Nyní nás čeká zpracování tohoto seznamu a postupná agregace hodnot zespoda nahoru. Vezmeme vždy první prvek seznamu a příslušnou hodnotu dáme na výstup. Z cesty k dané hodnotě odebereme poslední identifikátor uzlu (poslední číslo a tečku). Podíváme se, jestli máme v seznamu prvek se stejnou cestou, jakou jsme nyní vytvořili. Pokud ne, vložíme novou cestu a starou hodnotu zpět do seznamu. Pokud v seznamu takový prvek je, provedeme se starou hodnotou a hodnotou tohoto prvku požadovanou agregační operaci a výsledek opět umístíme zpět do seznamu. Jak tento proces probíhá si ukážeme ještě na příkladu. Mějme následující fragment XML dokumentu. 32

33 Divize 1 Oddělení Oddělení Oddělení Skupina Skupina Skupina Skupina Skupina Rozpočet Rozpočet Rozpočet Rozpočet Rozpočet Vidíme názvy elementů a pod nimi vždy jejich identifikátory, dané cestou k nim. Předpokládejme, že budeme zpracovávat element Skupina s identifikátorem Odebereme tento prvek ze seznamu a na výstup dáme hodnotu odpovídající výši rozpočtu této skupiny hodnota elementu Rozpočet je Nyní z identifikátoru cesty odebereme poslední číslo a dostaneme se tak ve stromu o patro výše. Máme tak cestu Podíváme se, jestli je v seznamu prvek s touto cestou. Takový prvek tam není, a proto dáme do seznamu nový prvek obsahující cestu a hodnotu Nyní vybereme ze seznamu další prvek máme cestu a hodnotu Hodnotu dáme na výstup a upravíme cestu. Protože již v seznamu je prvek obsahující cestu 1.1.2, agregujeme hodnotu s hodnotou tohoto prvku. Pokud je agregační funkcí suma, získáme hodnotu Novou hodnotu uložíme do seznamu. Máme zde tedy nyní prvek s cestou a hodnotou Tímto způsobem pokračujeme, dokud máme v seznamu nějaký prvek. Až odstraníme poslední prvek seznamu, máme na výstupu kompletní výsledek. Ukázku takového výsledku vidíme zde. <result> <level depth="4"> <node-id> </node-id> <value> </value> <node-id> </node-id> <value> </value>... </level>... <level depth="1"> <node-id>1</node-id> 33

34 <value> </value> </level> </result> Výhody a nevýhody Tato funkce nám přináší hlavní výhodu ve své vlastní existenci. Vytvořit ze základních prostředků jazyka XQuery dotaz na postupnou agregaci hodnot od listů ke kořeni totiž není snadné. Poměrně značnými nevýhodami současného řešení je zobrazení cesty k uzlu pouze v podobě číselného identifikátoru uzlu namísto cesty k uzlu a nemožnost vybrání úrovní agregace, které nás zajímají. 3.4 Konstrukce Cube Poslední konstrukcí, kterou si představíme, je konstrukce cube. Jedná se o složitější operaci, než jsou dříve představené operace group by a roll up. Tato konstrukce nám dá odpovědi na všechny možné otázky týkající se dané množiny dat, značně nám usnadní práci a ušetří čas, neboť pro získání stejného výsledku by bylo potřeba spousty volání funkcí předchozích. Konstrukci cube si můžeme například představit jako vícenásobné volání konstrukce roll up. Pokud se vrátíme k příkladu s prodejem aut z předchozí části, použitím konstrukce roll up získáme údaje o prodeji aut dle modelu, roku, barvy a souhrnné údaje o prodeji dle modelu a roku, pouze dle modelu a údaje o celkovém prodeji. Konstrukce cube nám navíc dá informace o prodeji aut dle modelu a barvy, dle roku a barvy, nebo dle pouze roku atd. Tentokrát si představíme tři varianty konstrukce. První varianta ke svému běhu využívá dříve uvedenou funkci groupby2. Jednoduchost návrhu je však vykoupena většími časovými nároky. Druhá varianta je díky použité datové struktuře složitější, ale její běh je rychlejší. Nevýhodou je pak její prostorová náročnost. Třetí varianta se snaží redukovat obrovské nároky na paměť druhé varianty Řešení pomocí konstrukce group by Jako první představíme jednodušší variantu, která ke své práci používá konstrukci group by, konkrétně funkci groupby2. Nejdříve se podíváme na hlavní ideu funkce, její hlavičku a parametry. Následovat bude ukázka běhu funkce na jednoduchém příkladu. Idea Z volání funkce vezmeme požadavky na tvorbu skupin a budeme z nich postupně generovat všechny podmnožiny s výjimkou prázdné podmnožiny. Podmnožiny představují různé stupně agregace. Každou takovou podmnožinu předáme funkci groupby2 a její výsledek dáme na výstup. Protože funkce groupby2 nepřijímá prázdný požadavek na tvorbu skupin, reprezentující celkový agregát, sestavíme 34

35 pro tento agregát zvláštní XQuery dotaz a po jeho provedení dáme vrácená data na výstup. Funkce cube grouping:cube(string cesta, string+ skupiny, string agregát, string operace) grouping: Název jmenného prostoru. Při použití databáze exist je potřeba u volání funkcí uvádět i z kterého jmenného prostoru funkce je. cube: Název funkce. cesta: Cesta ke společnému elementu, vůči kterému se vztahují požadavky na tvorbu skupin (parametr skupiny) a na agregovanou veličinu (parametr agregát). Jde o XPath výraz. skupiny: Sekvence cest k hodnotám elementů (tříd), dle kterých chceme sestavit skupiny pro agregaci. Sekvence je uzavřena do kulatých závorek. Jednotlivé cesty (XPath výrazy) jsou od sebe odděleny čárkami. Pokud je zadán jen jeden požadavek na skupinu (jedna cesta), nemusí být uzavřen do závorek. agregát: Cesta k hodnotě elementu (třídy), kterou chceme agregovat. operace: Název agregační funkce. K dispozici jsou následující funkce: sum, avg, min, max, count a echo. Připomeňme, že funkce echo slouží k vypsání všech hodnot ve skupině a jde o rozšíření vůči relačnímu operátoru cube. Příklad použití Použití funkce si ukážeme nad následujícím dokumentem, obsahujícím údaje o prodejích aut. <prodeje> <prodej> <model>chevy</model> <rok>1994</rok> <barva>bílá</barva> <kusy>10</kusy> </prodej> <prodej> <model>ford</model> <rok>1995</rok> <barva>černá</barva> <kusy>25</kusy> </prodej>... </prodeje> Z tohoto dokumentu budeme chtít zjistit Kolik aut se prodalo dle značky, roku, barvy, agregovaně dle značky/roku, značky/barvy,...? Zavoláme naši funkci s následujícími parametry: grouping:cube("//prodej", ("model", "rok", "barva"), "kusy", "sum") 35

36 Z tohoto volání funkce nás nejvíce zajímají požadavky na tvorbu skupin. Tyto vezmeme a postupně budeme vytvářet všechny jejich podmnožiny, s výjimkou prázdné podmnožiny. Na každou tuto podmnožinu zavoláme funkci groupby2 a její výsledek dáme na výstup. Nakonec ještě musíme spočítat celkový agregát (počet prodaných aut celkem), neboť funkce groupby2 nepřipouští jako svůj parametr prázdnou sekvenci požadavků na tvorbu skupin. Vytvoříme tedy následující XQuery dotaz, který spustíme v databázi. <sum-kusy>{sum(//prodej/kusy)}</sum-kusy> Tak získáme celkový agregát, který přidáme k předchozím výsledkům. Konečný výsledek je sekvencí dílčích výsledků a má následující podobu: <result> <model>chevy</model> <barva>černá</barva> <rok>1994</rok> <sum-kusy>50.0</sum-kusy>... </result> <result> <model>chevy</model> <barva>černá</barva> <sum-kusy>135.0</sum-kusy>... </result> <result> <model>chevy</model> <rok>1994</rok> <sum-kusy>90.0</sum-kusy>... </result> <result> <barva>černá</barva> <sum-kusy>270.0</sum-kusy> <barva>bílá</barva> <sum-kusy>240.0</sum-kusy> </result>... <result> <sum-kusy>510</sum-kusy> </result> 36

37 Výhody a nevýhody Výhodou tohoto řešení je to, že nám ušetří práci a čas se samostatným voláním velkého množství group by operací. Velkou nevýhodou je časová složitost tohoto řešení. Pro požadavek na tvorbu skupin velikosti n je potřeba provést 2 n 1 iterací volání funkce groupby2, přičemž každé volání znamená průchod nad těmi stejnými daty v databázi. Navíc je ještě potřeba jednoho volání pro získání celkového agregátu. Protože se ale vždy jedná o průchod stejnými daty, mohlo by výpočtu napomoci použití paměti cache databází. O tom se přesvědčíme v 4. kapitole věnované praktickým testům. Za nevýhodu by se dalo považovat i to, že výsledek není tvořen jediným fragmentem XML kódu tak, jak je to u ostatních funkcí, ale výsledek je tvořen sekvencí fragmentů XML kódu. Všechny tyto nedostatky se snaží řešit následující varianty konstrukce cube Řešení pomocí hyperkrychle V této variantě konstruktoru cube si představíme přístup zcela odlišný od minulé varianty. Pokusíme se tak odstranit výše zmíněné nedostatky předchozí implementace konstrukce cube. Jako základní prvek implementace použijeme hyperkrychli. Hyperkrychle Hyperkrychle je n-dimenzionální krychle, kde n je velikost požadavku na tvorbu skupin. Velikost krychle je dána kardinalitou jednotlivých dimenzí. Když kardinalitu dimenze i označíme C i, pak velikost krychle je n i=1 C i. Každá buňka krychle obsahuje agregovanou hodnotu pro jistou kombinaci hodnot jednotlivých dimenzí. Zatím krychle uchovává jen agregované hodnoty týkající se vždy všech dimenzí. Zvětšíme kardinalitu každé dimenze o jedna a tím získáme buňky krychle pro uložení agregovaných hodnot pro nejrůznější kombinace dimenzí. Velikost hyperkrychle se tak zvětší na n i=1 (C i + 1). Zavedeme speciální hodnotu ALL, která označuje dimenzi, která nás v danou chvíli nezajímá agregace probíhá přes všechny její hodnoty. Výpočet nad hyperkrychlí potom probíhá tak, že postupně procházíme zdrojová data a pro každý záznam upravíme příslušné buňky v hyperkrychli. Těchto buněk je 2 n. Vyplývá to z toho, že v n-prvkové adrese buňky postupně všemi způsoby nahrazujeme prvky adresy za hodnoty ALL. Pokud se vrátíme k příkladu s prodejem aut a budeme požadovat tvorbu skupin na základě modelu auta, roku výroby a barvy, pak model auta bude tvořit první dimenzi krychle, rok výroby druhou a barva třetí. Hyperkrychle pak může mít buňky [Chevy, 1994, černá] s hodnotu udávající počet prodaných černých aut Chevy v roce 1994 a [Chevy, ALL, černá] uchovávající agregovanou hodnotu udávající počet prodaných černých aut Chevy. 37

38 Idea Volání funkce nejprve přetransformujeme na XQuery dotaz, kterým získáme z databáze všechny záznamy, které obsahují informace potřebné pro vypočtení agregátů. Záznamy jsou vráceny jako XML fragment, proto na průchody záznamy budeme používat SAX parser. Projdeme všechny záznamy a zjistíme kardinalitu jednotlivých dimenzí a ke každé dimenzi si zapamatujeme hodnoty, které obsahuje. Nyní vytvoříme hyperkrychli příslušné velikosti. Projdeme znovu všechny záznamy z databáze a pro každý upravíme příslušnou buňku hyperkrychle a také buňky obsahující agregáty. Po dokončení průchodu dáme na výstup obsah těch buněk hyperkrychle, ke kterým jsme v průběhu zpracování záznamů alespoň jednou přistoupili. Funkce cube2 Hlavička funkce a přijímané parametry se neliší od předchozí varianty, název funkce je však cube2. Příklad použití Nyní ukážeme průběh vyhodnocení funkce od jejího volání až po vydání výsledku. Příklad bude stejný jako u minulé varianty. Nad XML dokumentem s prodeji aut provedeme následující volání funkce: grouping:cube2("//prodej", ("model", "rok", "barva"), "kusy", "sum") Z tohoto volání nejprve sestavíme XQuery dotaz, jehož pomocí získáme z databáze potřebná data pro agregaci. XQuery dotaz má tento tvar: for $var in //prodej[model and rok and barva and kusy] return {$var/model} {$var/rok} {$var/barva} <sum-kusy> {data($var/kusy)} </sum-kusy> Z databáze obdržíme jednotlivé záznamy, které budeme ukládat do hyperkrychle. Povšimněme si, že data nijak netřídíme. Pro ukládání dat do hyperkrychle nehraje pořadí záznamů žádnou roli. Část výsledku provedení dotazu můžeme vidět níže. <result> <model>chevy</model> <rok>1994</rok> <barva>bílá</barva> <sum-kusy>10</sum-kusy> <model>ford</model> <rok>1994</rok> 38

39 <barva>černá</barva> <sum-kusy>15</sum-kusy>... </result> Získaná data sekvenčně projdeme a zjistíme, jakou kardinalitu mají jednotlivé dimenze a jaké obsahují hodnoty. Hodnoty v každé dimenzi setřídíme dle abecedy. Nyní vytvoříme hyperkrychli příslušné velikosti. Následuje další sekvenční průchod daty. Pro každý záznam určíme jeho adresu v hyperkrychli a agregujeme hodnotu uloženou na této adrese s hodnotou záznamu. Dále budeme v adrese jednotlivé prvky postupně nahrazovat hodnotami ALL a v buňkách na těchto adresách také agregujeme hodnoty. To provedeme pro všechny záznamy. Nyní již máme v hyperkrychli vypočtené všechny agregáty. Zbývá hyperkrychli projít a data z ní vypsat na výstup. Hyperkrychli budeme procházet takovým způsobem, abychom data dostali přímo setříděna. Ukázku výstupu si můžeme prohlédnout níže. <result> <model>chevy</model> <rok>1994</rok> <barva>černá</barva> <sum-kusy>50.0</sum-kusy>... <model>ford</model> <barva>černá</barva> <sum-kusy>135.0</sum-kusy>... <rok>1994</rok> <sum-kusy>150.0</sum-kusy>... <sum-kusy>510.0</sum-kusy> </result> Výhody a nevýhody Nevýhody předchozí varianty se nám podařilo úspěšně odstranit pro získání dat z databáze stačí jediný dotaz a pro výpočet agregovaných hodnot pak dva průchody daty. Hlavní nevýhodou této varianty je její prostorová náročnost. Vždy je totiž vytvořena a inicializována v paměti celá hyperkrychle, i když velká část buněk hyperkrychle nám bude pravděpodobně reprezentovat skupiny, které se ve vstupním dokumentu nevyskytují. To se snaží řešit následující varianta. 39

40 Za nevýhodu můžeme také považovat průchod daty navíc pro získání prvků dimenzí a určení jejich kardinalit. To by šlo odstranit použitím dynamického zvětšování hyperkrychle při nalezení nového prvku nějaké dimenze. Další nevýhodou je zbytečné počítání všech příslušných agregátů u každého záznamu. U každého záznamu by stačilo spočítat agregáty na adresách, které vzniknou z adresy záznamu v hyperkrychli nahrazením vždy právě jednoho prvku v adrese hodnotou ALL. Ostatní agregáty (na hranách hyperkrychle) bychom pak spočítali na závěr. U každého takového výpočtu bychom mohli zvolit, přes kterou příslušnou stěnu (dimenzi) jej spočítat vybrali bychom tu nejmenší stěnu (dimenzi s nejmenší kardinalitou) Řešení pomocí hašování Tato varianta vychází z předchozí a odstraňuje její největší nedostatek prostorovou náročnost. Vycházíme z předpokladu, že velká část buněk hyperkrychle reprezentuje skupiny, které se ve vstupním dokumentu nevyskytují. Idea Nahradíme n-rozměrné pole, reprezentující v předchozí variantě hyperkrychli, hašováním. Prvek, reprezentující jednu skupinu, zahašujeme až na něj poprvé narazíme. Máme tak uloženy jen ty skupiny, které se vyskytují ve vstupním dokumentu. Funkce cube3 Hlavička funkce a přijímané parametry jsou stejné jako u předchozích variant, název funkce je však cube3. Výhody a nevýhody Výhodou je prostorová náročnost, která je nejhůře srovnatelná s předchozí variantou, zpravidla však menší. Na to, jestli jsou tyto předpoklady pravdivé, odpovíme v 4. kapitole věnované praktickým testům. Nevýhody, jako zbytečný průchod daty a okamžité počítání všech agregátů, přetrvávají i u této varianty. 40

41 Kapitola 4 Praktické testy V této kapitole se podíváme na to, jak rychlé jsou v praxi jednotlivé představené konstrukce. Zaměříme se také na srovnání jednotlivých variant téže konstrukce. 4.1 Testovací prostředí Všechny testy byly provedeny na stroji s následujícími parametry. Procesor: AMD Athlon XP Operační paměť : Transcend 512MB DDR ( ) Základní deska: Asus A7N8X-E Deluxe Pevný disk: Seagate ST GB Operační systém: Microsoft Windows XP Professional SP2 Databáze: exist Měření rychlosti probíhalo pomocí javové aplikace, která před každým dotazem znovu spustila databázi exist a vytvořila s ní nové spojení, aby další měření nad stejnými daty nebylo ovlivněno cachovaním databáze. Pro zjištění doby běhu dotazu byla použita standardní funkce System.currentTimeMillis(). Doba provádění dotazu byla pro každý dotaz změřena desetkrát a výsledek je dán průměrem těchto deseti měření. Jako testovací XML dokumenty byly použity dokumenty z projektu XMark [8], a to ve velikostech 1MB, 10MB, 50MB a 100MB. 4.2 Group by Nejprve se podíváme, jak dopadla měření u konstrukce group by. Měření probíhala nad různě velkými vstupními XML dokumenty projektu XMark, s různými dotazy a za použití funkce groupby i funkce groupby2. Dotazy byly čtyři, od nejjednoduššího, při kterém byl požadavek na tvorbu skupin jen dle jedné kategorie, až po složitější, kdy se skupiny vytvářely dle čtyř kategorií. Dotazy byly následující: 41

42 x1) grouping:groupby( "/site/regions/africa/item", "location", "quantity", "avg" ) x2) grouping:groupby( "/site/regions/africa/item", ("location", "payment"), "quantity", "avg" ) x3) grouping:groupby( "/site/regions/africa/item", ("location", "payment", "quantity"), "name", "count" ) x4) grouping:groupby( "/site/regions/africa/item", ("location", "payment", "quantity", "mailbox/mail[1]/date"), "mailbox/mail[1]/date", "count" ) Funkce groupby Podívejme se nejprve, jak dopadlo měření u funkce groupby. Dobu vyhodnocování dotazu v závislosti na velikosti vstupního souboru nalezneme v tabulce 4.1 a v grafu na obrázku 4.1 (pozor na logaritmické měřítko grafu). 1MB 10MB 50MB 100MB x1 0,3312 0,3814 0,7063 4,1579 x2 0,3565 0,6204 4, ,5969 x3 0,4234 0, , ,5970 x4 0, , , ,2985 Tabulka 4.1: Funkce groupby doba běhu v sekundách. Z naměřených hodnot vidíme, že doba běhu jednoduchých dotazů (dotazy x1, x2) na malých vstupních souborech (velikost 1MB a 10MB) se příliš neliší. Pokud však dotaz položíme nad větším vstupním souborem (velikost 50MB a 100MB), začne se doba drasticky prodlužovat již u dotazu, který tvoří skupiny na základě jen dvou kategorií (dotaz x2). Pokud například pro dotaz x2 zvětšíme vstupní dokument 5krát (z 10MB na 50MB), doba běhu se prodlouží 7krát. Když použijeme ještě větší vstupní soubor (opět pro dotaz x2) a zvýšíme tak velikost vstupních dat 10krát (z 10MB na 100MB), naroste doba výpočtu dokonce 122krát. 42

43 Obrázek 4.1: Funkce groupby doba běhu v sekundách. U složitějších dotazů je dramatický nárůst doby běhu dotazu ještě výraznější. Pro dotaz x3 se doba běhu při zvětšení vstupu 10krát (z 10MB na 100MB) zvětšila 283krát a u dotazu x4 dokonce 5006krát. Pokud se podíváme co se děje při zvětšení počtu požadavků na tvorbu skupin při zachování stejné velikosti vstupního souboru, uvidíme, že přidání jednoho požadavku na skupinu nám opět výrazně prodlouží dobu vykonávání dotazu. Například, při zvětšení požadavku na tvorbu skupin ze dvou na tři nad souborem o velikosti 50MB, nám vzroste doba běhu téměř 4krát. Při dalším zvětšení požadavku ze tří na čtyři se nám doba běhu prodlouží dokonce 155,5krát Funkce groupby2 Nyní se podíváme na druhou variantu implementace konstrukce group by, funkci groupby2. Dobu běhu výpočtu funkce s různě složitými dotazy v závislosti na velikosti vstupního souboru najdeme v tabulce 4.2. Tytéž hodnoty zobrazené v grafu pak najdeme na obrázku MB 10MB 50MB 100MB x1 0,3563 0,4220 0,6717 1,2139 x2 0,3500 0,4669 0,7874 1,4340 x3 0,4252 0,5515 1,2063 1,9437 x4 0,6126 0,9451 2,1655 3,4688 Tabulka 4.2: Funkce groupby2 doba běhu v sekundách. Z naměřených hodnot vidíme, že pro každý dotaz se doba běhu v závislosti na velikosti vstupního souboru nijak výrazně nemění. Pro dotazy x1 a x2 byla doba výpočtu menší než 1 sekunda dokonce i pro vstupní soubor o velikosti 50MB. Pro dotazy x3 a x4 pak bylo dosaženo srovnatelné rychlosti ještě na vstupním souboru o velikosti 10MB. Když provedeme stejný výpočet jako u funkce groupby, zjistíme například, že při tvorbě skupin dle tří kriterií (dotaz x3) se doba běhu při zvětšení vstupního 43

44 Obrázek 4.2: Funkce groupby2 doba běhu v sekundách. souboru 10krát (z 10MB na 100MB) prodloužila pouze 3,5krát. U čtyř kriterií (dotaz x4) se doba výpočtu zvětšila 3,6krát. Pokud se zaměříme na srovnání doby běhu funkce v závislosti na složitosti dotazu pro danou velikost vstupu, dojdeme k závěru, že přidání dalšího kriteria pro tvorbu skupin nezhorší výrazně dobu výpočtu. Například pro vstupní soubor s velikostí 50MB se při přechodu od dvou kriterií ke třem prodlouží doba výpočtu 1,5krát a při dalším rozšíření dotazu o čtvrté kriterium se doba běhu prodlouží 1,8krát. U 100MB vstupního souboru se při přechodu od dotazu x2 k dotazu x3 prodlouží doba běhu jen 1,36krát a při změně dotazu x3 za dotaz x4 jen 1,8krát Srovnání funkcí groupby a groupby2 Zaměříme se nyní na srovnání dvou různých implementací konstrukce group by. Funkce groupby využívá vnořených cyklů přímo v XQuery dotazu. Ve funkci groupby2 jsou tyto vnořené cykly odstraněny a sdružování do skupin je prováděno vlastními silami při průchodu zdrojovými daty. Srovnání obou funkcí bude nejlépe patrno z grafů. V prvním grafu na obrázku 4.3 nalezneme porovnání doby běhu obou funkcí nad vstupními daty o velikosti 1MB a 10MB v závislosti na složitosti dotazu. Na grafu z obrázku 4.4 nalezneme opět porovnání doby běhu funkcí v závislosti na složitosti dotazu. Tentokrát však pro velikosti vstupního souboru 50MB a 100MB. Podívejme se nejprve na první graf ukazující dobu běhu na dokumentech o velikostech 1MB a 10MB. Vidíme, že pro vstupní dokument o velikosti 1MB jsou obě funkce velmi vyrovnané. Zvětšíme-li ale velikost vstupních dat na 10MB začíná být funkce groupby2 s přibývající složitostí dotazů výrazně rychlejší než funkce groupby. Při tvorbě skupin dle čtyř kriterií je dokonce funkce groupby2 11,6krát rychlejší než funkce groupby. V druhém grafu vidíme dobu běhu obou funkcí na dokumentech o velikosti 50MB a 100MB. Z výsledků je vidět, že funkce groupby2 je značně rychlejší než funkce groupby. A to již od dotazu x2 (požadavek na tvorbu skupin dle dvou kriterií) pro vstupní dokument velikosti 50MB, a dokonce od dotazu x1 pro vstupní data velikosti 100MB. Na 50MB vstupním dokumentu je funkce groupby2 13,2krát 44

45 Obrázek 4.3: Srovnání funkcí groupby a groupby2 doba běhu v sekundách. Obrázek 4.4: Srovnání funkcí groupby a groupby2 doba běhu v sekundách. rychlejší při tvorbě skupin dle tří požadavků (dotaz x3) a dokonce 1139krát rychlejší při tvorbě skupin dle čtyř požadavků (dotaz x4) než funkce groupby. Analogicky pro vstupní dokument velikosti 100MB je funkce groupby2 135,6krát, respektive 15810krát, rychlejší než funkce groupby. Z měření vyplývá, že se nám povedlo úspěšně odstranit hlavní vadu funkce groupby, vnořené cykly, a podstatně tak zrychlili dobu provádění výpočtu. Funkce groupby2 je tedy díky nízkým naměřeným časům vhodná i pro praktické použití. 4.3 Roll up Další testy probíhaly pro konstrukci roll up. Funkci rollup jsme testovali pomocí tří dotazů (dotazy x5 až x7, viz níže), lišících se v počtu požadavků na tvorbu skupin. Nejjednodušší dotaz měl pouze jeden takový požadavek, nejsložitější pak tři požadavky. U funkce topo-rollup jsme použili pouze jeden dotaz. Dotazy byly pokládány nad XML dokumenty z projektu XMark různých velikostí. Použité dotazy vypadají následovně: x5) grouping:rollup( 45

46 "/site/closed_auctions/closed_auction", "date"), "price", "avg" ) x6) grouping:rollup( "/site/closed_auctions/closed_auction", ("seller/@person", "date", "quantity"), "price", "avg" ) x7) grouping:rollup( "/site/closed_auctions/closed_auction", ("seller/@person", "date", "quantity", "type"), "price", "avg" ) x8) grouping:topo-rollup( "/site/regions/*/item/quantity", "sum" ) Funkce rollup Podívejme se, jak si v testech vedla funkce rollup. Dobu běhu funkce v závislosti na položeném dotazu a na velikosti vstupních dat najdeme v tabulce 4.3. Graficky ztvárněné naměřené hodnoty nalezneme pak v grafu na obrázku MB 10MB 50MB 100MB x5 0,6921 1,3064 3,4751 5,3953 x6 0,6624 1,5968 4,2189 6,6531 x7 0,7078 1,7205 4,6609 7,4281 Tabulka 4.3: Funkce rollup doba běhu v sekundách. Z naměřených dat vidíme, že s rostoucí velikostí vstupních dat se doba běhu funkce nijak výrazně nezhoršuje. Zvětšíme-li například velikost vstupních dat 5krát (z 10MB na 50MB), pak se doba běhu při nejsložitějším dotazu (dotaz x7) prodlouží 2,7krát. Při zvětšení vstupních dokumentů 10krát (z 10MB na 100MB) se doba běhu funkce při tomtéž dotazu prodlouží 4,3krát. Pokud budeme zkoumat vliv složitosti dotazu na dobu běhu funkce pro danou velikost vstupních dat, uvidíme, že u 50MB vstupního souboru se doba běhu příliš nemění s rostoucím požadavkem na tvorbu skupin. Na vstupním souboru velikosti 100MB znamená zvýšení požadavku na tvorbu skupin o jedna nárůst doby výpočtu přibližně o jednu sekundu, což je velmi dobrý výkon. 46

47 Obrázek 4.5: Funkce rollup doba běhu v sekundách Funkce topo-rollup Nyní se podívejme na výkon funkce topo-rollup. Testy byly tentokrát prováděny pouze s jedním dotazem. Naměřená data nalezneme v tabulce 4.4 a také v grafu na obrázku MB 10MB 50MB 100MB x8 0,5734 2,5594 7, ,2297 Tabulka 4.4: Funkce topo-rollup doba běhu v sekundách. Obrázek 4.6: Funkce topo-rollup doba běhu v sekundách. Z naměřených hodnot vidíme, že při zvětšujícím se objemu vstupních dat roste výrazně doba běhu funkce. Například při zvětšení vstupního souboru 5krát (z 10MB na 50MB) se doba běhu prodlouží 3krát, při zvětšení 10krát (z 10MB na 100MB) se doba běhu prodlouží 5,6krát. 47

48 4.4 Cube Poslední testovanou konstrukcí je konstrukce cube. Testy byly prováděny pro všechny tři varianty konstrukce funkce cube, cube2 a cube3. Tři dotazy, lišící se svou složitostí, byly pokládány nad dokumenty projektu XMark o velikostech od 1MB do 100MB. Použité dotazy vypadají následovně: x9) grouping:cube( "/site/open_auctions/open_auction", ("seller/@person", "type"), "initial", "avg" ) x10) grouping:cube( "/site/open_auctions/open_auction", ("seller/@person", "type", "itemref/@item"), "initial", "avg" ) x11) grouping:cube( "/site/open_auctions/open_auction", ( "seller/@person", "type", "itemref/@item", "annotation/happiness" ), "initial", "avg" ) Funkce cube Nejprve se podíváme na funkci cube, která ke svému běhu využívá dříve uvedenou funkci groupby2. Naměřené hodnoty najdeme v tabulce 4.5 a v grafu na obrázku MB 10MB 50MB 100MB x9 0,9889 3,0221 8, ,3597 x10 1,9188 6, , ,1234 x11 3, , , ,6312 Tabulka 4.5: Funkce cube doba běhu v sekundách. Z hodnot v tabulce vidíme, že se zvětšujícím se vstupním souborem se doba výpočtu významně prodlužuje. Pro nejjednodušší dotaz x9, obsahující požadavek na dvě dimenze, se při zvětšení vstupního souboru 10krát (z 10MB na 100MB) prodlouží doba výpočtu 4,8krát. Při stejném zvětšení vstupního dokumentu se doba výpočtu pro dotaz x11 zvětší 6krát, což je vzhledem k daleko složitějšímu dotazu než v předchozím případě dobrý výsledek. 48

49 Obrázek 4.7: Funkce cube doba běhu v sekundách. Pokud se podíváme na to, jaký vliv má složitost dotazu na dobu výpočtu při zachování stejně velkého vstupního souboru, vidíme, že každé přidání dimenze (požadavku na tvorbu skupin) vedlo přibližně ke zdvojnásobení doby běhu programu Funkce cube2 Funkce cube2 již nevyužívá funkci groupby2, ale sama tvoří hyperkrychli a počítá příslušné agregáty. Dobu běhu funkce nalezneme v tabulce 4.6 a v grafu na obrázku MB 10MB 50MB 100MB x9 0,5579 1,6297 5,2139 9,2668 x10 0,7216 5,8468 x11 1, ,4953 Tabulka 4.6: Funkce cube2 doba běhu v sekundách. Obrázek 4.8: Funkce cube2 doba běhu v sekundách. V tabulce je ihned vidět, že ne vše se nám podařilo změřit. U kombinace dotazů 49

50 x10 a x11 a vstupních souborů o velikostech 50MB a 100MB došlo k ukončení výpočtu z důvodu nedostatku paměti. Pro zajímavost, velikost krychle pro dotaz x10 a 50MB vstupní soubor byla Pokud se podíváme, jaká je doba běhu funkce při zvětšujícím se vstupním souboru, vidíme že, doba provádění funkce výrazně roste. Při zvětšení vstupního souboru 10krát (z 1MB na 10MB) se doba běhu u dotazu x10 prodlouží 8krát a u dotazu x11 dokonce 44krát. Když budeme zkoumat závislost doby běhu funkce na složitosti dotazu při zachování velikosti vstupního souboru, opět dojdeme k závěru, že při zvětšení počtu dimenzí (požadavků na tvorbu skupin) o jedna se doba běhu mnohonásobně prodlouží. Například, pro vstupní soubor velikosti 10MB se při zvětšení dimenze ze dvou na tři doba běhu prodlouží 3,6krát. Při dalším zvýšení počtu dimenzí ze tří na čtyři se doba běhu zvětší dokonce 9,6krát Funkce cube3 Funkce cube3 vychází z funkce cube2, ale místo hyperkrychle reprezentované n- rozměrným polem využívá hašování. Dobu běhu funkce nalezneme v tabulce 4.7 a v grafu na obrázku MB 10MB 50MB 100MB x9 0,5607 1,6343 5,1173 9,2784 x10 0,7000 3, , ,1171 x11 0, , ,4920 Tabulka 4.7: Funkce cube3 doba běhu v sekundách. Obrázek 4.9: Funkce cube3 doba běhu v sekundách. Ani zde se nám nepovedlo naměřit vše. U dotazu x11 spuštěném na vstupním souboru velikosti 100MB byl výpočet ukončen z důvodu nedostatku paměti. Velikost krychle v tomto případě byla Při zkoumání vlivu velikosti vstupního souboru na dobu běhu vidíme, že pro dotaz se dvěma dimenzemi (x9) není nárůst doby provádění funkce nijak výrazný při zvětšení velikosti vstupního souboru. U dotazu x10, který obsahuje 50

51 tři dimenze, už však při zvětšení vstupního souboru 5krát (z 10MB na 50MB) vzroste doba výpočtu 9,8krát. U dotazu x11 se doba provádění funkce prodlouží dokonce 19,3krát. Pokud neměníme velikost vstupního souboru, ale zvyšujeme počet dimenzí v dotazu, doba běhu funkce výrazně roste již pro vstupní soubor velikosti 10MB, kde při zvýšení počtu dimenzí ze tří na čtyři doba výpočtu vzroste 4,8krát. Při použití vstupního dokumentu o velikosti 50MB se doba výpočtu prodlouží 9,5krát Srovnání funkcí cube, cube2 a cube3 Podíváme se na porovnání tří implementací konstrukce cube. První varianta, funkce cube, je založena na opakovaném volání funkce groupby2. Funkce cube2 reprezentuje hyperkrychli pomocí n-rozměrného pole v paměti. Poslední implementovaná varianta, funkce cube3, vychází z funkce cube2, ale pro buňky hyperkrychle používá hašování. Výsledky měření všech funkcí porovnáme na grafech. V grafech je vždy zobrazena doba běhu funkce v závislosti na položeném dotazu. V grafu na obrázku 4.10 máme situaci pro vstupní soubor velikosti 1MB. Druhý graf na obrázku 4.11 zachycuje situaci se vstupním dokumentem o velikosti 10MB. Graf z obrázku 4.12 je pak pro vstupní soubor velikosti 50MB a poslední graf na obrázku 4.13 zachycuje situaci pro vstupní dokument s velikostí 100MB. Obrázek 4.10: Srovnání funkcí cube, cube2 a cube3 doba běhu v sekundách pro vstupní soubor velikosti 1MB. Graf na obrázku 4.10 zachycuje situaci pro vstupní dokument velikosti 1MB. Vidíme, že pro všechny dotazy je nejpomalejší funkce cube. Dlouhá doba běhu je způsobena množstvím volání funkce groupby2 a tím i spoustou přístupů do databáze. Funkce cube2 a cube3 jsou pro všechny dotazy vyrovnané. U posledního dotazu x11, který vyžaduje tvorbu hyperkrychle dle čtyř dimenzí, je však funkce cube3 již nepatrně rychlejší a lze očekávat, že pro více dimenzí by odstup ještě narostl. Situaci se vstupním souborem velikosti 10MB vidíme v grafu na obrázku Pro dotazy x9 a x10 se opakuje situace z předchozího grafu funkce cube je 51

52 Obrázek 4.11: Srovnání funkcí cube, cube2 a cube3 doba běhu v sekundách pro vstupní soubor velikosti 10MB. Obrázek 4.12: Srovnání funkcí cube, cube2 a cube3 doba běhu v sekundách pro vstupní soubor velikosti 50MB. Obrázek 4.13: Srovnání funkcí cube, cube2 a cube3 doba běhu v sekundách pro vstupní soubor velikosti 100MB. 52