Onderzoek native XML databases

Transcriptie

1 Onderzoek native XML databases Vincent Fleur Dennis Heij

2 Voorwoord Dit onderzoeksrapport is geschreven door Dennis Heij en Vincent Fleur. Beide zijn laatstejaars student van de opleiding kort Bedrijfskundige Informatica aan het instituut I&I van de Saxion Hogeschool IJselland te Deventer. Dit document is het resultaat van een afstudeerperiode van februari 2002 tot juli 2002 bij Thales Nederland B.V. te Hengelo. We willen een aantal mensen danken, welke hebben bijgedragen aan het tot stand komen van dit document. Allereerst danken we Jan Swets, onze begeleider bij Thales. Jan heeft ons veel nuttige adviezen gegeven en ons bij ons onderzoek begelied. Speciale dank gaat uit naar Gerrit te Vaarwerk die met een positieve kijk op de situatie ons wist te motiveren en te stimuleren. Hij kwam regelmatig op onze kamer een kopje koffie drinken en bracht af en toe zijn eigen werk mee. Gerrit heeft ons geholpen bij het vormgeven van dit document en daarvoor zijn we hem uiterst dankbaar. Als laatste danken we u als lezer, omdat u interesse toont in ons werk. Vincent Fleur Juni 2002 Dennis Heij

3 Samenvatting Dit document is het resultaat van een onderzoek naar de functionaliteit, mogelijkheden en toepassingsgebieden van native XML-databases ten opzichte van de functionaliteit van traditionele databases. Native XML databases zijn speciaal ontwikkeld voor de opslag van XML documenten. Evenals andere databases ondersteunen ze de meest gangbare functies. Het verschilt per systeem welke functies er ondersteund worden. Het grote verschil met traditionele databases is, dat het interne model is gebaseerd op XML en niet op bijvoorbeeld een relationeel model. Dit brengt grote voordelen met zich mee die zich voornamelijk uiten in snelheid en mogelijkheden. Ook zijn er voor native XML databases specifieke query talen, die beter inspringen op de structuur van een XML document. De keuze voor een native XML database of voor een traditionele database, hangt af van de situatie. Als men veel met data-centric XML documenten werkt, is het verstandiger om voor een traditionele database te kiezen. Wordt er meer met document-centric documenten gewerkt, dan kan er beter voor een native XML database gekozen worden. We hebben twee Content Management Systems in de praktijk getest en onderzocht. Tamino XML Server, van Software AG en X-Hive, van X-Hive. Het bleek dat deze twee CMS's meer hadden te bieden dan anderen en waren daarom een nader onderzoek waard. Tamino wordt geïnstalleerd met een aantal applicaties van waaruit de mogelijkheden die het programma biedt zijn te gebruiken. Bij X-Hive wordt er maar een applicatie geinstalleerd, van waaruit een beperkt aantal mogelijkheden te gebruiken zijn. De overige mogelijkheden van X-Hive worden toegepast door middel van Java Classes. Creatie van content is mogelijk vanuit de applicatie die bij X-Hive geïnstalleerd wordt, maar is zeer beperkt. Bij Tamino is er geen mogelijkheid om content te creëren. Via WebDAV is integratie mogelijk met XML editors als Xmetal en XML-Spy. In X-Hive kan elk soort document in elke Library van de database worden opgeslagen. Als men valid XML documenten in X-Hive wil opslaan, dan moet er in het document zelf een verwijzing naar het DTD staan. Tamino maakt voor het opslaan van documenten geen gebruik van Libraries, maar van Collections. Bij Tamino is het mogelijk om d.m.v. de Scheme Editor, schema's van een DTD toe te wijzen aan zo'n Collection, valid XML documenten die conform dat schema gemaakt zijn, kunnen in die Collection worden opgeslagen. Well-formed en non-xml documenten, worden door Tamino respectievelijk in de Collections ino:etc en ino:nonxml opgeslagen. Beide CMS's beschouwen SGML data als non-xml. Indexing moet bij Tamino worden aangegeven in het schema dat bij een Collection hoort. Bij X-Hive gebeurt indexing door Java Classes. Bij beide de CMS's zijn verschillende niveaus waarop kan worden geindexeerd. Indexing bevordert het gemak en de snelheid waarmee queries op de database worden uitgevoerd. Het is dus aan de gebruiker om goed na te denken wat van belang is om geindexeerd te worden. X-Hive ondersteunt locking op library level, XLink en Branching. Tamino doet dit niet.

4 Tamino kent wel een mogelijkheid waarmee grote hoeveelheden data tegelijk opgeslagen kunnen worden. De Pass-thru servlet, is een onderdeel van Tamino, waarmee verschillende publishing varianten mogelijk zijn. Bij X-Hive gebeurt dit door middel van Java Classes.

5

6 Inhoudsopgave Voorwoord 2 Samenvatting 3 Lijst van afkortingen Inleiding Thales Nederland B.V Doelstelling van de opdracht Vooronderzoek Taken en activiteiten Resultaten vooronderzoek XML testbestanden Inventarisatie Over Content Management Systems in het algemeen Authoring Workflow en Storage Publishing Omvang van een Content Management Systeem XML en databases Data versus Documenten Opslaan en opvragen van data Opslaan en opvragen van documenten Native XML databases Wat is een native XML database Native XML database architecturen De features van native XML databases Normalisatie, referentiële integriteit en scalability Native XML database versus traditionele databases WebDAV De WebDAV standaard De voordelen van WebDAV Tamino XML Server Inleiding Algemene Informatie Aan de slag met Tamino Authoring Integratie van Tamino met XML editors Workflow & Storage Publishing Tamino WebDAV Server Tamino WebDAV Server Aan de slag met de Tamino WebDAV Server X-Hive/DB Inleiding Algemene Informatie Aan de slag met X-Hive Authoring Workflow & Storage X-Hive Publishing Tamino versus X-Hive 72 6

7 Installatie Interface Authoring Workflow & Storage Publishing XML publicatiestraat Authoring Workflow & Storage Publishing Toepassingsgebieden van XML en databases Vliegtuigmaatschappij Handleiding Conclusie Content Management Systems XML en databases WebDAV Tamino versus X-Hive XML publicatiestraat Aanbevelingen Bronnen Productomschrijvingen Informatieve naslagwerken Internet bronnen...88 Bijlage 1, Plan van Aanpak Bijlage 2, Inventarisatie XML Content Management tools 7

8 Lijst van afkortingen API Application Programming Interface ASP Active Server Pages BLOB Binary Large OBject CDATA Character Data CMS Content Management SYstem CSS Cascading Stylesheet CVS Concurrent Versioning System DOM Document Object Model DTD Data Type Definition FTP FIle Transfer Protocol HTML Hyper Text Markup Languiage HTTP Hyper Text Transfer Protocol IETF Internet Engeneering TaskForce IIS Internet Information Server JDBC Java DataBase Connectivity JRE Java Runtime Environment JSDK Java Servlet Development Kit JSP Java Server Pages JVM Java Virtual Machine ODBC 8

9 Open DataBase Connectivity OLE DB Object Linking and Embediing for DataBases PCDATA Parsed Character Data PDF Portable Document Format PHP Hypertext Pre Processor RADAR Radio Detection and Ranging RDBMS Relational Database Management System SGML STandard Generalized Markup Language SMH System Management Hub (Administratie applicatie van Tamino) SQL Structured Query Language URL Unified Resource Locater WAP Wireless Acces Protocol WebDAV Webbased Distribution Auhtoring and Versioning WML Wireless Markup Language Xlink XML Link XML EXtensible Markup Language XSL Xml Stylesheet Language XSLT XML Stylesheet Language Transformation XSQL XML Structured Query Language XQL XML Query Language 9

10 1 - Inleiding Thales Nederland B.V. Thales Nederland B.V. is in 1922 begonnen onder de naam "NV Hazemeijers Fabriek van Signaalapparaten". Deze fabriek produceerde wapenbesturingssystemen. In 1947 werd de naam veranderd in "Hollandse Signaalapparaten N.V." In samenwerking met Philips werd begonnen aan het ontwikkelen van digitale RADAR systemen. Signaal integreerde zijn radar systemen met de wapenbesturingssystemen en was daarmee de concurrentie een stap voor. De kerntaken van Signaal verschoven van het mechanische deel, naar het elektrotechnische gebied. In 1992 is Signaal overgenomen door het Franse Thompson-CSF. In 2000 werd de naam veranderd in "Thales Nederland B.V." Thales Nederland is een grote speler op de wereldmarkt, zeker als het gaat om zogenaamde Naval Combat Systems. Voornamelijk overheden zijn klant bij Thales. Zo heeft de Nederlandse Marine veel van haar fregatten voorzien van apparatuur van Thales. In totaal heeft Thales sinds 1970 ongeveer 200 schepen van apparatuur voorzien. Naast de levering van producten voorziet het programma van Thales ook in uitgebreide service en onderhoud. Ook is er een trainingscentrum waar klanten worden opgeleid om met het Thales product te werken en dit te onderhouden. Thales wereldwijd heeft ongeveer medewerkers daarvan werken bij Thales Nederland B.V. waarvan de hoofdvestiging zich in Hengelo (OV) bevindt. Naast deze vestiging is er een kleine vestiging in Delft, waar men zich voornamelijk bezighoudt met optische systemen Doelstelling van de opdracht Kern van de opdracht is het uitvoeren van een onderzoek naar de functionaliteit, mogelijkheden en toepassingsgebieden van native XML-databases ten opzichte van de functionaliteit van traditionele databases. Om deze doelstelling te bereiken hebben we een aantal onderzoeksvragen opgesteld, welke in ons Plan van Aanpak zijn na te lezen. Dit plan hebben we als bijlage bijgevoegd. We hebben een vooronderzoek gedaan om meer inzicht te krijgen in het onderwerp. De resultaten hiervan komen in het volgende hoofdstuk aan de orde. 10

11 2 - Vooronderzoek Wat moet er nu daadwerkelijk onderzocht worden? Waarop moeten we de pakketten testen, welke pakketten moeten we eigenlijk onderzoeken en hoe testen we een pakket? Om op die vragen een antwoord te vinden, voeren we eerst een vooronderzoek uit Taken en activiteiten Hieronder volgt een lijst van activiteiten die in dit vooronderzoek aan de orde komen. Opstellen criteria waaraan een content manager moet voldoen Opstellen criteria waaraan een native XML-database moet voldoen Opstellen testomgeving, welke moet bestaan uit: XML bestanden DTD's en/of schema's XSL stylesheets Inventariseren native XML-databases die we gaan onderzoeken Inventariseren hard- en softwarematige eisen van geselecteerde native XML-databases Opstellen onderzoeksplanning Resultaten vooronderzoek Uit het vooronderzoek zijn de volgende resultaten gekomen Onderzoeksvragen Algemene Vragen Welke van de onderdelen (authoring, workflow, storage, publishing) biedt het CMS aan? Wat zijn de eisen van het pakket aan de infrastructuur? Voor welke toepassing is het CMS volgens de fabrikant ontworpen? Welke content formaten kan het CMS importeren/ exporteren? Welke documentatie wordt bij het CMS geleverd? Vragen die betrekking hebben op het onderdeel Authoring Hoe is de aansluiting van de content creatie omgeving op de overige onderdelen van het CMS en wat merken auteurs daarvan? Hoe strikt is de scheiding tussen content en publicatie? Hoe is multi-user authoring geregeld? Welke eisen stelt het CMS aan content? Hoe gaat het CMS om met XML, XSLT, DTD's en XML namespaces? Hoe wordt metadata vastgelegd, gebeurt dit bijvoorbeeld door indexes? Hoe wordt omgegaan met links en wat merken auteurs daarvan? Welke kennis hebben auteurs nodig om met het systeem te werken? Welke inspanning is nodig voor het creëren van content? 11

12 Welke inspanning is vereist voor het importeren van SGML content? Vragen die betrekking hebben op het onderdeel Workflow en Storage Op welke wijze wordt content door het CMS opgeslagen, is dat in een relationele database, een traditionele database of als XML-files? Hoe wordt door het CMS omgegaan met version control? Hoe is de beveiliging van het CMS? Kan het CMS samenwerken met andere applicaties? Tot in welke mate verzorgt het CMS administratieve rapporten? Welke query language gebruikt het CMS, XPath, XQL, XQuery of XSQL? Vragen die betrekking hebben op het onderdeel Publishing Hoe flexibel kan het CMS omgaan met stylesheets? Op welke wijze worden stylesheets toegepast? Naar welke formaten kan het CMS content publiceren en zijn die volgens een standaard gedefinieerd? XML testbestanden We hebben met de tool XMetal van Softquad een aantal XML bestanden gemaakt. XMetal is een tool, waarvan de user interface naar wens aanpasbaar is. Zo kunnen er eigen menu's en toolbars gedefinieerd worden en kan er vanuit de ResourceManager (onderdeel van XMetal) repeterende elementen in een document worden ge-dragged and dropped. De opzet is zodanig, dat een programmeur de tool en omgeving configureert, zodat een auteur er als in MS Word mee kan werken. Onze testdocumenten zijn conform het Journalist DTD, welke een subset van de DocBook DTD is. We hebben voor de Journalist DTD gekozen, omdat XMetal belangrijke elementen als stylesheets en macro's bevat die voor deze DTD gemaakt zijn. Het kost ons te veel tijd om XMetal zodanig te configureren, dat het met DocBook uit de voeten kan. Het zal voor ons onderzoek weinig verschil uitmaken, of we nu met de DocBook zelf of een subset daarvan werken. Voor onze testset, hebben wij gebruik gemaakt van: XML bestanden conform het Journalist DTD, XSL bestanden en van een DTD Inventarisatie De inventarisatie bestaat uit het globaal onderzoeken wat de mogelijkheden zijn die het product volgens de fabrikant biedt. Dit heeft een document opgeleverd waarin onze bevindingen staan. Dit document is als bijlage toegevoegd aan ons verslag. Na de inventarisatie hebben we ervoor gekozen, om drie producten nader te onderzoeken. Helaas zijn wij er niet aan toegekomen om er daadwerkelijk drie te testen. Dit vanwege tijdgebrek. Uiteindelijk hebben we twee systemen nader onderzocht. Dit zijn geworden Tamino XML Server en X-Hive. Voor die keuze hebben we de volgende motivatie: Uitgebreide documentatie en specificatie Er was over beide producten veel informatie te vinden op het internet. Hierdoor kregen we al snel een globale eerste indruk van de mogelijkheden van beide producten. 12

13 Gebruik van native XML database Gebruik van WebDAV WebDAV is een uitbreiding van het HTTP protocol, hierdoor kunnen gebruikers gezamenlijk bestanden bewerken en opslaan op een webserver. Verdere uitleg over WebDAV volgt verderop in het verslag. Naamsbekendheid / aanbeveling van Jan Swets Uit verschillende essays op het internet, waarin kleine vergelijkingen naar voren kwamen, werden Tamino en X-Hive aanbevolen. Ook onze stagebegeleider van Thales Nederland BV, was zeer geïnteresseerd in de mogelijkheden van deze twee producten. 13

14 3 - Over Content Management Systems in het algemeen Content Management bestaat globaal uit vier onderdelen: Authoring Workflow Storage Publishing In dit verslag proberen we continu onderscheid te maken tussen bovenstaande vier onderdelen. Workflow en storage hangen nauw met elkaar samen, daarom bespreken we deze ware het een onderdeel Authoring Onder authoring wordt in het algemeen verstaan het creëren van content. Om als gebruiker/auteur zelf content te creëren, moet deze de beschikking hebben over een DTD en over een content creatie tool, waarmee uitgebreide editting opties mogelijk zijn. Door het document conform een DTD te maken, wordt het document een valid XML-document. Het is niet verplicht een document conform een DTD te maken, in dit geval wordt gesproken van een well formed XML-document Workflow en Storage Met workflow bedoelen we de automatisering van de levenscyclus van een content element. Het gaat hier dan om het managen van taken tussen het creëren van content en het opslaan van content. Voorbeelden van dit soort taken zijn: link checking, validatie aan DTD, zorgdragen van goedkeuring van content door een bovengeschikte en indexing. Indexing houdt in dat een Content Management Systeem een index van de elementen van een XML document maakt en deze vastlegt in een apart bestand. Als er vervolgens bijvoorbeeld een query op het document uitgevoerd wordt, wordt er in de index gezocht i.p.v. dat het hele document doorzocht wordt. Dit scheelt aanzienlijk in tijd. Wij bedoelen met storage niet het daadwerkelijke schrijf proces, maar het proces dat zorg draagt voor de opslag van documenten. Opslag vindt plaats als record in een database of als XML file. Het is dus niet zo dat het daadwerkelijke schrijven een onderdeel van een CMS is. Bij storage hoort ook versioning van content, zodat meerdere individuen tegelijkertijd aan hetzelfde document kunnen werken en dat oudere versies van een doocument hersteld kunnen worden Publishing Publishing is een algemene term die wij gebruiken voor het publiceren van content. Onder de content vallen de XML documenten die opgeslagen zijn in de database. Een belangrijke vraag die hierbij een rol speelt is naar welke formaten er gepubliceerd kan worden. Voorbeelden van die formaten zijn: HTML en PDF. 14

15 3.4 - Omvang van een Content Management Systeem De onderdelen die een CMS minimaal moet bevatten zijn workflow en storage. Eventuele andere onderdelen die een CMS kan aanbieden zijn: user management Dit zijn taken m.b.t. gebruikersbeheer zoals het toewijzen van rechten. user interfaces Een applicatie voor administratie van het CMS en de content. data sources De locatie waar content wordt opgeslagen. Dit kan zijn een relationele database of XML files. Hier vindt het daadwerkelijke schrijfproces plaats. applications Deze applicaties integreren de content met bestaande data en voeren softwarematige manipulaties uit op content om de consistentie te waarborgen. Een dergelijke applicatie is meestal een formulier waarmee de publicatie van content centraal geregeld wordt. Voorbeelden hiervan zij indexing en searching, maar ook middleware dat er zorg voor draagt dat database records gebruikt kunnen worden in dynamische web-pagina's. Voorbeelden van die middleware zijn: ODBC, JDBC, ASP, Perl en PHP. 15

16 4 - XML en databases In dit hoofdstuk wordt ingegaan op de relatie tussen XML en databases. We zullen duidelijk maken wat het verschil is tussen traditionele databases en native XML-databases Data versus Documenten XML kan op verschillende manieren gebruikt worden. Zo kan XML dienen als data-transport tussen een database en een (non-xml) applicatie. Of XML kan integraal gebruikt worden zoals bijvoorbeeld met DocBook documenten of XHTML. Hoewel er vele overeenkomsten zijn tussen twee soorten XML documenten, wordt er toch onderscheid gemaakt tussen data-centric documents en document-centric documents omdat de verschillen van belang zijn voor de wijze van opslag in een database Data-centric XML documenten Data-centric XML documenten zijn documenten die XML gebruiken als data transport. Ze zijn bedoeld om door een computer verwerkt te worden. Het maakt voor een applicatie niet uit dat de data voor een bepaalde tijd in een database is opgeslagen. Voorbeelden van data-centric documenten zijn verkooporders, vluchtschema's, wetenschappelijke data en beurskoersen. Kenmerkend voor data-centric XML documenten zijn de regelmatige structuur en de weinige of geen gemengde content. Onder gemengde content verstaan we elementen die meerdere soorten inhoud bevatten, bijvoorbeeld een element dat een ander element en tekst bevat. De volgorde waarin elementen staan is vaak niet belangrijk tenzij het document gevalideerd wordt. Data-centric documenten kunnen m.b.v. een XSL stylesheet worden getransformeerd tot een voor publiek leesbaar document. Elke website die momenteel gebruik maakt van dynamisch gegenereerde HTML pagina's (templates die gevuld worden met database data) kan waarschijnlijk worden vervangen door een serie van data-centric XML documenten en één of meer XSL Stylesheets. Het onderstaande sales order document is data-centric: 16

17 <SalesOrder SONumber="1234"> <Customer CustNumber="543"> <CustName>Grolsch breweries</custname> </Customer> <OrderDate>170502</OrderDate> <Item ItemNumber="1"> <Part PartNumber="123"> <Price>9,95</Price> </Part> <Quantity>12</Quantity> </Item> </SalesOrder> Document-centric XML documenten Document-centric XML documenten zijn het meest geschikt als communicatiemiddel. Voorbeelden zijn boeken, s, advertenties en eigenlijk elk hand geschreven XHTML document. Kenmerkend zijn de onregelmatige structuur en de diversiteit van de betreffende content. De volgorde van de elementen is meestal erg belangrijk. Onderstaande product omschrijving is document-centric: 17

18 <Product> <Name>Notebook</Name> <Developer>Asus</Developer> <Description> <Para>Notebook with finger-print security on BIOS and Windows. You are the only one with access to your pc. The notebook comes with a P MHz processor and 512 MB RAM. With the 15 inch TFT screen and DVD player you can watch movies anywhere you like</para> <Para>You can:</para> <List> <Item><Link URL="order.html">Order this notebook</link></item> <Item><Link URL="specs.html.">Read the technical specifications</link></item> <Item><Link URL="search.html">Search for another notebook</link></item> </List> </Descriotion> </Product> Data, documenten en databases Het onderscheid tussen data-centric en document-centric XML documenten is niet altijd even duidelijk aan te geven. Ondanks dat is er toch een soort algemene regel wat betreft het type document en de bijbehorende database. Deze regel is afgeleid uit de tendens op de markt. Data-centric XML documenten worden opgeslagen in traditionele databases, zoals relationele, object-georienteerde of hierarchische databases. Document-centric XML documenten worden opgeslagen in een native XML database (een database speciaal ontworpen voor het opslaan van XML). Uiteraard is deze regel niet een wet van Meden en Perzen, want data kan opgeslagen worden in een native XML database en documenten in een traditionele database. Tevens beginnen de grenzen tussen traditionele databases en native XML databases te vervagen, beide nemen toepassingsmogelijkheden van elkaar over Opslaan en opvragen van data Elk type database slaat data op een bepaalde manier op. XML data wordt aangeboden aan de database. Een bepaald stuk software is hiervoor verantwoordelijk. Die software moet een XML document naar de database vervoeren en vice versa. Deze software kan deel uitmaken van het database systeem, in dat geval spreken we van een XML-enabled database. 18

19 Data transport Bij transport van een data-centric XML document naar een database is het vaak acceptabel om informatie over het document, zoals de naam en het DTD weg te gooien. Het gaat tenslotte om de data en de overige zaken zijn van ondergeschikt belang. De fysieke structuur zoals entiteiten definities en gebruik, de wijze waarop binary data wordt opgeslagen, CDATA secties en encoding informatie kan weggegooid worden. Het is zelfs acceptabel om de logische structuur, bepaalde processing instructies en de volgorde van elementen en attributen te vergeten. Bij transport van data uit een database naar een XML document is het wenselijk dat het document geen CDATA en entiteit gebruik bevat (afgezien van standaard entiteiten als lt, gt, amp, apos en quot). Een CDATA sectie is een sectie waarin het gebruik van markup genegeerd wordt. In het geval van een data-centric XML document zijn CDATA secties nutteloos. Het bevat namelijk geen data die ook echt als data behandeld wordt. Entiteiten dienen gedeclareerd te worden, dit kan in een DTD of direct in een XML document. De standaard entiteiten behoeven geen aparte declaratie. Als er stukkken data uit een data-centric XML document gehaald worden en deze stukken bevatten andere dan standaard entiteiten, dan moet er altijd een entiteit declaratie aan het stuk informatie toegeveogd worden. Dit maakt het werken met entiteiten onhandig en is dus niet gewenst. Het is gewenst dat de hiërarchische strucuur van de XML en de positie van elementen in die structuur dezelfde is als de volgorde van de elementen zoals die in de database zit. Er is dan geen tussenstap vereist die de data in gewenste volgorde in het XML document plaatst. Ook het model daarvoor is dan overbodig. Om bovenstaande beweringen toe te lichten geven we een voorbeeld waarin XML data gebruikt wordt om data te transporteren tussen twee databases. We nemen het geval van de sales order. Het maakt niet uit of het sales order number is opgeslagen in een CDATA sectie, een externe entiteit, een attribuut of direct als PCDATA. Het gaat erom dat de data van de ene database wordt getransporteerd naar de andere. De data transport software moet zich bezig houden met de hierarchische structuur (zodat informatie over een bepaalde sales order wordt gegroepeerd) en verder weinig andere zaken. Het nadeel van het weglaten van informatie over een document is dat wanneer het document weer wordt opgevraagd uit de database het resultaat een ander document is. Het bevat de juiste data, maar daar is alles mee gezegd. In sommige gevallen is dit geen probleem, dit is afhankelijk van de behoefte Mapping van documenten op de database Software die data tussen XML documenten en een database transporteren zijn gebaseerd op mapping tussen het document en de database. Bijvoorbeeld het <SalesOrder> element naar de SalesOrders tabel en het <OrderDate> element op de kolom SalesOrders.OrderDate. Dergelijke mappings zijn te verdelen in vier catagorieen: model-driven template-driven 19

20 table-based object-relational Model-driven mapping Hierbij wordt XML data aan de hand van een voorgedefinieerd model gemapt op de database. Omdat het model vooraf gedefinieerd is, is dit systeem minder flexibel dan Template-diven mapping. Figuur 4-1: Model-driven mapping Vaak wordt gebruik gemaakt van XSLT, omdat XML documenten mogelijk niet aan het model voldoen. Hiermee wordt iets van de flexibiliteit van Template-driven mapping teruggevonden. 20

21 Template-driven mapping In plaats van voorgedefinieerde mapping worden product specifieke commando's in een template aangeleverd. Deze worden door de data transmissie software verwerkt. Bijvoorbeeld een SELECT statement wordt opgenomen tussen <SelectStm> tags. Bij het verwerken van het aangeboden XML document wordt het SELECT statement vervangen door het resultaat van de query. Het volgende voorbeeld is een template die een SELECT statement heeft opgenomen in een <SelectStm> element: <?xml version="1.0"?> <FlightInfo> <Introduction>The following fligths have available seats: </Introduction> <SelectStm>SELECT Airline, FltNumber, Depart, Arrive FROM Fligths</SelectStm> <Conclusion>We hope one of these meets your needs</conclusion> </FlightInfo> Wanneer bovenstaand document wordt verwerkt door de data-transport software, wordt het SELECT statement vervangen door de resultaten en levert bijvoorbeeld onderstaand document op: 21

22 <?xml version="1.0"?> <FlightInfo> <Introduction>The following fligths have available seats: </Introduction> <Flights> <Row> <Airline>ACME</Airline> <FltNumber>123</FltNumber> <Depart>Dec 12, :43</Depart> <Arrive>Dec 13, :21</Depart> </Flights> <Conclusion>We hope one of these meets your needs</conclusion> </FlightInfo> Template-driven mapping wordt bijna altijd toegepast om data van relationele databases uit te voeren in XML documenten. Table-based mapping Hierbij wordt een XML document als een tabel of set van tabellen gemodelleerd. Table-based mapping wordt meestal gebruikt om relationele data uit te wisselen. Het kan niet worden gebruikt voor XML documenten die niet aan het tabel-model voldoen. Het tabel-model ziet er uit als: <Database> <Table> <Row> <column1>... </column1> <column2>... </column2> </Row> <Row> <column1>... </column1> <column2>... </column2> </Row> </Table> </Database> 22

23 Object-relational mapping Hierbij wordt de data in een XML document als objecten gemodelleerd. In dit model worden element types met atributen, element inhoud weergegeven als classes. Element typen met puur PCDATA, attributen en PCDATA worden weergegeven als scalar properties. Het model wordt dan gemapt op een database waarbij classes worden gemapt op tabellen, scalar properties op kolommen en object-value properties op primary keys en/of foreign keys Opslaan van data in een native XML database Data in XML documenten kan ook worden opgeslagen in een native XML database. Voor die keuze zijn een aantal argumenten. Semi-gestructureerde data resulteert in een groot aantal kolommen met NULL waardes of tabellen in een relationele database Native XML databases zijn over het algemeen sneller met het verkrijgen van data dan relationele databases Native XML databases hebben XML specifieke mogelijkheden Als de data semi-gestructureerd is, d.w.z. een regelmatige structuur, maar genoeg afwijkingen zodat opslag in een relationele database een groot aantal kolommen met NULL waardes of veel tabellen oplevert. Ondanks dat semi-gestructureerde data opgeslagen kan worden in object-georienteerde en hierarchische databases is het ook mogelijk om die data op te slaan in een native XML database in de vorm van een XML document. De retrieval snelheid is de tijd die nodig is om data uit de database te halen. Afhankelijk van hoe een native XML database data fysiek opslaat, kan er een flinke snelheidswinst geboekt worden in vergelijking met een relationele database. De reden hiervoor is dat een native XML database fysiek gezien complete documenten opslaat of fysieke pointers tussen delen van documenten gebruikt. Dit heeft als resultaat dat documenten kunnen worden opgevraagd zonder joins of met fysieke joins, wat beide sneller is dan logische joins die door relationele databases gebruikt worden. 23