R2D2 > XML 2 RDB: een nieuw algoritme > Algoritme > Positionering

5.1.4 Positionering

Er moet nog een aantal dingen aangepast worden. Op alle plaatsen waar de #PCDATA opgeslagen worden, staat nu nog in het schema #PCDATA als veldnaam. Dit kan beter veranderd worden in een wat meerzeggende veldnaam. Al deze velden worden dan ook hernoemd in tabelnaam + Val. In het geval van de comments tabel zal het #PCDATA veld dan ook vervangen worden voor commentsVal.

Het laatste wat nu nog moet gebeuren is een manier vinden om de positie van de elementen in het XML-document op te slaan in de database. Een drietal methoden zijn te vinden in [TAT02]. De eerste methode, global order encoding, nummert de elementen in volgorde van voorkomen. Er ontstaat dus een absolute nummering van de elementen. Voordeel: het is heel makkelijk om de originele structuur terug te krijgen of door te zoeken. Nadeel: Als er ergens een element moet worden toegevoegd, moeten vanaf dat punt alle posities van de elementen één opgehoogd worden. Dit kost dus erg veel tijd en moeite, maar is in het geval van archief functionaliteit minder een probleem. De tweede methode heet local order encoding en nummert de elementen per 'generatie'. Met andere woorden de relatieve positie wordt opgeslagen. Voordeel: het invoegen van nieuwe elementen kost nu minder tijd en moeite. Nadeel: in het reconstrueren van het XML-document kost nu erg veel tijd. De derde en laatste methode is Dewey order encoding. Dit systeem slaat het pad naar een element op. Aan het positienummer is dus te zien welk element zijn parent is en op zijn beurt zijn parent, enz. Toch voldoen deze methoden allemaal niet genoeg.

Mijn methode is voor een deel wel op de daargenoemde methoden gebaseerd, maar wijkt toch op een aantal essentiële punten af. De belangrijkste reden hiervoor is dat in dit artikel uitgegaan wordt van de situatie waar een XML-document zonder DTD gebruikt wordt. Door het gebruik van een DTD worden de methoden minder bruikbaar. Ik stel dan ook op enkele punten aanpassingen op deze methode voor.

Een XML document is een geordend document. Bij het omzetten naar een relationele database moet daarom de mogelijkheid gegarandeerd worden dat posities of volgordes blijven bestaan voor toekomstig gebruik. Deze geordendheid in een XML document is vooral van belang als een subelement meerdere keren voorkomt onder een element. In dit geval is de volgorde namelijk essentieel. Hierbij valt te denken aan bijvoorbeeld de volgorde van paragrafen in een tekst. Als je de originele volgorde niet vasthoudt, kan er een vreemde tekst ontstaan die nog maar weinig samenhang vertoont. In het relationele schema moeten dan ook velden worden toegevoegd voor het aangeven van de positie in de tabellen die ontstaan zijn uit de regels 4 en 5 voor het opstellen van tabellen in paragraaf 5.1.2. Dat betekent dat de tabellen review, comments, author, tutorial, reference en authorname een extra veld pos krijgen waarin hun positie onder hun parent element opgeslagen kan worden.

Deze methode heeft een belangrijk nadeel: het gemengd voorkomen van verschillende elementen. Als onder een review element zowel een rating element als twee comments elementen voorkomen, is alleen de volgorde van de twee comments elementen bekend. Waar het rating element moet komen (voor de twee comments elementen, er tussen in of achteraan) is niet bekend. In de meest gelukkige situatie ligt deze informatie vast in de DTD, maar er zijn gevallen te bedenken waar dit niet het geval is. In zulke gevallen zou dit systeem spaak lopen. Er zijn echter een aantal redenen waarom ik dit systeem toch aanhoud. Op de eerste plaats is mijn systeem meer bedoeld voor datagerichte XML. In dit soort data is de ordening van de data van minder belang en anders ligt deze vast in de DTD. Een tweede argument is dat ik eerlijk gezegd niet met een beter alternatief kon komen. Dit is zeker iets dat in een eventueel vervolg op deze scriptie onderzocht zou moeten worden. Een derde en laatste reden, zeker niet de beste en belangrijkste reden, is dat ik me vooral bezig houdt met de conversie van XML naar RDB en niet andersom. Dat neemt niet weg dat er geen rekening gehouden zou moeten worden met de eventuele terugconversie, maar dat heb ik dan ook naar mijn beste kunnen gedaan.

Als we deze laatste wijzigingen doorvoeren in het schema uit fig. 21, krijgen we uiteindelijk schema uit fig. 22. Dit schema is het uiteindelijke relationele schema van hoe de database structuur er uit komt te zien. in het volgende stuk zal ik het functionele ontwerp voor de applicatie, die met dit algoritme gaat werken, bespreken.