Ontwerpen van XML-documenten

Ondanks dat sommigen XML nog steeds niet ontdekt hebben, vliegen er al duizenden XML-documenten per dag door onze netwerken. XML is in korte tijd uitgegroeid tot dé standaard voor gegevensuitwisseling. Ondanks deze populariteit bestaan er toch veel vragen over hoe we nu eigenlijk XML-documenten dienen te ontwerpen? Specialisten zonder database-achtergrond zijn op zoek naar nieuwe ontwerpmethodes. Totaal onnodig, we kunnen onze bekende modelleringtechnieken gewoon blijven gebruiken.

Een XML-document bestaat uit een hiërarchisch gestructureerde verzameling elementen. Bijvoorbeeld, het element boek is opgebouwd uit de subelementen auteur, uitgever, titel en ISBN. Het element auteur kent weer de subelementen voornaam, achternaam en titel. Een subelement kan meerdere voorkomens hebben, dus per boek kunnen er meerdere auteurelementen zijn. Elk element kan tevens een verzameling attributen hebben. Het element titel kan bijvoorbeeld een attribuut hebben waarmee wordt aangeven in welke taal de titel gespecificeerd is.

De structuur van een XML-document kan met diverse schematalen beschreven worden. We kunnen hiervoor DTD (Document Type Definition), XSDL (XML Schema Definition Language), XDR (XML Data Reduced), SOX (Schema for Object-Oriented XML) of een van de andere schematalen kiezen. DTD was de eerste en XSDL zien we als de meest complete. De verschillen tussen de schematalen liggen niet zozeer in het beschrijven van de structuur van XML-documenten, maar in het specificeren van datatypes en integriteitregels. Bijvoorbeeld, DTD biedt geen enkele mogelijkheid om integriteitregels te specificeren, terwijl XSDL juist sterk op dit gebied is.

Het ontwerpen van XML-documenten behelst dus niets anders dan het bepalen van de structuur, de datatypes en de integriteitregels. Hierbij betekent het bepalen van de structuur het nadenken over de benodigde elementen, hun onderlinge hiërarchische structuur en de bijbehorende attributen. 

Voor het ontwerpen van een databasestructuur geldt eigenlijk hetzelfde: het bepalen van de structuur, de datatypes en de integriteitregels. Alleen de bouwstenen van, bijvoorbeeld, een relationele database zijn anders. In plaats van elementen zijn relationele databases opgebouwd uit tabellen en kolommen. Ook de integriteitregels zijn anders. In de relationele wereld kennen we onder andere de primaire-sleutel, de refererende-sleutel en de trigger.

Er is al tientallen jaren studie uitgevoerd naar en ervaring opgedaan met het ontwerpen van databasestructuren. De belangrijkste les die we geleerd hebben, is dat we het gehele ontwerpproces in minimaal twee fasen moeten opbreken: logisch ontwerp en fysiek ontwerp. Het accent tijdens de eerste fase ligt op het doorgronden van de gegevens waarom het gaat. Het resultaat is een verzameling regels voor de gegevens. We kunnen in deze fase een moderne techniek als UML (Unified Modelling Language) gebruiken of een wat klassiekere variant, zoals EAR (Entiry-Attribute-Relationship).

Het resulterende logische gegevensmodel is een neutrale, technologie-onafhankelijke specificatie van de gegevens die opgeslagen moeten worden. Door deze niet al te veel te richten op een bepaalde databasetechnologie is ze onafhankelijker van toekomstige technologische veranderingen en kunnen we tijdens de logische ontwerpfase bouwstenen gebruiken die dicht bij de belevingswereld van de gebruiker liggen. Dezelfde fase uitvoeren met behulp van bouwstenen als tabellen en kolommen is als het ontwerpen van een huis met behulp van een hamer en zaag.

Tijdens de fysieke ontwerpfase vertalen we de neutrale specificaties uit het analysemodel naar SQL-tabellen, kolommen en sleutels. Indien er technologische vorderingen gemaakt worden, of er wordt een niet-relationele database ingezet, dan verandert dat niets aan het logische ontwerpmodel. Er hoeft slechts een andere vertaalslag gehanteerd te worden.

Deze lessen zijn uiteraard ook van toepassing op het ontwerpen van XML-documenten. Als er een hoeveelheid gegevens uitgewisseld moet worden, kunnen we hiervoor technieken als UML en EAR wel degelijk goed gebruiken. Onze twintig jaar ervaring hoeven we dus niet overboord te gooien. Het enige verschil is dat we tijdens de fysieke ontwerpfase een andere vertaalslag krijgen, namelijk één die de neutrale specificaties omzet naar de XML-bouwstenen, zoals elementen en attributen.

Er is dus geen behoefte aan een nieuwe techniek voor het logische ontwerp van XML-documenten. Tot nu toe heeft nog niemand een overtuigend argument aangedragen waarom XML zo speciaal zou zijn, dat er een speciale techniek voor bedacht zou moeten worden. UML en EAR zijn beide krachtig genoeg om deze taak te vervullen. Alleen voor fysiek ontwerp moet een nieuwe vertaalslag bedacht worden, maar dat wordt slechts een variant op een bekend thema.