4. de manier van uitdrukken: 'mag
nooit' (struik mag nooit in het water
staan) of 'altijd moet' (struik moet
altijd op grasveld geplant worden);
5. de aard van de constraint: 'fysiek on
mogelijk' (boom kan niet vrij in de
lucht zweven) of 'ontwerpdoelstel
ling' (struik zou ten zuiden van een
boom moeten staan).
Nu het belang van constraints in ver
schillende cases is aangetoond en nu
we ook beschikken over een classifica
tie van de verschillende soorten con
straints, komt de vraag: hoe nemen we
constraints mee in het systeem? Ten
eerste zal de specificatie goed toegan
kelijk en intuïtief moeten zijn voor de
makers van de modellen. De con
straints zouden onderdeel van het
complete model moeten zijn en zo for
meel mogelijk moeten zijn zodat hier
later automatisch delen van subsyste
men (edit/simulatie, database/opslag,
uitwisseling/conversie) uit kunnen
worden gegenereerd. Een formele aan
pak zorgt er ook voor dat de con
straints niet ambigue zijn. De Unified
Modelling Language (UML) is thans
min of meer de standaard aanpak voor
het object-georiënteerd modelleren
[OMG, 2002]. UML is een grafische taal
die verschillende soorten diagrammen
onderscheidt waarvan in onze context
het klassendiagram het meest relevant
is. Aangevuld met een niet-grafische
taal binnen UML, de Object Constraint
Language (OCL), kunnen constraints
verder formeel worden gespecificeerd.
De constraints zijn gespecificeerd en
worden beheerd in een 'repository'
maar zouden nu ook het fundament
voor verdere implementatie moeten
vormen in alle subsystemen: edit/simu
latie, database/opslag, uitwisselen/con
versie. De edit/simulatie-applicatieom-
geving (hoewel belangrijk voor interac
tie) zal hier niet verder worden uitge
werkt. In de context van de uitwisse
ling speelt XML een belangrijke rol en
kan het XML-schema worden gebruikt
voor het beschrijven van het model. Zo
als eerder aangegeven is ook hier nog
nader onderzoek nodig om de con
straints automatisch van UML/OCL om
te zetten naar XML-schema.
Nu zal verder worden ingegaan op de omzetting van
UML/OCL-constraints naar de implementatie hiervan in
een database. De redenen hiervoor zijn dat de database
naar alle verwachting hier geschikt voor is (flexibiliteit
biedt bij specificeren van constraints) én dat de database
de plek is waar vanuit meerdere gebruikers toegang heb
ben tot dezelfde set consistente gegevens. Sinds SQL92 zijn
'general constraints' (assertions) onderdeel van deze stan
daard. Helaas zijn ze niet geïmplementeerd in de gangbare
database. De ontwikkelaars worden verwezen naar het ge
bruik van 'triggers' (en vaak ook 'procedures') voor de im
plementatie van generieke constraints. De soorten con
straints die op dit moment wel goed door database worden
ondersteund zijn: domein-constraints (specificeren van
enumeratie-typen of range-typen) en 'base table con
straints' (waaronder ook de referentiële integriteit-con-
straints vallen). Assertions vormen echter een handige en
compacte SQL-schrijfwijze van constraints en het zou ook
mogelijk moeten om zijn deze automatisch uit UML/OCL af
te leiden. Ze vormen dan mooie opstapjes die kunnen wor
den gebruikt bij het later herschrijven naar de trigger/pro
cedure vorm.
Het voordeel is dat de trigger/procedure-oplossing echt
werkt in de praktijk maar het nadeel is dat deze veel co-
deerwerlc oplevert. Er zijn echter ontwikkelomgevingen die
de generatie van deze triggers (en procedures) ondersteu
nen, zoals Oracle's CDM Ruleframe. Een laatste opmerking
over de ondersteuning van constraints door databases:
naast standaard domein-constraints en referentiële inte
griteit komt er de laatste tijd ook steeds meer standaard
ondersteuning voor topologische structuren en/of con
straints in de databases: Oracle lOg spatial omvat onder
steuning voor topologische structuren (DBMS controleert
topologische consistentie), LaserScan Radius topology en
er komen ook meer 'middleware'-achtige oplossingen met
topologische constraints ondersteuning zoals de ESRI geo-
database.
Hoewel constraints binnen GIS tot nu toe niet veel aan
dacht kregen, blijken ze in de vier cases een belangrijke rol
te spelen, steeds op een andere manier. Er is op basis van de
cases en de beschikbare literatuur een voorstel voor de clas
sificatie van constraints gegeven. Deze kunnen dan meege
nomen worden in de formele beschrijving van het model
(UML/OCL). Uit dit model moeten dan automatisch de ver
schillende subsystemen worden gegenereerd (edit, opslag,
uitwisseling) die dan allemaal gebaseerd zijn op dezelfde
constraints. Op dit moment is het volledig automatisch af
leiden van de verschillende subsystemen uit het model nog
onderwerp van onderzoek. De visie zal voor een deel voorlo
pig met de hand moeten worden uitgewerkt.
Een uitgebreider, Engelstalig, artikel verschijnt binnenkort in:
Oosterom, Peter van, Constraints in Spatial Data Models in a
Dynamic Context., Chapter 4 in: Drummond, J., Billen, R., Forrest,
D. and Joao, E. (editors), Dynamic Mobile GIS: Investigating
Change in Space and Time. Taylor Francis, 2006.
GEO-INFO 2005-9
Specificeren van constraints
Implementatie van
constraints
Conclusie
