Inhoudsopgave Inleiding... 2

Transcriptie

1 R2 D 2 Va n X M L n a a r D a ta b a s e R o b e rt B o u m a S c rip tie In fo rm a tie k u n d e R ug D e c e m b e r

2 Vo o rw o o rd!" #$ % &% (' *) ),+.-0/ / -1 $ (2&345 6$ 7 82 /' 9 : ( / / ;-< ( =-> $?2@A): B *C/1DE+FG%/ /.2@$): # 74 % > $ 8 Ḧ (/' 2 % ( 7 =IJ 9 K )(' / 3LMḦ M% (' / / ( (IN %#% (& L *BOP( Q / P % K-0 RḦ 8 S/ / T-1 P (2$$) U' IN %V 7 Q0 =& L 8 ( / = IN/WḦ / (' 8 X QEBY* IJ > ' Q4 8 ZḦ / #Ḧ / 4L 82#/ 82 >.2& 34 8/ 8 <H* / [ 2& 7 8 7L +*H % 8 : (' -</ / VA+\ -(-< ( ' =' / / ( 7Q4 ' 8 <Ḧ / ' ] * ( // 8 2# 82<)E % $=2^/ -= =' L -< (? (2&345 6$ ( B 8 8 MḦ _)^`5% 7 6 8'ab OP=I L (/ / %/ -= 2^ (Q / L *c. d e e2b-( P =)4!24 fn-= /.V = 4 / &2 IN/WḦ % 8 :' =2@A): 8 A % K-1 W% 3= A TQ ;Ḧ (2$; ) 4 = #/ ghe 8/ L?IN/ /. / * 8'>IN/2:C/P) ) 5 =Ih 6 1M i>j 7Q / E& = -0 /.& 7-> Q ' kq : 8/ /%2@] 7 3& 2 l. "2@3 % ;Ḧ <Ḧ / ( (2&3; 6$ fr Ih 6 7j 2@] _Q4 7 / #H!2@3L ) ' 0-= /L "/ 82%IN 7 8 &.IG 6 8 ( L$ * #Ḧ /$) )E5 6 $=/ -> P <HE5 ( (2@$): B 8 ' %? B 8 7Q ]' */ ' 7: QQ4 / / ( & =& 2 ( 7:/ Ḧ G]/ / AmV/L% (IN ( :2#'/ / T $L (IJ/ MḦ. 4'1 (IN 8 (% 7Q4 8 H: ( 82< /( (2@P) * 8 npo;q R o b e rt B o u m a G ro n in g e n, i

3 Inhoudsopgave Inhoudsopgave Inleiding Waarom XML 2 RDB XML DTD Relationele Databases Het relationele datamodel Normaalvormen RDBMS Waarom XML 2 RDB Applicatie XML 2 RDB: de theorie De DTD versimpelen Conclusie Prototype boomstructuur schema's ontwerpen Conclusie Prototype relationele schema's ontwerpen Sleutels vinden en normalisatie Conversie XML-data naar RDB XML 2 RDB: een nieuw algoritme Algoritme Versimpelen van de DTD Ontwerpen van de prototype boomstructuur en relationele schema's Vinden van sleutels Positionering Ontwerp en beschrijving R2D Informatie Programma User interface XML 2 RDB: R2D Van DTD naar databasestructuur Algemeen De DTD versimpelen Prototype boomstructuur en relationele schema's ontwerpen Sleutels vinden en positionering Van XML naar database data De webinterface Testen en aandachtsgebieden Conclusies Samenvatting Beperkingen Verder onderzoek Literatuurlijst

4 1. Inleiding Tegenwoordig wordt er steeds meer gebruik gemaakt van XML. In deze markuptaal kan data opgeslagen worden die normaliter opgeslagen wordt in een database, maar ook data die minder geschikt zijn om in databases opgeslagen te worden. Hierbij valt te denken aan data die minder gestructureerd zijn door bijvoorbeeld het ontbreken van gegevens. Mede daarom is het tegenwoordig wellicht geen slecht idee om over te gaan op het opslaan van gegevens in het XML-formaat. Voor het zoeken in gegevens is het daarentegen gemakkelijker om gebruik te maken van databases. Omdat deze al lange(re) tijd bestaan, zijn de zoekmogelijkheden hierin ondertussen goed uitgekristalliseerd. Bij XMLdocumenten is dat nog niet helemaal het geval en vaak grijpt men dan toch weer terug op meer conventionele zoekmethoden. Daarnaast ondersteunen deze bestaande pakketten ook steeds vaker de mogelijkheid om data te exporteren naar XML-bestanden. Aan de andere kant ontstaan er ook steeds meer applicaties die de functionaliteit van bestaande relationele database management systemen (RDBMS) overnemen en deze rechtstreeks toepassen op XML-bestanden. Hierdoor hoeft niet meer een vertaalslag gemaakt te worden van XML naar relationele database (RDB) en andersom. Bij het lezen over deze onderwerpen, ontstaat bij mij een aantal vragen. Allereerst is er de vraag wat handiger is: bestanden in XML-formaat laten staan of omzetten in een RDB-systeem. En direct er achteraan: als je een XMLdocument wil omzetten naar een RDB-systeem, op welke manier kan dit dan het beste? Is het überhaupt mogelijk om een XML-document goed over te zetten naar een RDB-systeem? Op deze vragen wil ik proberen een antwoord te geven in deze scriptie. Hiervoor heb ik een onderzoeksvraag opgesteld die tweeledig is: Waarom zou je een XML-document omzetten naar een RDB-systeem en niet als XML-document bewaren èn hoe kan een XML-document omgezet worden in een RDB-systeem? 2

5 De reden waarom ik juist hiernaar wil kijken, heeft te maken met mijn interesse in dit gebied en de ervaring die ik de afgelopen jaren heb opgedaan met het werken met databases. Omdat er al veel bestaande applicaties zijn die werken met RDB is het interessant om te kijken of deze applicaties dusdanig aan te passen zijn dat ze ook kunnen werken met XML. Dit zou een betere oplossing zijn dan deze applicaties opnieuw te ontwerpen en te implementeren. Daarnaast is men gewend aan de huidige applicaties en het in gebruik nemen van nieuwe applicaties brengt een nieuw leertraject met zich mee. Het omzetten van XML naar een RDB kan echter problemen opleveren. Een RDB verwacht dat de data die erin opgeslagen wordt goed gestructureerd is. XML kan echter minder gestructureerd zijn. Voor het omzetten wil ik gebruik maken van de DTD (Document Type Description). Ik wil een algoritme ontwerpen dat deze DTD uitleest en een structuur oplevert. Met behulp van de gevonden structuur kan vervolgens de RDB-structuur opgezet worden. In deze RDB-structuur kan tenslotte de XML-data opgeslagen worden. Ik wil nagaan in hoeverre dit problemen oplevert en, nog interessanter, in hoeverre deze eventuele problemen opgelost kunnen worden. Dit is een erg ruim probleem. Om een aantal problemen dat ik tegen kan komen het hoofd te bieden stel ik dan ook grenzen aan de soort data die ik wil gebruiken. Allereerst wil ik mij vooral richten op data met archieffunctie. Dat wil zeggen data die niet vaak gewijzigd hoeven te worden maar enkel geraadpleegd of, waarvan in ieder geval de structuur niet veelvuldig aangepast hoeft te worden. De reden hiervoor is dat het ontwerpen van een goede onderhoudsmodule al een klus op zich is en dit wil ik dan ook niet opnemen in deze scriptie. Daarnaast wil ik me vooral bezighouden met datagerichte XML-documenten en niet met documentgerichte XML-documenten. Datagericht wil zeggen dat de data goed gestructureerd zijn en weinig gemengd voorkomt (geen regels in de DTD als (element #PCDATA)) en waarin volgorde minder van belang is. Voorbeelden hiervan zijn bijvoorbeeld beurskoersen en adresboeken. In zekere zin dus data die al een zeker mate van RDB-eigenschappen in zich hebben. Documentgerichte XML heeft als kenmerken dat de structuur minder strak is, dat er wel veel gemengde data in voorkomen en waarin volgorde vaak wel van duidelijk belang is. Hierbij valt bijvoorbeeld te denken aan artikelen, toneelstukken of boeken in 3

6 XML-formaat. Ik richt mij dus vooral op de structuur van de data en minder op de inhoud. Om deze vragen te beantwoorden, is het nuttig om te werken met een praktijkvoorbeeld. Hiertoe wil ik een applicatie bouwen. Deze applicatie zal gebruikt kunnen worden om XML-documenten om te zetten naar RDB. Daarnaast zal hierin ook gepoogd worden om in zekere mate een onderhoudsmodule op te nemen, voor het onderhoud van de data. Deze module zal een zogenaamde webapplicatie worden en zal gebouwd worden in PHP en MySQL. De applicatie zelf wil ik in Perl ontwerpen. 4

7 2. Waarom XML 2 RDB In dit hoofdstuk wil ik antwoord geven op het eerste, en kleinste deel van mijn onderzoeksvraag, namelijk waarom zou je een XML-document omzetten naar een RDB-systeem en niet als XML-document bewaren. Om dit te kunnen uitleggen, is er begrip nodig van XML en relationele database (RDB)-systemen. Eerst zullen deze twee zaken dan ook worden uitgelegd en in het derde gedeelte van dit hoofdstuk wordt nader ingegaan op de onderzoeksvraag. 2.1 XML XML is ontworpen door het W3C 1 en is bedoeld voor de elektronische uitwisseling van machineleesbare data, in tegenstelling tot HTML dat bedoeld is om documenten voor mensen leesbaar te maken op het internet. XML is een subset van SGML en is op een drietal punten krachtiger dan HTML (ook een subset van SGML)[SUC98]: 1. De gebruiker kan zelf nieuwe tags definiëren. 2. Documentstructuren kunnen genest worden tot ieder gewenst niveau. 3. Elk XML-document kan een verwijzing naar een Document Type Description (DTD) bevatten. In deze DTD staat de grammatica voor dat document beschreven. Deze kan dan gebruikt worden bij validatie van de structuur van het XML-document. In het algemeen bestaat XML uit elementen die begrensd worden door zogenaamde tags (open- en sluittags) die genest kunnen worden. Hieronder staat een voorbeeld van XML data: <doc> <titel id="o1" reference="o2">semistructured data and XML</titel> <auteur> <voornaam>dan</voornaam> <achternaam>suciu</achternaam> </auteur> </doc> Hierbij zijn de tags de stukjes tussen de 'vishaken' (< en >), waarbij de sluittags voorafgegaan worden door een slash (/). Een voorbeeld van een opentag is 1 5

8 <auteur> en van een sluittag </auteur>. Een element is het geheel van matchende tags en de informatie die ertussen staat, bijvoorbeeld: <firstname>dan</firstname>. XML heeft veel weg van semistructured data 2. Zo kan de structuur van een XMLdocument onregelmatig zijn, zelfs onbekend en van tijd tot tijd veranderen zonder dat daar melding van gedaan wordt. Daar staat tegenover dat zonder veel moeite allerlei soorten data omgezet kunnen worden naar een XML-document. Dit heeft als voordeel dat het aantrekkelijk wordt om gegevens te publiceren in een XML-document. De gegevens zijn namelijk vervolgens eenvoudig te verspreiden naar andere XML-applicaties op het internet. XML is bedoeld om informatie te structureren. Het zegt niets over de presentatie van data. Hiervoor zijn stylesheet-talen ontwikkeld. Voor de presentatie op internet is er de stylesheet-taal CSS (Cascading Style Sheets). Deze taal geeft aan hoe elementen getoond moeten worden. Voor de presentatie in andere omgevingen dan het internet (zoals MS Word- of PDF-documenten) kan gebruik gemaakt worden van XSLT. In deze scriptie wordt verder niet ingegaan op deze stylesheet-talen. Wat wel belangrijk is, is de strikte scheiding in XML tussen structuur en presentatie DTD XML heeft zijn eigen schema, namelijk de Document Type Description (DTD). DTD s beschrijven welke tags gebruikt mogen worden en hoe ze genest moeten worden. Daarnaast leggen DTD's ook de volgorde vast waarin elementen moeten staan en hoeveel er mogen voorkomen. Een DTD kan gebruikt worden voor meerdere XML-documenten. In een DTD zijn een aantal onderdelen te onderscheiden. <!DOCTYPE naam []> - met deze declaratie wordt aangegeven wat het zogenaamde topelement is in het XML-document. Dit topelement mag slechts één keer voorkomen in een XML-document, vergelijkbaar met de <html> tag in een HTML-document. Om een DTD in een XML-document aan te roepen zijn er twee mogelijkheden. Allereerst kan de DTD in het XML-document zelf gedefinieerd worden. In dat geval staan tussen de vierkante haken ([]) de 2 Voor uitleg over semistructured data verwijs ik naar mijn literatuurstudie, te vinden op 6

9 declaraties van de elementen. De tweede manier is dat de declaraties in een los bestand worden opgeslagen. In dat geval wordt in de DOCTYPE aangegeven waar dat bestand zich bevindt (<!DOCTYPE naam SYSTEM bestand.dtd >). <!ELEMENT elnaam ()> - met deze declaratie worden de verschillende elementen gedefinieerd die voor mogen komen in een XML-document. Hier staat elnaam voor de naam van het element. In een XML-document wordt dit dus weergegeven door <elnaam>waarde</elnaam>. Tussen de haakjes komen de elementen die genest kunnen voorkomen onder dit element. Een voorbeeld is <!element persoon (naam,leeftijd, *)>. Hier staat dat onder het element persoon een element naam, leeftijd en nul of meer elementen mogen voorkomen (in die volgorde). De ster operator (*) betekent hier nul of meer keer. Er zijn een aantal van deze operatoren. Naast el* zijn er ook nog el+ (één of meer keer voorkomen), el? (nul of één keer voorkomen), el el2 (alternatieven: òf el, òf el2) en el, el2 (achterelkaar voorkomen: eerst el, dan el2). Het is ook mogelijk dat tussen een bepaald element alleen een string komt te staan. In dit geval komt er #PCDATA te staan op de plaats van de ronde haakjes (<!ELEMENT naam #PCDATA>). Natuurlijk is een combinatie van elementen en #PCDATA ook mogelijk. <!ATTLIST elnaam attnaam type #status> - op deze wijze worden attributen gedeclareerd. elnaam is de naam van het element waar het attribuut aan toegewezen wordt. attnaam is vervolgens de naam van het attribuut. Het type informatie dat hierin neergezet mag worden, wordt gedefinieerd door type. De belangrijkste mogelijkheden zijn de volgende: o CDATA zogenaamde character data, oftewel een willekeurige string. o Lijst een lijst met mogelijke waarden, op de volgende manier weergegeven: (fruit groente aardappelen). o ENTITY hier mag een entity worden ingevuld die elders in de DTD gedefinieerd is. o ID dit geeft de mogelijkheid om een element een ID mee te geven. Deze ID moet uniek zijn voor het hele XML-document. o IDREF met dit type kan een verwijzing naar een ID aangegeven worden. Er wordt verwezen naar een element elders in het XMLdocument dat een attribuut van het type ID heeft. Binnen een ATTLIST kunnen meerdere attributen per element gedefinieerd worden. Voor elk attribuut is ook aan te geven of deze verplicht zijn of niet. Daarvoor zijn voor #status een aantal waarden in te vullen, namelijk 7

10 #REQUIRED als het attribuut verplicht een waarde moet hebben, #IMPLIED als het attribuut niet persé een waarde hoeft te hebben en #FIXED als het attribuut een vaste waarde heeft (dit wordt dan als laatste argument meegegeven aan de declaratie). Een voorbeeld: <!ATTLIST person sekse (man vrouw) #REQUIRED opmerkingen CDATA #IMPLIED id ID #REQUIRED familie IDREF #IMPLIED type CDATA #FIXED mens > <!ENTITY %naam vervanging > - deze declaraties kunnen gebruikt worden om bepaalde (groepen) karakters te vervangen door anderen. Er zijn vier soorten (waarvan de eerste twee de belangrijkste zijn): o general entities deze worden voornamelijk gebruikt om bepaalde karakters te laten zien die gereserveerd zijn, zoals < en > of vreemde karakters. Deze worden op de volgende manier gedefinieerd: <!ENTITY copyright &#xa9 >. In een XML-document wordt dit aangeroepen met &copyright; en dit tovert het copyright teken ( ) op het scherm. o parameter entities deze entities kunnen alleen gebruikt worden in de DTD zelf en kunnen gebruikt worden om bepaalde veel gebruikte strings te vervangen voor korte varianten. Een voorbeeld is <!ENTITY %txt (#PCDATA) >. Later kan bij een element declaratie dan deze korte variant gebruikt worden: <!ELEMENT naam %txt;>. o externe entities deze kunnen gebruikt worden om te verwijzen naar externe documenten: <!ENTITY adressen SYSTEM adressen.xml >. In een XML-document kan dit bestand in één keer geïmporteerd worden door te verwijzen naar &adressen;. o unparsed entities hiermee kan verwezen worden naar bepaalde data die geen XML-inhoud hebben. Voorbeelden zijn plaatjes of video s. De definitie werkt op dezelfde manier als bij externe entities. DTD s hebben ook een aantal tekortkomingen. Deze worden genoemd in [ABI00]: Alleen het datatype PCDATA kan gebruikt worden. Indien het mogelijk moet zijn om bijvoorbeeld een leeftijd op te slaan, dan moet er teruggegrepen worden op een definitie van een range. Het type van een tag is globaal. Indien er onderscheid gemaakt moet worden tussen de lengte van een film en de lengte van een persoon (met behulp van een tag <lengte>), dan zijn er twee mogelijkheden: er moeten 8

11 twee tags gedefinieerd worden (een tag <persoonslengte> en een tag <filmlengte>), of er moet gewerkt worden met namespaces. Er worden twee namespaces aangemaakt (een persoon namespace en een film namespace) en vervolgens twee tags persoon:lengte en film:lengte. Voor elke namespace moet er dan wel een aparte DTD komen. Het type van IDREFS is niet te beperken. In de praktijk kan het handig zijn om bepaalde tags alleen met bepaalde identifiers te verbinden, maar dit is helaas niet mogelijk. In een DTD kunnen een aantal operatoren voorkomen aan te geven hoe vaak en in welke volgorde elementen voor kunnen komen. Hieronder staan ze opgesomd en uitgelegd:? operator de operator betekent dat het element 0 of 1 keer voor mag komen * operator het element mag 0 of meer keer voorkomen + operator deze operator betekent dat het element minimaal 1 keer moet voorkomen., operator met deze operator wordt de volgorde bepaald. Elk element moet precies in deze volgorde voorkomen operator ook deze operator regelt de volgorde. Hierbij gaat het om keuze. Het ene of het andere element mag voorkomen Nu XML uitgebreid besproken is, is het tijd om een blik te werpen op relationele databases. 2.2 Relationele Databases Het relationele datamodel Het relationele model geeft aan hoe een relationele database in elkaar steekt en wat de eisen en grenzen zijn van zo n database. Het model stamt uit 1970 en is ontwikkeld door E.F. Codd en later verfijnd door C.J. Date in [DAT90]. Dit model is gebaseerd op drie wiskundige terreinen, namelijk de verzamelingenleer, de relationele calculus en de algebra (uit [GRO01]). Het model bestaat uit drie delen: De tabellen Een querytaal 9

12 Een serie integriteitregels De tabellen bestaan uit rijen en kolommen. Een kolom heeft een bepaalde reeks met toegestane waarden. Een waarde moet bijvoorbeeld een string zijn of een integer. Een veld in een kolom bestaat uit precies één waarde. Een rij in een tabel wordt samengesteld uit één of meer kolommen en wordt uniek geïdentificeerd door een primary key. Dit betekent dus dat er geen rijen in een tabel mogen voorkomen die gelijk zijn. Kandidaat-sleutels zijn één of meer kolommen die een rij eventueel als uniek zouden kunnen identificeren. Als er meerdere kandidaat-sleutels zijn, kan er gekozen worden welke gebruikt wordt voor de primary key. Als een kolom of een serie van kolommen overeenkomt met de primary key van een andere tabel, wordt dit een foreign key genoemd. Een combinatie van nul of meer rijen en één of meer kolommen worden ook wel entiteittypen genoemd. Voor een tabel geld de voorwaarde dat alle rijen bestaan uit precies dezelfde set kolommen. Een bijkomend voordeel is dat de structuur van de tabellen in een database gerepresenteerd kunnen worden in tabelvorm. Zo kunnen de tabellen gemakkelijk aangepast worden met dezelfde querytaal, die ook gebruikt wordt om de data te manipuleren. De querytaal die bij relationele databases gebruikt wordt, wordt SQL genoemd. Met deze taal is het mogelijk tabellen aan te maken, hier informatie aan toe te voegen, te verwijderen en op te vragen. Dit alles is gebaseerd op relationele algebra. Veel voorkomende bewerkingen zijn SELECT, DELETE en INSERT. Meestal worden deze bewerkingen uitgevoerd via een RDBMS, een Relationeel DataBase Management Systeem, waarover later meer. Het laatste onderdeel bestaat uit een tweetal integriteitregels, volgens [GRO01]: 1. De entiteits integriteitregel, deze stelt dat geen enkel onderdeel van de primary key lege waarden (NULL waarden) mag bevatten. 2. De referentiële integriteitregel, deze regel stelt dat er voor elke foreign key in een tabel een overeenkomende primary key moet voorkomen in een andere tabel in de database. Deze twee regels zorgen ervoor dat er in de tabellen geen inconsistentie ontstaat. Dat wil zeggen dat er geen interne tegenstrijdigheden zijn in de database en dat 10

13 er dus geen verwijzingen zijn naar niet-bestaande waarden. Dit zou problemen oproepen bij het uitvoeren van queries. Een ander probleem bij de opslag en bewerking van gegevens in een database is redundantie. Dit betekent dat gegevens dubbel worden opgeslagen. Een voorbeeld is een tabel auteurs die een veld uitgever hebben. Deze uitgever kan beter opgeslagen worden in een aparte tabel om te voorkomen dat bij bewerken van dit veld meerdere records aangepast moeten worden waardoor de kans op fouten groter wordt Normaalvormen Om redundantie zo veel mogelijk te voorkomen is het belangrijk om er voor te zorgen dat de tabellen in de derde normaal vorm (3NV) staan. Het feit dat er een 3NV is, betekent ook dat er een eerste en tweede normaal vorm zijn (respectievelijk 1NV en 2NV). Deze normaalvormen zijn ontwikkeld door Codd en zijn bedoeld om redundantie zoveel mogelijk tegen te gaan. Ik zal hier in het kort deze normaalvormen bespreken. De informatie over de verschillende normaalvormen komt uit [BLA88] en [DAT90]. Voor de normaalvormen gelden de volgende definities (uit [BLA88]): Een relatie R is in de eerste normaalvorm (1NV) dan en slechts dan als alle onderliggende domeinen uitsluitend atomaire waarden bevatten - dit wil zeggen dat de afzonderlijke velden van een tabel (hier domeinen genoemd) niet mogen bestaan uit samengestelde delen. Het moeten simpele waarden zijn (meestal string of integer). Een relatie R is in de tweede normaalvorm (2NV) dan en slechts dan als de relatie in 1NV is en elk niet-sleutel attribuut volledig van de primaire sleutel afhangt met een niet-sleutel attribuut worden de velden bedoeld die niet in aanmerking komen voor de primaire sleutel. Een relatie is in de derde normaalvorm (3NV) dan en slechts dan als de relatie in 2NV is en ieder niet-sleutel attribuut niet transitief afhankelijk is van de primaire sleutel net als bij de andere twee stappen zorgt deze normaal vorm voor het terugdringen van redundantie van data en waarmee voorkomen wordt dat er inconsistentie ontstaat bij het toevoegen, verwijderen en wijzigen van data in de database. 11

14 Er bestaan ook nog een Boyce/Codd normaal vorm (BCNV) en een vierde en vijfde normaalvorm (4NV en 5NV), maar deze zijn voor de hier gebruikte structuren niet nodig en zullen dan ook niet verder besproken worden. Meer over deze laatste normaalvormen is terug te vinden in [DAT90] RDBMS Een RDBMS, oftewel een Relationeel DataBase Management Systeem, is een applicatie waarmee databases kunnen worden beheerd. Met zo n systeem kan zorg gedragen worden voor opslag, beheer en het bevragen van data. Het is te beschouwen als een tussenlaag tussen de gebruiker en de fysieke opslag van de data. Een RDBMS zorgt ervoor, of maakt het in ieder geval makkelijker, dat de data die in een database opgeslagen moeten worden, voldoen aan de eerder gestelde eisen. In het kort zijn er in ieder geval een achttal eisen waar een RDBMS aan moet voldoen. Deze zijn terug te vinden in [GRO01]: 1. Gebruikers moeten in staat zijn data op te slaan, op te roepen en aan te passen. 2. De gebruiker moet de mogelijkheid geboden worden om een catalogus in te zien waarin data-eenheden beschreven worden. Hierbij is een catalogus een verzameling van gerelateerde bestanden. 3. Het moet mogelijk zijn dat meerdere gebruikers tegelijk aan een database werken zonder dat hierbij afbreuk wordt gedaan aan de integriteit van de database. 4. Mocht een database beschadigd raken, dan moet het RDBMS de mogelijkheid tot herstel bieden. 5. Het moet mogelijk zijn de toegang van gebruikers tot databases te reguleren. 6. De eerder genoemde integriteitregels moeten gewaarborgd zijn. 7. Een RDBMS moet dataonafhankelijk zijn. Als de structuur van een database of van tabellen in die database verandert, hoeft de databewerking niet veranderd te worden. 8. Er moeten een aantal hulpprogramma s zijn. Hierbij valt te denken aan rapportgeneratoren en query-by-example programma s (programma s die het bevragen van de informatie versimpelen). Bij het bouwen van mijn applicatie gebruik ik MySQL. Dit databasepakket voldoet niet aan alle genoemde eisen, vooral op punten 4 en 8. Dit is echter niet erg omdat ik in mijn applicatie die functionaliteit niet nodig heb. Bij het bouwen van 12

15 een volledige applicatie voor gebruikers is het aan te raden om wel aan alle bovenstaande eisen te voldoen. Nu zowel XML als RDB systemen beschreven zijn, is het tijd om te gaan kijken waarom het handig kan zijn XML om te zetten naar RDB systemen. 2.3 Waarom XML 2 RDB De huidige generatie internet browsers en web search engines kunnen prima omgaan met zogenaamde document operations. Hieronder wordt onder andere het zoeken in tekst en het presenteren van de tekst in de juiste opmaak verstaan. Om de mogelijkheden in XML echter volledig te benutten, zijn naast deze document operations, ook database operations nodig. Onder deze laatste operaties vallen data extractie (het verkrijgen van data uit een document), data integratie (het samenvoegen van data in een document), data opslag en data transformatie (het omvormen van data in een nieuwe structuur) zoals vermeld in [SUC98]. Relationele databases zijn goed in het uitvoeren deze database operations, in tegenstelling tot de huidige generatie internet browsers en search engines. De querytaal SQL is er helemaal op ingesteld dit soort bewerkingen simpel en efficiënt uit te voeren. De lange ontwikkeling van de relationele databases heeft het volgende gebracht ([GRO01]): Opslagtechnieken en query-talen die efficiënt toegang geven tot grote hoeveelheden zeer gestructureerde data. Datamodellen en methoden voor het structureren van data. Methoden voor het onderhouden van de consistentie en integriteit van data. Dit zou dus een hele goede reden zijn om XML om te zetten naar een relationele database. Het omzetten zou, als het eenrichtingsverkeer zou betreffen (alleen van XML naar RDB), zelfs betrekkelijk eenvoudig zijn. Zo eenvoudig ligt het echter niet. Het grote nadeel van relationele databases is dat deze vaak niet al te goed zijn in de document operations. Voor dit gedeelte zouden XML en vooral de viewers van XML (de web browsers e.d) erg geschikt zijn, maar deze browsers kunnen niet overweg met data zoals die opgeslagen wordt door database systemen. Er zijn wel querytalen voor XML, maar deze 13

16 werken minder goed dan SQL 3. Vooral op het gebied van structuur (gebruik van de DTD) en het toevoegen van verschillende datatypes zijn deze talen niet goed. Hierdoor is het zeker voor de meer ingewikkelde data interessant om verwerkt te worden via een database. Dit geld ook voor data die op zich niet heel ingewikkeld zijn, maar wel vergaande bewerking moeten kunnen ondergaan. Daarnaast is het XML-formaat veel makkelijker in het uitwisselen van data tussen systemen. XML is platform- en programmaonafhankelijk in tegenstelling tot de bestandsformaten van de meeste RDB systemen. Elk bedrijf dat een dergelijk RDB systeem ontwerpt, gebruikt vaak een eigen bestandsformaat en de verschillende systemen kunnen vaak niet met elkaars bestandsformaten overweg. De beste oplossing zou zijn om een RDB systeem te hebben dat als bestandsformaat de XML indeling gebruikt. Het goede nieuws is dat deze er al zijn. Het slechte nieuws is dat deze pakketten vaak erg duur zijn en van de gebruikers vaak een herscholingscursus vergen om met weer een nieuw pakket te leren werken. Voor kleinere bedrijven en instellingen is het vaak kostbaar om een dergelijke omschakeling te maken. Daarnaast zijn het vaak deze kleinere bedrijven en instellingen die net geïnvesteerd hebben in een prachtig, eventueel custom-made, RDB systeem omdat ze gehoord hadden dat een dergelijk systeem de toekomst had! Voor deze bedrijven en instellingen zou het een uitkomst kunnen zijn om aan hun bestaande systemen een extra component te koppelen die XML-bestanden omzet naar RDB-data. Dit is voordeliger dan het aanschaffen en leren omgaan met een nieuw software pakket. Voorwaarde is wel dat de conversie twee kanten op werkt. Data moeten ook teruggezet kunnen worden naar XML voor presentatie doeleinden. Daarnaast ben ik persoonlijk erg nieuwsgierig of dit in de praktijk te doen is of dat het meer problemen dan oplossingen oplevert. Om deze redenen lijkt het mij dus interessant een applicatie te bouwen die het voor elkaar krijgt XML-documenten om te zetten naar een RDB systeem. Maar zelfs als de redenen buiten beschouwing laten, is het nog steeds een interessant theoretisch probleem dat tot een oplossing gebracht moet kunnen worden op een zo n correct mogelijke manier. Een dergelijk RDB systeem zou in staat moeten zijn de voordelen van XML en de voordelen van een RDB systeem samen te voegen en op die manier een aantal van hun nadelen teniet te doen. 3 Meer informatie over deze querytalen is de vinden in mijn literatuurstudie op 14

17 2.4 Applicatie Met mijn applicatie wil ik mij vooral richten op de conversie kant van het verhaal. Het uitlezen van een database in een XML-document laat ik over aan één ieder die zich daartoe geroepen voelt, maar hiernaar is al eens gekeken door A. de Groot in [GRO01]. Bij het omzetten mag echter niet vergeten worden dat de data ook weer terug geconverteerd zouden moeten kunnen worden. Daarom is het belangrijk dat een applicatie aan een aantal eisen voldoet. Op de eerste plaats moet het RDB systeem een goede weergave geven van het XML-document. Aan de oorspronkelijke structuur en inhoud mag geen afbreuk gedaan worden. Daarnaast moet de volgorde in het XML-document gewaarborgd blijven bij conversie. In RDB systemen is volgorde niet van belang, maar bij XML wel. Bij export van de database gegevens naar XML-documenten moet dit dus op de juiste manier terug geplaatst worden. Om er zeker van te zijn dat deze export goed slaagt, is het van belang de DTD ook op te slaan in de database. Deze kan dan geraadpleegd worden bij het omzetten van RDB naar XML. Onder deze voorwaarden wil ik proberen een dergelijke applicatie te bouwen. Het hart van zo n applicatie wordt gevormd door het algoritme dat de structuur van de database haalt uit de, bij het XML-document behorende, DTD. Hiervoor zijn in het verleden al een aantal algoritmes geschreven. In het volgende hoofdstuk bekijk ik deze algoritmes nader en in hoofdstuk 4 geef ik mijn eigen versie die voldoet aan de door mij gestelde eisen. 15

18 3. XML 2 RDB: de theorie Bij het omzetten van XML-data naar een relationele database (RDB) kan een tweetal stappen onderscheiden worden. De eerste stap betreft het analyseren van de structuur van de XML-data. Vaak kan hier gebruik gemaakt worden van de DTD. Dit verdient zelfs de voorkeur. Als de XML structuur eenmaal bekend is, kan de RDB opgebouwd worden. Deze stap is onder te verdelen in de onderstaande delen die ook terug te vinden zijn in [MEN01]: 1. De DTD versimpelen - Een DTD kan behoorlijk ingewikkeld in elkaar steken. Om het geheel begrijpelijker en overzichtelijker te maken, is het wenselijk de DTD te versimpelen. Natuurlijk moet dit dusdanig gebeuren dat er zo min mogelijk afbreuk gedaan wordt aan de oorspronkelijke bedoelingen van de DTD. 2. Prototype boomstructuur schema's ontwerpen - Om een overzicht te krijgen van de samenhang tussen de verschillende elementen en attributen in de DTD, is het handig deze relaties 'uit te tekenen' in een boomstructuur. Vanuit een dergelijke boomstructuur is het maken van een relationeel schema makkelijker. 3. Prototype relationele schema's ontwerpen - Aan de hand van ontstane boomstructu(u)r(en) is het mogelijk een voorlopig relationeel schema te fabriceren. Dit schema dient als basis voor de te ontwerpen tabellen in een RDB. 4. Sleutels vinden en normalisatie - Als het prototype van het relationele schema af is, wordt het tijd te bepalen wat de primaire sleutels worden van de tabellen in de database. Als deze sleutels bekend zijn, kan het eventueel ook nodig zijn de ontstane schema's voor tabellen te normaliseren, bijvoorbeeld om redundantie in de data te voorkomen. De tweede stap betreft het opdelen van de XML-data in het document in de nieuw aangemaakte database. Dit is verhoudingsgewijs de minst ingewikkelde stap. In de hier besproken algoritmes wordt hier dan ook weinig aandacht aan besteed. In dit hoofdstuk wordt gekeken naar vier verschillende algoritmes en hoe deze omgaan met de genoemde punten: het Global Schema Extraction (GSE) algoritme, het DTD-splitting Schema Extraction (DSE) algoritme, het Inlining Schema (IS) algoritme en het Non-DTD (ND) algoritme. De eerste twee algoritmes worden besproken in [MEN01]. De auteurs proberen in dit artikel een 16

19 geautomatiseerde manier te vinden om XML in een relationele database op te slaan. De reden om dit te willen, ligt in het feit dat technieken voor relationele databases al goed ontwikkeld zijn en het zou mooi zijn als deze technieken ook toegepast zouden kunnen worden op XML-data. Het derde algoritme wordt besproken in [SHA99]. In dit artikel wordt vooral gekeken in hoeverre queries kunnen worden toegepast op XML-data. Ook hier ligt de reden in het feit dat er voor relationele databases al zeer veel technieken ontwikkeld zijn en het zou nuttig zijn als deze technieken ook werken in het verband van XML-data. Het laatste algoritme wordt besproken in [FLO99]. De auteurs wilden er achter komen in hoeverre simpele en voor de hand liggende oplossingen voldeden, voordat er nagedacht ging worden over meer ontwikkelde methoden. 3.1 De DTD versimpelen Er zijn een aantal manieren om de DTD te versimpelen. Toch is er ook één methode die alle algoritmes toepassen. Dit betreft de entity declarations die gebruikt worden voor verwijzing binnen de DTD. Deze worden verwijderd en vervolgens worden alle declaraties die naar een entity verwijzen vervangen door de DTD componenten die deze entities vertegenwoordigen. Een voorbeeld is: <!ENTITY %txt "(#PCDATA)"> <!ELEMENT boektitel %txt> Dit wordt: <!ELEMENT boektitel (#PCDATA)> Ook worden in de attribute type declaration de waarden voor de CDATA (#IMPLIED, #FIXED, enz.) weggelaten. Hoewel in een database ook restricties worden aangegeven, wordt dit wel duidelijk bij het uitlezen van het XML bestand. Zeker wanneer het systeem voornamelijk gebruikt wordt voor archief functies en er dus weinig tot niets zal veranderen in de data. Als een systeem ook bedoeld is voor het onderhoud van de data zou dit meer problemen opleveren. In een dergelijk geval zou het eventueel wenselijk zijn deze informatie wel te bewaren. Zoals echter aangegeven in de inleiding is het systeem dat ik wil opzetten vooral bedoeld voor archivering doeleinden en daarom is het hier gerechtvaardigd de type declarations weg te laten. De volgende stap is het elimineren van operatoren in de DTD. Hierdoor wordt de DTD geflattened en is de structuur beter te vangen in een database structuur. De 17

20 verschillende algoritmes gaan hier verschillend mee om. Het GSE algoritme is het meest radicaal. Bij de voorgestelde transformaties wordt de DTD het meeste 'plat geslagen'. Het DSE algoritme laat wat meer heel van de structuur en het IS algoritme houdt de meeste operatoren intact en versimpelt voornamelijk de geneste structuren in de DTD. Het ND algoritme tenslotte kent deze transformaties niet. Dit komt omdat dit algoritme niet werkt op een DTD maar rechtstreeks op de XML-data zelf. Hieronder staat een overzicht van de transformaties die de verschillende algoritmes voorstellen. f* --> f f+ --> f f? --> f..., f,..., f,... --> f f f' --> f, f' (f, f') --> f, f' Fig.1: Transformaties bij het GSE algoritme. g* --> g* g+ --> g* g? --> g g g' --> g, g' (g, g') --> g, g' (g,g')* --> g*, g'*..., g,..., g*,... --> g*..., g,..., g,... --> g Fig.2: Transformaties bij het DSE algoritme. h+ --> h* h** --> h* h*? --> h* h?* --> h* h?? --> h? (h, h')* --> h*, h'* (h, h')? --> h?, h'? (h h') --> h?, h'?..., h*,..., h*,... --> h*,......, h*,..., h?,... --> h*,......, h?,..., h*,... --> h*,......, h?,..., h?,... --> h*,......, h,..., h,... --> h*,... Fig.3: Transformaties bij het IS algoritme. Deze transformaties zijn onder te verdelen in drie groepen: simplification transformations - deze transformaties zorgen ervoor dat het aantal operatoren per element bij de elementen terug gebracht worden. Hierdoor wordt het geheel een stuk overzichtelijker en dus simpeler. De transformaties die linksboven staan in de drie figuren, zijn hiervan een voorbeeld. flattening transformations - deze transformaties zorgen ervoor dat geneste elementen omgezet worden naar een platte variant. De transformaties die hierop betrekking hebben, zijn de transformaties die rechts boven staan. grouping transformations - deze transformaties zorgen ervoor dat groepen subelementen met dezelfde naam in een element vervangen worden door een subelement met die naam en, eventueel, een * operator. Deze operatoren zijn in de fig. 1 tot en met 3 linksonder terug te vinden. 18

21 Ik zal nu de simplification transformaties bespreken. Bij het GSE algoritme worden alle operatoren simpelweg verwijderd. Van alle elementen wordt dus uitgegaan dat ze precies 1 keer voorkomen. Veel informatie gaat op deze manier verloren en het is lastig op deze manier nog 1:M relaties te onderkennen. Het DSE algoritme verwijdert de? operator en vervangt de + operator voor de * operator. Het IS algoritme tenslotte bewaard meer informatie omdat de? operator niet verwijderd wordt. De volgende set transformaties zijn de flattening transformaties. Bij alledrie de algoritmes worden de geneste gedeelten achterelkaar gezet. De operator wordt vervangen door een, operator. Hiermee verdwijnt wel de informatie over volgorde binnen de elementen, maar, in tegenstelling tot de situatie binnen een DTD of XML-document, maakt dit niet uit in de database. In een database kan volgorde niet zonder hulpmiddelen worden weergegeven en hieraan wordt dan ook bij het uitlezen van de data aandacht besteed. De DSE en IS algoritmes hebben als extra regel dat eventuele operatoren om de geneste elementen toegekend worden aan zijn individuele elementen, iets dat in principe hetzelfde betekent, maar iets anders opgeschreven is. Omdat het IS algoritme de? operator bewaard, wordt een genest statement met de operator opgesplitst in zijn delen met een? operator, gescheiden door een, operator. De laatste groep transformaties zijn de grouping transformaties. De transformaties zorgen ervoor dat dezelfde elementen die meerdere keren voorkomen in een statement bij elkaar geplaatst worden. Het GSE algoritme heeft ook in deze stap geen operatoren en het DSE algoritme zorgt ervoor dat elementen zonder operatoren ook vervangen worden door één keer dat element zonder een operator. Dit is niet correct. Het feit dat een element meerdere keren voorkomt, zegt al dat er een + operator geplaatst zou moeten worden, of op z'n minst een * operator. Het IS algoritme vervangt elementen wel door één keer dat element met een * operator, iets wat in het licht van de net aangevoerde reden ook als meer juist beschouwd kan worden. Welke set transformaties moet nu gebruikt worden voor het versimpelen van de DTD. De transformaties van het GSE algoritme voldoen niet. Alle operatoren worden bij dit algoritme weggegooid en zo is er teveel informatie verlies. Het IS algoritme bewaard weer teveel informatie door ook gebruik te maken van de? operator. Dus ook dit algoritme voldoet niet Conclusie 19

22 Met dit commentaar in het achterhoofd stel ik de volgende transformaties voor als goed alternatief voor de besproken algoritmes. Voor de relaties in een database hoeft alleen het onderscheid gemaakt worden tussen maximaal 1 keer voorkomen of meer dan 1 keer voorkomen: simplification flattening grouping e --> e e? --> e e* --> e* e+ --> e* e** --> e* e f --> e,f (e,f) --> e,f (e,f)* --> e*,f* Fig. 4: transformaties voor versimpeling van de DTD...,e,...,e,... --> e*...,e,...,e*,... --> e*...,e*,...,e*,... --> e* De meeste transformaties zijn overgenomen uit het DSE algoritme op tweetal uitzonderingen na. Als een operator dubbel voorkomt, wordt deze vervangen door een enkel voorkomen. En de grouping transformaties uit het IS algoritme zijn gebruikt, omdat die van het DSE algoritme niet klopten. Een versimpelde DTD zou er dan vervolgens als volgt uit kunnen zien (uit [MEN01]): <!ELEMENT book (booktitle, price, author, authority*)> <!ELEMENT authority (authname, country)> <!ELEMENT authname #PCDATA> <!ELEMENT country #PCDATA> <!ELEMENT booktitle #PCDATA> <!ELEMENT price #PCDATA> <!ELEMENT monograph (title, author, editor)> <!ELEMENT editor (monograph*)> <!ATTLIST editor name CDATA> <!ELEMENT author (name, address)> <!ATTLIST author id ID> <!ELEMENT name (firstname, lastname)> <!ELEMENT firstname #PCDATA> <!ELEMENT lastname #PCDATA> <!ELEMENT address #PCDATA> Fig. 5: een versimpelde DTD met behulp van de DSE transformaties 3.2 Prototype boomstructuur schema's ontwerpen De volgende stap is het maken van het prototype boomstructuur schema. Deze bomen representeren de structuur van de versimpelde DTD. Hierbij zijn de nodes in de boom de elementen en attributen uit de DTD. Deze schema's worden 20

23 gemaakt aan de hand van een aantal regels, dat genoemd worden in [MEN01]. Voor de GSE en DSE algoritmen komen deze regels voor een deel overeen: 1. Alleen een element kan een root worden - Attributen bestaan alleen bij gratie van het element waar ze toe behoren. Om deze reden kan alleen een element en nooit een attribuut een root zijn. 2. Als er een element is dat niet voorkomt als een subelement van enig ander element in de DTD, dan wordt dit element een root voor een schema van een prototype tree. Het GSE algoritme heeft vervolgens nog één regel: 3. Als er geen enkel element in de DTD is dat voldoet aan 2, dan wordt er een element gekozen om als root te dienen In dit geval is er recursie in de DTD. Op zo'n moment moet er een willekeurig element gekozen worden om de dreigende oneindige cirkel te breken. Met behulp van deze regel wordt een root element gekozen uit de DTD. Vervolgens wordt er een boom gemaakt van de verhoudingen tussen de verschillende elementen. Eventuele attributen van een element kunnen in een boomstructuur gezien worden als subelementen van dat element. In het geval een element alleen #PCDATA bevat, wordt dit de waarde van de node die van dit element gemaakt wordt. Als een element zowel #PCDATA als subelementen bevat, wordt dit in de bijbehorende node aangegeven met een #. In het geval van recursie wordt er een foreign key aan de node toegekend. Dit wordt in het label aangegeven door er.a aan toe te voegen. Vervolgens wordt er gestopt met zoeken naar subelementen van dit element om te voorkomen in een oneindige cirkel te verzeilen. De boomstructuren voor de eerder besproken DTD komen er dan als volgt uit te zien: 21

24 Fig. 6: boomstructuren van de versimpelde DTD van het GSE algoritme Het DSE algoritme heeft dezelfde eerste twee regels maar heeft nog 3 andere regels: 3. Als een niet-#pcdata element in meer dan één element declaratie voorkomt, wordt het een root voor een boomstructuur - Stel dat element C zowel subelement is van A en van B. In dit geval kan aangenomen worden dat er een M:1 relatie bestaat tussen A, B en C. Hierdoor is het nuttig om een extra boomstructuur aan te maken met C als de root. Hetzelfde principe gaat op voor M:N relaties. 4. Als er in de DTD een niet-#pcdata element B met een * ALLEEN voorkomt in een niet-root element A, dan wordt B een root element van een nieuwe boomstructuur, als B NIET het enige subelement van A is - De reden hiervoor is dat er een kans bestaat op een 1:M of zelfs M:N relatie tussen A en B. Als er meerdere subelementen zijn in A hebben deze elementen (mits ze geen * hebben) een 1:1 relatie. Om deze reden moet er voor B een nieuwe boomstructuur komen met B als root 5. Als er recursie optreedt in de DTD wordt één van de elementen in de recursie gekozen als root. Bij root elementen die door de 2e, 3e en 5e regel bepaald zijn, wordt de boomstructuur opgebouwd net als bij het eerder besproken GSE algoritme. De uitzondering hierbij is dat een root element dat gevonden is met de 3e regel niet alleen een nieuwe boomstructuur krijgt, maar ook als nieuwe node wordt toegevoegd aan de huidige boomstructuur omdat er een M:1 relatie te verwachten is tussen de parent van dit nieuwe root element en het element zelf. Het valt 22

25 bijvoorbeeld te verwachten dat er meerdere boeken geschreven zijn door een enkele auteur en het is dus logisch om de auteur op te nemen als verwijzende sleutel in de relatie van een boek. Als er echter een root element gevonden wordt met de 4e regel, dan wordt deze niet als node toegevoegd aan de huidige boomstructuur. In dit geval moet de ancestor van dit element gevonden worden en samen met de subelementen van de gevonden root tot een nieuwe boomstructuur gemaakt worden. Dit wordt gedaan omdat er een 1:M relatie verwacht wordt tussen de ancestor en het root element. Een boek kan bijvoorbeeld meerdere authorities hebben. Hier komen vervolgens de volgende schema's uit: Fig. 7: boomstructuren van de versimpelde DTD voor het DSE algoritme Het schema dat voor het IS algoritme gemaakt wordt, gaat niet uit van deze regels. Dit algoritme bouwt voor de hele DTD in één boomstructuur en vervolgens van alle elementen zogenaamde element graphs zoals vermeld in [SHA99]. 23

26 Fig. 8: boomstructuren van de versimpelde DTD voor het IS algoritme Conclusie Het creëren van deze boomstructuren is voor een belangrijk gedeelte de voorbereiding op het genereren van de prototypes van de relationele schema's. Hoe uitgebreider deze stap wordt uitgevoerd, hoe minder werk er te doen is in de volgende stap. Het minste werk verricht het IS algoritme. Bij dit algoritme wordt voor de hele DTD structuur een boomstructuur gemaakt en vervolgens voor ieder element. Hierbij wordt nog niet nagedacht over hoe de tabellen in de RDB er uit zullen komen te zien. Het GSE algoritme gaat al iets specifieker aan de gang. Er wordt voor een deel al nagedacht over de database structuur door al voor één of meer roots te kiezen en deze te gebruiken als beginpunt van een boomstructuur. Het aantal roots geeft al een aardige indicatie van de tabellen die nodig zijn in de database. Het DSE algoritme gaat hierin nog een stapje verder. De regels die dit algoritme hanteert zijn wat uitgebreider en er kunnen op die manier ook meer boomstructuren ontstaan. Hierdoor zou je kunnen stellen dat het relationele schema bij voorbaat al wat meer genormaliseerd wordt. Conclusies over welk algoritme het meest geschikt is voor mijn doeleinden zullen getrokken in het volgende hoofdstuk. 24

27 3.3 Prototype relationele schema's ontwerpen Nadat de boomstructuren ontworpen zijn, kunnen de prototypes van de relationele schema's gecreëerd worden. Het idee hierbij is dat alle elementen en attributen in de versimpelde DTD gezien kunnen worden als attributen in het prototype voor het relationele schema. De verschillende tabellen in dit prototype schema worden gevormd door de paden vanuit de root naar de eindpunten in de eerder gemaakte boomstructuur. Het pad moet altijd eindigen bij een element of attribuut dat #PCDATA of een mengvorm van subelementen en #PCDATA bevatten omdat deze alleen 'echte' data bevatten. De relationele schema's (overgenomen uit [MEN01]) voor het GSE algoritme komen er dan als volgt uit te zien: table:book ( book.booktitle, (A) book.price, (B) book.author.id, (C) book.author.name.firstname, (D) book.author.name.lastname, (E) book.author.address, (F) book.authority.authname, (G) book.authority.country (H) ) table:monograph ( monograph.title, (A) monograph.author.id, (B) monograph.author.name.firstname, (C) monograph.author.name.lastname, (D) monograph.author.address, (E) monograph.editor.name, (F) monograph.editor.monograph.a (G) ) Fig. 9: de relationele schema prototypes voor de boomstructuren in fig. 6 Op deze schema's zijn nog wel een aantal dingen aan te merken. Allereerst de naamgeving. Doordat je als naam voor een attribuut zijn hele pad vanaf de root gebruikt, worden deze lang. Wel wordt ervoor gezorgd dat alle attributen zo een unieke naam hebben, maar het is de vraag in hoeverre dat in de uiteindelijke tabellen nodig is. Een attribuut is dan namelijk uniek te identificeren aan de hand van de tabelnaam in combinatie met de veldnaam. Een ander bezwaar ligt in de misschien te simpele voorstelling. Hierdoor ontstaat onder andere redundantie. De naam van een auteur bijvoorbeeld wordt nu twee keer opgeslagen. Deze simpele voorstelling kan juist ook als een voordeel werken. Het is niet heel erg moeilijk om de structuur van de database en zijn tabellen te doorgronden op deze manier. Nu kijken we hoe dit in zijn werk gaat bij het DSE algoritme. In tegenstelling tot bij het vorige algoritme worden in deze schema's niet de mogelijke sleutels opgenomen (de vet gedrukte attributen in fig. 7). Deze sleutels worden later ingevoegd als de functionele afhankelijkheden en mogelijke sleutels gezocht 25

28 worden. Het schema dat overgenomen is uit [MEN01], komt er nu als volgt uit te zien: table:book(booktitle, price) table:authority(country, authname) table:author(address, id, firstname, lastname) table:monograph(title, name) Fig. 10: de mogelijke sleutels voor de boomstructuren in fig. 7 Aangezien er in dit schema geen gelijke namen zijn, wordt de naam niet bepaald door het pad vanuit de root. Hierdoor is het geheel goed overzichtelijk. Een nadeel is dat er een aantal velden verdwenen is uit het schema. Deze elementen vormen de sleutels en worden in de volgende stap wel weer ingevoegd, maar de inzichtelijkheid komt dit in deze stap niet ten goede. Het volgende algoritme dat besproken wordt is het IS algoritme. Dit algoritme volgt een andere koers dan de vorige twee algoritmen bij het opstellen van de prototype relationele schema's. Voor het genereren van een voorlopig relationeel schema zijn er een drietal technieken in dit algoritme: Basic Inlining Techniek Shared Inlining Techniek Hybrid Inlining Techniek Basic Bij deze techniek worden relationele schema s gemaakt voor alle elementen omdat het in principe mogelijk is dat een XML-document geroot kan worden bij ieder element in de DTD. Er zijn twee situaties die nog nader bekeken moeten worden, namelijk het geval waarin er 1:M relatie is en recursie. In beide gevallen lost dit algoritme dit op met behulp van een extra, foreign key. Het schema dat overgenomen is uit [SHA01], dat hierdoor ontstaat ziet er als volgt uit: book(bookid, book.title, book.author.name.firstname, book.author.name.lastname, book.author.address, author.authorid) booktitle(booktitle.id, booktitle) article(articleid, article.contactauthor.authorid, article.title) article.author(article.authorid, article.author.parentid, article.author.name.firstname, article.author.name.lastname, article.author.address, article.author.authorid) contactauthor(contactauthorid, contactauthor.authorid) title(titleid, title) monograph(monographid, monograph.parentid, monograph.title, monograph.editor.name, monograph.author.name.firstname, monograph.author.name.lastname, monograph.author.address, 26