Overslaan en naar de inhoud gaan

XML doorbreekt impasse met relationele modellen

Bestaande applicaties vormen voor organisaties vaak een belemmering bij het makkelijk kunnen doorvoeren van veranderingen in de bedrijfsvoering en het op de markt brengen van nieuwe producten. De oorzaak daarvan is veelal gelegen in het feit dat het onderliggende gegevensmodel niet voorbereid is op de gewenste wijziging en dat de code om met het resulterende complexe gegevensmodel om te gaan, te ingewikkeld is geworden om nog eenvoudig te kunnen beheren.
Maatschappij
Shutterstock
Shutterstock

Het inzetten van XML-technologie biedt hier een charmante uitweg.

Strijkijzers
Goede ontwerpers van relationele gegevensmodellen houden rekening met mogelijke toekomstige veranderingen. Relationele databases ondersteunen namelijk maar één versie van een gegevensmodel. Wijzigingen in relationele modellen zijn kostbaar. Bestaande data moeten worden gemigreerd en de programmeurs moeten de bestaande applicatielogica aan het nieuwe model aanpassen.
Een veelgebruikte modelleertechniek om op verandering te anticiperen is het ‘parametriseren’ van gegevensstructuren. Dit houdt in dat er bij het modelleren zoveel mogelijk wordt geabstraheerd van de werkelijkheid. Voor een elektronische boekenwinkel modelleert de ontwerper bijvoorbeeld niet een tabel met boeken maar een tabel met abstracte producttypen. Aan deze tabel koppelt hij via een kruistabel een tabel met kenmerktypen. Zo kan hij specificeren dat het producttype ‘boek’ de volgende kenmerktypen kent: ‘titel’, ‘auteur’, ‘uitgeverij’, ‘ISBN-nummer’. Als de winkel nu besluit om ook strijkijzers en spijkerbroeken te verkopen, hoeft hij alleen nog maar de vulling van de tabellen producttype en kenmerktype uit te breiden. Programmeren is niet nodig.
Parametriseren kent een belangrijke beperking. De applicatielogica om gegevens te lezen en te manipuleren is beduidend complexer. Om de gegevens te verzamelen die de eindgebruiker wil zien, moet de code immers alle relevante geparametriseerde waarden verzamelen en samenvoegen. De kans op programmeerfouten is groter en het onderhoud van dergelijke code duurder. Ook is er een risico dat de complexere queries de performance van de applicatie nadelig beïnvloeden.
Los van deze technische complicaties is het simpelweg onmogelijk om alle toekomstige veranderingen vooraf te voorzien. Denk bijvoorbeeld aan verzekeringsproducten. De programmeurs op de ICT-afdeling krijgen grijze haren van elke nieuwe variant die ze bij de business bedenken. In de praktijk vormen de rigide relationele modellen meestal de bottleneck bij de invoering van nieuwe producten. Zou het niet mooi zijn als er een technologie bestond die evoluerende gegevensmodellen als van nature ondersteunt? Goed nieuws: die technologie is volop beschikbaar en ‘proven’: XML.

Veelbelovend
XML is toch die standaard voor het vormgeven en versturen van elektronische berichten? Inderdaad is dat de belangrijkste toepassing sinds XML een ‘aanbevolen’ standaard werd op 10 februari 1998. De afgelopen jaren heeft het grootste deel van de ICT-industrie zich vooral op deze toepassing van XML gericht. Voortschrijdend inzicht leert echter dat er nog een andere veelbelovende toepassing is. Organisaties kunnen het XML-formaat ook gebruiken om gegevens in op te slaan.
In de uitgeverswereld is het toepassen van XML als opslagformaat al langer gebruikelijk. Het voordeel hier is dat de ‘content’ onafhankelijk van de vorm kan worden opgeslagen.
XML heeft twee eigenschappen die de basis vormen voor het doorbreken van de impasse waar het relationele model ons in heeft gebracht. Ten eerste geeft een XML-datastructuur zelf aan hoe de interne structuur is opgebouwd. Elk individueel XML-document bevat namelijk een verwijzing naar het gehanteerde schema. Ten tweede kunnen verschillende versies van hetzelfde documenttype tegelijkertijd voorkomen in de XML-database. Een XML-levensverzekeringsdocument uit 1992 kan bijvoorbeeld een ander formaat hanteren dan een XML-levensverzekeringsdocument uit 2002.
De essentie van de XML-oplossing is om die objecten van een organisatie als uitgangspunt te nemen waarvan de instanties een langere levensduur kennen en waarvan het waarschijnlijk is dat de organisatie er in de loop der jaren andere eigenschappen van wil vastleggen. Denk aan een belastingaangifte bij de Belastingdienst of een strafzaak bij het OM. De organisatie modelleert deze objecten met eenvoudige XML-schema’s in plaats van een complex geparametriseerd relationeel model.
Verschillende versies van een belastingaangifte (IB2004, IB2005 et cetera) kunnen tegelijkertijd voorkomen in de XML-database. Programmeurs schrijven code voor een bepaalde versie van een XML-document. Wanneer besloten wordt dat er een nieuwe versie van een documenttype moet komen (bijvoorbeeld IB2006), blijft de code voor de oude versies standaard beschikbaar. Dit betekent ook dat code in het algemeen eenvoudiger blijft omdat het slechts met één vaak eenvoudige datastructuur om moet kunnen gaan. Sneller ontwikkelen en goedkoper onderhoud liggen in het verschiet.
Betekent dit het einde van de relationele database? Nee, waarschijnlijk niet. Voor bepaalde taken levert een relationele database namelijk betere prestaties dan een XML-database. Het bewaken van referentiële integriteit is daarvan een voorbeeld. Een relationele database biedt standaard voorzieningen om te bewaken dat instanties nooit kunnen verwijzen naar instanties die niet meer bestaan. Dit scheelt de programmeur veel werk.

Complexiteit
In XML-databases ligt dit wat complexer. Voor het opnemen van relaties in een native XML-database is het een goed gebruik om bi-directionele verwijzingen op te nemen. Dat wil zeggen dat bijvoorbeeld een XML-hypotheekdocument naar een XML-klantdocument verwijst en vice versa. Bij mutaties of verwijderingen kan dan snel nagegaan worden welke gerelateerde documenten worden geraakt. Het uitvoeren van deze controleslag is, anders dan bij relationele databases, echter wel de verantwoordelijkheid van de programmeur.
Een ander voorbeeld waarin relationele databases beter presteren betreft het verwerken van grote hoeveelheden data in batches. Relationele databases zijn daar bij uitstek voor geëquipeerd.
Een hybride gegevensarchitectuur waarin XML en het relationele model naast elkaar bestaan heeft de toekomst. Deze architectuur verenigt de sterke kanten van beide werelden. Dit idee leeft ook bij de drie grote relationele database vendors. IBM, Microsoft en Oracle bieden in hun RDBMS-producten inmiddels standaard ondersteuning voor de opslag van native XML. De eerste succesvolle toepassingen hebben het daglicht al gezien.

Guido van der Harst (guido.vanderharst@gartner.com) en Michiel Malotaux (michiel.malotaux@gartner.com) zijn als adviseur werkzaam voor Gartner Consulting. Voor meer informatie over XML: www.w3.org/XML/. Voor meer informatie over het semantic web, OWL en RDF: www.w3.org/2001/sw.



Luchthavensysteem
Een luchthaveninformatiesysteem coördineert de informatieuitwisseling tussen alle organisaties (luchthaven, luchtvaartmaatschappij, verkeersleiding, beveiliging, schoonmaakbedrijf et cetera) betrokken bij de afhandeling van een vlucht. Van landing tot vertrek. Alle gegevens met betrekking tot een vlucht zijn opgeslagen in een zogenoemd vluchtinformatierecord. Het recentelijk opgeleverde systeem hanteert een native XML-database voor de opslag van vluchtinformatierecords.
Het voordeel van XML werd snel benut toen de Amerikaanse overheid in verband met veiligheid nieuwe regels instelde aan de vast te leggen vluchtinformatie. Om aan de nieuwe regels te voldoen volstond een uitbreiding van het XML-formaat met de vereiste velden en een eenvoudige toevoeging van code om deze velden te vullen en uit te lezen. De luchthaven kon nu een – anders dure en foutgevoelige – wijziging met een relatief beperkte inspanning in productie nemen.


Nationaal opsporingssysteem
Het nationaal opsporingsinformatiesysteem is een voorbeeld van een systeem waarvoor native XML als basis voor de gegevensopslag is gebruikt. Opsporingsambtenaren hebben vaak gegevens nodig die in andere opsporingsregio’s zijn verkregen. De informatieuitwisseling tussen de regio’s verloopt moeizaam omdat iedere regio aparte, onafhankelijk ontwikkelde systemen met ieder eigen gegevensstructuren gebruikt.
Door voor iedere regio een apart XML-formaat te definiëren werd het mogelijk om alle opsporingsrecords in één grote database te verzamelen. Door vervolgens met behulp van de standaarden voor het ‘semantic web’ (OWL en RDF) de verschillende gegevensdefinities aan elkaar te relateren werd het mogelijk om interregionale zoekopdrachten uit te voeren. Bovendien konden gegevens tussen regio’s worden uitgewisseld.
Wat anders een arbeidsintensief en complex traject was geworden kon relatief eenvoudig worden gerealiseerd dankzij het gebruik van XML als opslagformaat.

Lees dit PRO artikel gratis

Maak een gratis account aan en geniet van alle voordelen:

  • Toegang tot 3 PRO artikelen per maand
  • Inclusief CTO interviews, podcasts, digitale specials en whitepapers
  • Blijf up-to-date over de laatste ontwikkelingen in en rond tech

Bevestig jouw e-mailadres

We hebben de bevestigingsmail naar %email% gestuurd.

Geen bevestigingsmail ontvangen? Controleer je spam folder. Niet in de spam, klik dan hier om een account aan te maken.

Er is iets mis gegaan

Helaas konden we op dit moment geen account voor je aanmaken. Probeer het later nog eens.

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in