Uitwerking Tentamen XML & Databases [211096] woensdag 17 maart 2004; 13:30 16:30 open boek, d.w.z. geoorloofd: slides, artikelen, aantekeningen op papier 1 Algemeen Opgave 1 Noem de twee standaarden voor "document markup" die gezien worden als 'directe voorgangers' van de W3C XML standaard. Noem van beide standaarden tenminste één probleem dat de ontwikkeling van toekomstige webapplicaties in de weg staat, en vertel waarom de XML standaard een oplossing vormt voor deze problemen. HTML en SGML worden gezien als de directe voorgangers van XML. Het voornaamste probleem met SGML is a) dat deze standaard erg uitgebreid is, en het daarom moeilijk is om software te schrijven die de gehele standaard ondersteunt, en b) sommige delen van de standaard moeilijk efficiënt te implementeren zijn (bijvoorbeeld: in SGML is het in sommige gevallen toegestaan om geopende tags niet netjes te sluiten). Problemen met HTML zijn: a) HTML heeft een beperkte, vaste, verzameling tags; b) validatie van HTML documenten is moeilijk (omdat HTML een toepassing van SGML is), en c) HTML is met name gericht op presentatie, niet op datamodellering Opgave 2 Noem overeenkomsten, verschillen en mogelijke relaties tussen: a) XML "Document Type Definition" en XML "Schema Definition" b) XPath en XQuery a) Zowel een DTD als een XML schema definieert restricties op de XML data. De verschillen zijn onder andere: een DTD definieert een grammatica, een XSD definieert datastructuren en types; DTD definiëren allen "parent-child" relaties, XSD daarnaast ook overerving ("inheritence"); een DTD kent alleen de het datatype (P)CDATA, XSD kent vele datatypen. b) XPath en XQuery zijn beide declaratieve querytalen voor XML data. XPath 2.0 is een onderdeel van de XQuery 1.0 standaard. XPath definieert dus een subset van wat mogelijk is met XQuery. Het belangrijkste verschil tussen de beide is dat XQuery de generatie van (willekeurig welke) resultaten ondersteunt. 2 De moviedatabase Gegeven de relationele database "MovieDB" met het volgende schema. De volgende vragen zijn gebaseerd op het artikel "SQL/XML is Making Good Progress" van Eisenberg en Melton. CREATE TABLE movies (
movie_id INTEGER, title VARCHAR NOT NULL, year INTEGER NOT NULL, plot_outline VARCHAR, rating INTEGER, PRIMARY KEY (movie_id), ); CREATE TABLE persons ( person_id INTEGER, name VARCHAR NOT NULL, PRIMARY KEY (person_id) ); CREATE TABLE actors ( movie_id INTEGER, person_id INTEGER, role VARCHAR, FOREIGN KEY (movie_id) REFERENCES movies(movie_id), FOREIGN KEY (person_id) REFERENCES movies(person_id) ); Opgave 3 Geef de meest strikte DTD waaraan de SQL/XML "standard mapping" voldoet. De DTD ziet er als volgt uit: <!ELEMENT moviedb (movies, persons, actors) > <!ELEMENT movies (row*) > <!ELEMENT persons (row*) > <!ELEMENT actors (row*) > <!ELEMENT row ((movie_id, title, year, plot_outline, rating) (person_id, name) (movie_id, person_id, role)) > <!ELEMENT movie_id (#PCDATA) > <!ELEMENT title (#PCDATA) > <!ELEMENT year (#PCDATA) > <!ELEMENT plot_outline (#PCDATA) > <!ELEMENT rating (#PCDATA) > <!ELEMENT person_id (#PCDATA) > <!ELEMENT name (#PCDATA) > <!ELEMENT role (#PCDATA) > NB (extra informatie niet gerelateerd met het tentamen) sommige XML parsers (bijvoorbeeld xmllint) melden een ambiguous content model probleem met deze DTD. Deze parsers gebruiken een deterministische eindige automaat om XML documenten te valideren. Na <row> zijn er twee paden die beginnen met <movied_id>: geen deterministische automaat dus. Andere parsers kunnen alle BNF grammatica s aan (bijvoorbeeld Xerces) en melden geen probleem. Conclusie: het probleem ligt aan sommige parsers; de DTD is in orde. Om validatie door bijvoorbeeld xmllint ook mogelijk te maken kun je de definitie van row veranderen in: <!ELEMENT row ((movie_id, title, year, plot_outline, rating) (person_id, name) (role, movie_id, person_id)) >
Opgave 4 Geef een SQL/XML query die de volgende vraag beantwoordt: Geef titel, jaar en rating van die films die voor dat jaar de maximale rating hadden. Dit was achteraf een moeilijke SQL query. Weinig puntenaftrek als de XML generatie goed is, en als het antwoord wordt bepaald met een SQL sub-query. SELECT XMLELEMENT(NAME "movie", XMLELEMENT (NAME "title", title), XMLELEMENT (NAME "year", year), XMLELEMENT (NAME "rating", rating) ) ) AS RESULT FROM movies AS filmpjes WHERE rating >= ALL ( SELECT rating FROM movies WHERE movies.year = filmpjes.year ) Stel, we willen een "custom" XML view op de relationele database MovieDB definieren die voldoet aan de volgende DTD: <!ELEMENT movies (movie)* > <!ELEMENT movie (title, year, plot_outline?, rating?, actors)+ > <!ATTLIST movie movie_id ID #REQUIRED > <!ELEMENT actors (actor+) > <!ELEMENT actor (actor_name, role) > <!ELEMENT title (#PCDATA) > <!ELEMENT year (#PCDATA) > <!ELEMENT plot_outline (#PCDATA) > <!ELEMENT rating (#PCDATA) > <!ELEMENT actor_name (#PCDATA) > <!ELEMENT role (#PCDATA) > Opgave 5 Geef de SQL/XML query die de relationale database mapt naar een XML database die voldoet aan bovenstaande DTD. acteurs Recht-toe-recht-aan. Denk aan de GROUP BY en XMLAGG voor de SELECT XMLELEMENT(NAME, "movie", XMLATTRIBUTES ( movies.movie_id AS "movie_id"), XMLELEMENT(NAME, "title", title), XMLELEMENT(NAME, "year", year), XMLELEMENT(NAME, "plot_outline", plot_outline), XMLELEMENT(NAME, "rating", rating), XMLELEMENT(NAME, "actors", XMLAGG( XMLELEMENT(NAME, "actor", XMLELEMENT(NAME, "actor_name", name) XMLELEMENT(NAME, "role", role)
) ) ) ) AS result FROM movies, persons, actors WHERE movies.movie_id = actors.movie_id AND actors.person_id = persons.person_id GROUP BY movies.movie_id NB (1) Eigenlijk voldoet het resultaat van deze query niet aan de DTD omdat we het root element <movies> niet opleveren. NB (2) Het plusje + in de 2 e regel van de DTD hoort er eigenlijk niet te staan. Voor het beantwoorden van de vraag maakt het niet uit. Met of zonder +, het antwoord voldoet aan de DTD. De volgende vraag is gebaseerd op het artikel "Querying XML Views of Relational Data" van Shanmugasundaram et al. Opgave 6 Geef de XQuery query die de relationele database mapt naar een XML database die voldoet aan bovenstaande DTD. D.w.z. vanuit de standaard mapping, schrijf een XQuery query die hetzelfde resultaat geeft. Een mogelijke oplossing: <movies> { for $m in table("moviedb", "login", "password", "HR.movieDB.movies")/movies/row return <movie movie_id ={$m/movie_id}> { $m/title $m/year $m/plot_outline $m/rating } <actors> { for $a in table("moviedb", "login", "password", "HR.movieDB.actors")/actors/row where $a/movie_id = $m/movie_id return <actor> { for $p in table("moviedb", "login", "password", "HR.movieDB.persons")/persons/row where $p/person_id = $a/person_id return <actor_name> { $p/name/text()} <actor_name> } {$a/role} </actor> } </actors> </movie> } </movies>
Neem vanaf hier aan dat we werken op de XML view van de movie database. De volgende vraag is gebaseerd op het artikel "Retrieval Activities in a Database Consisting of Heterogeneous Collections of Structured Text" van Burkowski. Stel we zijn op zoek naar de titels van mafia- films over de familie Corleone. De volgende XPath query maakt gebruik van de functie contains om dat te bereiken: //movie[contains(.//role, "Corleone") and (contains(.//plot_outline, "maffia") or contains(.//plot_outline, "mob"))]//title Opgave 7 Formuleer de query in Burkowski's "algebra for contiguous text extents" De query wordt als volgt uitgevoerd: <title> SN { <movie> SW {<role> SW {"Corleone"}} SW {<plot_outline> SW {"maffia", "mob"}} } Toelichting: Het is het gemakkelijkst om met de contains functies te beginnen, dus contains(.//role, Corleone ) wordt: <role> SW {"Corleone"}; de and wordt in de algebra het herhaald toepassen van de SW operator; de or wordt een SW operator toegepast op een verzameling van term selecties; om de title te krijgen gebruik je tenslotte de SN operator. De volgende vraag is gebaseerd op het artikel "Using Language Models for Flat Text Queries in XML Retrieval" van Ogilvie en Callen. Het artikel beschrijft hoe een taalmodel voor elk XML element wordt gedefinieerd als een kansfunctie P. Bijvoorbeeld: P(w θ actors ) wordt gebruikt om het taalmodel voor de actors elementen aan te geven. Opgave 8 Leg uit hoe de taalmodellen van de actors elementen afhangen van de structuur van de data, en geef een definitie. Het taalmodel van een actors element wordt gedefinieerd als een lineaire interpolatie van de taalmodellen van de onderliggende elementen, waarbij λ i en µ j onbekende gewichten voor elk model die specifiek kunnen worden getraind voor een bepaalde taak of applicatie. Het taalmodel van een leaf node wordt geschat uit de tekst van de node. Aldus: k actors ) = λi P( w actor ) i= 1 P( w θ θ P ( w θ actor ) = µ 1P( w θ actor_name ) + µ 2P( w θ role ) P w θ ) = P( w θ ) and P w θ ) = P( w θ ) where θ T defines text nodes ( actor_name T ( role T P w θ ) = ( T freq( w,t) T
3 De webshop Een webshop gebruikt intern XML om orderinformatie tussen computersystemen uit te wisselen volgens de onderstaande DTD (orders.dtd). Zo n XML-document wordt in een bericht gestopt dat van het ene naar het andere systeem gecommuniceerd wordt. <!ELEMENT orders (order*) > <!ELEMENT order (line+) > <!ATTLIST order total CDATA #REQUIRED > <!ELEMENT line (article, qty, price) > <!ELEMENT article (#PCDATA) > <!ATTLIST article id CDATA #REQUIRED > <!ELEMENT qty (#PCDATA) > <!ELEMENT price (#PCDATA) > Hieronder een voorbeeld van een XML-bericht bericht.xml zoals dat uitgewisseld had kunnen worden (boldface wordt gebruikt om enkele elementen te markeren): <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE orders SYSTEM "orders.dtd"> <orders> <order total="10.89"> <line> <article id="10">potlood</article> <qty>2</qty> <price>1.95</price> </line> <line> <article id="23">papier</article> <qty>1</qty> <price>6.99</price> </line> </order> <order total="1.95"> <line> <article id="10">potlood</article> <qty>1</qty> <price>1.95</price> </line> </order> </orders> De informatie over orders en artikelen ligt natuurlijk wel ergens opgeslagen in tabellen, maar men heeft besloten de berichten zelf ook op te gaan slaan, onder andere t.b.v. debugging: dan kun je mooi zien welke berichten er zijn uitgewisseld en er naderhand query s op uitvoeren om fouten te vinden en de diagnostiseren. Opgave 9 Geef een XPath query die alle artikelen oplevert die duurder zijn dan 5 euro.
//article[./following-sibling::price >5] of //line[./price > 5]/article Opgave 10 Geef een XQuery query die per artikel aangeeft hoeveel ervan besteld zijn (let op! Van het potlood zijn er 3 verkocht: twee in de eerste order, eentje in de tweede). let $doc := document( bericht.xml ) for $artid in distinct-values($doc/article/@id) let $qty := sum($doc/article[@id = $artid]/following-sibling::qty), $art := $doc//article[@id=$artid and position()=1] return <result>{$art}<nrsold>{$qty}</nrsold></result> De volgende vragen zijn gebaseerd op de artikelen Accelerating XPath location steps van Grust, en Staircase Join: Teach an RDBMS to Watch its (Axis) Steps van Grust et.al. Opgave 11 Teken de XML-boom met preorder en postorder getallen van bericht.xml. 1:orders:29 2:order:18 20:order:28 3:@total=10.89:1 4:line:9 21:@total=1.95:19 25:line:27 5:article:4 8:qty:6 10:price:8 22:article:22 26:qty:24 28:price:26 6:@id=10:2 7: potlood :3 9: 2 :5 11: 1.95 :7 12:line:17 23:@id=10:20 24: Potlood :21 27: 1 :23 29: 1.95 :25 13:article:12 16:qty:14 18:price:16 14:@id=23:10 15: Papier :11 17: 1 :13 19: 6.99 :15 Opgave 12 Stel bericht.xml is opgeslagen in tabel accel volgens het XPath accelerator artikel. Het artikel geeft ook aan hoe XPath query s geëvalueerd kunnen worden m.b.v. SQL. Geef de SQL query die de XPath query van Opgave 9 evalueert. Afhankelijk van de query bij 9 krijgt je hier iets anders, bijvoorbeeld //article[./following-sibling::price >5] : SELECT DISTINCT art.pre FROM accel as art, accel as pr, accel as prtxt, cdata as prcdata WHERE art.pre>1 AND art.post < 29 AND art.name= article AND pr.pre > art.pre AND pr.post > art.post AND pr.parent = art.parent AND pr.name = price AND prtxt.parent = pr.pre AND prcdata.pre = prtxt.pre AND prcdata.cdata > 5 ORDER BY art.pre //line[./price > 5]/article : SELECT DISTINCT art.pre FROM accel as lin, accel as art, accel as pr, accel as prtxt, cdata as prcdata WHERE lin.pre>1 AND lin.post < 29 AND lin.name= line
AND pr.parent = lin.pre AND pr.name = price AND prtxt.parent = pr.pre AND prcdata.pre = prtxt.pre AND prcdata.cdata > 5 AND art.parent = lin.pre AND art.name= article ORDER BY art.pre Opgave 13 De drie article-elementen (aangegeven in boldface) vormen de context node sequence $cs. We gaan m.b.v. de staircase join $cs/descendant::* evalueren. a) Welke elementen worden uit $cs verwijderd als gevolg van pruning? b) De overgebleven elementen definieren partities p i p i+1. Geef aan welke partities het in dit geval worden. c) Tijdens het evalueren van de staircase join worden niet alle nodes van het document bekeken als mogelijke node van het resultaat. Hoeveel nodes worden er bekeken als er geen skipping gebruikt wordt? En hoeveel als je wel skipping gebruikt? Verklaar je antwoord. (a) geen (b) afhankelijk van getekende boom: 5-12; 13-21; 22-eind (c) geen skipping: 25 (elke contextnode + partities beginnend na context node) (c) wel skipping: (3x3+3=12: per context node, de context node zelf + descendants + first following vanwaar geskipt wordt). De volgende vraag is gebaseerd op het artikel Efficient Relational Storage and Retrieval of XML Documents" van Schmidt et al. Opgave 14 Stel bericht.xml is opgeslagen in tabellen uit de sets R en A. Het artikel geeft aan hoe XPath query s geëvalueerd kunnen worden m.b.v. SQL. Geef de SQL query die de XPath query van Opgave 9 evalueert. In de volgende query wordt de underscore gebruikt in plaats van het pijltje in de notatie van Schmidt et al. SELECT a.oid FROM orders_order_line l, orders_order_line_article a, orders_order_line_price p, orders_order_line_price_cdata c, orders_order_line_price_cdata_string s, WHERE l.oid = a.parent AND l.oid = p.parent AND p.oid = c.parent AND c.oid = s.oid AND s.string > 5 Toelichting: in het papertje van Schmidt et al. Staat een query met een SELECT, FROM en WHERE deel, waarvan de semantics are similar to [3]. Wat precies de semantiek van de query is, wordt dus niet duidelijk uit het paper, maar het is in elk geval geen standaard SQL query. Bovenstaande query is dat wel. Mensen die echter de query
uit het paper hebben aangepast aan de webshop situatie, hebben een deel van de punten gekregen. De volgende vragen zijn gebaseerd op het artikel Storing and Querying Ordered XML Using a Relational Database System van Tatarinov et.al. Opgave 15 In paragraaf 3.4 worden drie dimensies van XML ordening genoemd. Welke dimensies worden door de staircase join bediend? Verklaar je antwoord. axes wel, functions als position niet; result set ordering wel; element reconstruction is discutabel: op zich wordt er weinig over gezegd, maar aan de andere kant is voor reconstructie het simpelweg een zaak van de descendants bepalen en dat wordt wel ondersteund. Opgave 16 In paragraaf 4 worden verschillende soorten encodings besproken. Tot welke encoding behoort de preorder/postorder encoding van de XPath accelerator? Global Order Encoding. De volgende vragen zijn gebaseerd op het artikel Views in a large-scale XML repository van Aguilera et.al. In Nederland is er iemand die informatie over artikelen verzamelt. De eigenaars van de webshop geven toestemming dat hun berichtendatabase gebruikt mag worden; er zit immers ook informatie over artikelen in. Voor de informatieverzameling over artikelen gebruikt men Xyleme, het systeem uit het artikel. De Nederlander heeft de volgende abstracte DTD opgesteld voor z n artikelenverzameling. artikelen artikel beschrijving prijs Opgave 17 Geef alle path-to-path mappings van deze abstracte DTD naar de concrete DTD orders.dtd. artikelen heeft geen tegenhanger. artikelen/artikel -> orders/order/line/article artikelen/artikel/beschrijving -> orders/order/line/article artikelen/artikel/prijs -> orders/order/line/price Opgave 18 Welke vormen van matching heb je gebruikt voor het vinden van deze mappings: syntactic, semantic or structural matching? Verklaar je antwoord. Als mens gebruik ik natuurlijk met name semantic matching: ik weet dat artikel het Nederlandse woord is voor article. Daarbij gebruik ik ook structural matching, want
woorden als article hebben natuurlijk meer betekenissen, maar uit de context blijkt duidelijk dat het wel matcht. Syntactic matching gebruik je als mens wellicht niet in zo n geval, maar een computer zou dat in eerste instantie waarschijnlijk wel doen, want article lijkt op artikel De volgende vraag gaat over het PowerDB-systeem (tentamenstof was slides + die concepten uit het artikel die ook op het college behandeld zijn). Opgave 19 In het PowerDB-systeem worden XML-documenten gefragmenteerd, worden er sidetables toegevoegd en inverted lists t.b.v. information retrieval. Stel de webshop wil PowerDB gaan gebruiken om hun berichten op te slaan. Hoe zou je de berichten fragmenteren (d.w.z. welke fragment root kies je?), welke sidetable(s) zou je introduceren en welke elementen/attributen zou je betrekken in de inverted list? Verklaar je antwoord. Fragmenteren op order lijkt meest waarschijnlijke. Per order is het aantal regels waarschijnlijk niet zo groot, wel heel veel orders na elkaar mogelijk. Side table voor article(id,description,price?) ligt voor de hand (gezien ook vermijding van replicatie). Verder kunnen line(article_id, qty,price?,ref to generated order_id) en order (total, generated order_id). Inverted list is voor zoeken in teksten. Hier geen grote verhalen, dus dubieus of inverted list handig is, maar zo ja, dan voor de tekst van articles. 4 XML bij Elsevier De volgende vraag gaat over het gastcollege van Rob Schrauwen van Elsevier (geen bijbehorend artikel; alleen slides). Opgave 20 Rob heeft verteld dat het eerste wat Elsevier doet met een geaccepteerd artikel dat binnenkomt, is hem omzetten in XML. Vervolgens worden alle bewerkingen uitgevoerd op het XML-document, die uiteindelijk ook m.b.v. een stylesheet de enige bron is voor de uiteindelijke opmaak op internet of papier. Elsevier krijgt per dag gemiddeld 1000 geaccepteerde artikelen te verwerken. Bovendien, zit een artikel gemiddeld 100 dagen in het proces. In de database met actieve artikelen liggen dus gemiddeld 100.000 artikelen in XML-formaat opgeslagen. Van alle systemen en opslagmethoden die in dit college de revue zijn gepasseerd, welke vind je het meest geschikt voor Elsevier voor hun database met actieve artikelen? Verklaar je antwoord. Het gaat hier puur om de argumentatie van het antwoord en de inzicht die daaruit blijkt. Hier zijn veel antwoorden mogelijk, maar het gaat om aspecten die je noemt en inzicht in hoe goed de systemen/methoden zijn op die aspecten. Wat je kunt noemen is het feit dat de artikelen document-centric XML zijn: opslag à la Shanmugasundaram is daar niet goed in. Ander aspect is dat er veel geüpdated wordt: daar is de XPath accelerator weer niet goed in, want échte updates (vervanging van een subboompje door een mogelijkerwijs groter subboompje) vergen hernummeringen en die zijn duur. Zoeken wordt in deze artikelen waarschijnlijk niet eens zoveel gedaan (althans niet met de actieve die nog in het proces voor publicatie zitten), maar wel in z n geheel als output geven t.b.v. presentatie. PowerDB die fragmenten als tekst opslaat zou dit
laatste wel aardig kunnen, ook dat updaten wel. En als er gezocht wordt, dan wellicht fulltext search en daar heeft PowerDB speciale faciliteiten voor. Ik verwacht dat een Native XML DBMS hier om dezelfde redenen ook goed, misschien wel beter, zou kunnen presteren. Robuustheid is een aspect dat spreekt voor de aanpakken op relationele DBMSen.