Gege vensmodellen
Een groot aantal verschillende modellen is ontwikkeld om
de structuur en de constraints van gegevens te beschrij
ven [7]. Veelgebruikte modellen zijn NIAM [8], entity-
relationship model [2] [5], relationeel model [3] [4], data
base abstractions (semantisch) model [1] en object-
oriented model (O-O-model) [6]. Van deze modellen wordt
het relationele het meest toegepast en lijkt het object
georiënteerde het meeste toekomst te hebben, vooral
voor geografische systemen.
Het relationele model is gebaseerd op volwassen techno
logie. Er zijn op grote schaal commerciële gegevens
bankbeheerssystemen voor verkrijgbaar en de taal is
zeer goed gestandaardiseerd. Het voornaamste bezwaar
tegen dit model is, dat het is gericht op alfanumerieke ge
gevens met een vlakke structuur (relaties tussen entiteit
type en attribuut: twee niveaus). Het objectgeoriënteerde
model biedt de mogelijkheid om ook grafische en andere
complexe gegevens met diepe geneste structuren te
modelleren. Het is echter nog volop in ontwikkeling en er
is nog geen standaard voor de taal.
De overige modellen hebben het voordeel dat zij meer
semantische uitdrukkingskracht hebben dan het rela
tionele model, maar gegevensbankbeheerssystemen be
staan niet of slechts op experimentele basis. Ze zijn daar
om alleen geschikt voor de voorfasen van het gegevens
bank-ontwerp.
Al deze modellen hebben de concepten van entiteittype,
attribuut en constraint gemeen, zij het dat zij daarvoor
soms andere termen gebruiken. De verschillen zitten met
name in de wijze waarop entiteiten worden geïdentifi
ceerd. Het relationele model kent alleen „afdrukbare"
waarden voor attributen en eist dat elke entiteit door de
waarden van zijn attributen kan worden geïdentificeerd.
Het objectgeoriënteerde model kent in wezen alleen
objecten (alles is een object). Een object is een uniek
symbool dat op zich geen bepaalde afdrukbare vorm
heeft. Op het moment dat een object wordt getoond aan
de gebruiker, kan daarvoor een bepaalde vorm worden
aangewezen (bijvoorbeeld tabel of pie-chart, rode of witte
letters, Engels of Nederlands).
In het vervolg van dit artikel wordt in principe uitgegaan
van een objectgeoriënteerde benadering.
Terminologie
Omdat de term object in geografische systemen een speciale
betekenis heeft, zullen we hier spreken over een entiteit voor
de unieke representatie van een specifiek feit in de gegevens
bank, over attribuut voor een eigenschap van een entiteit met
een bepaalde waarde en over entiteittype voor een klasse van
feiten met gelijke attributen (respectievelijk „object", „me
thod" en „object class" in het O-O-model).
Kwaliteit van gegevens
De oorspronkelijke functie van constraints in een gege
vensbank is om de kwaliteit van de gegevens te bewaken
door te voorkomen dat de gegevensbank onware gege
vens zal bevatten. Door alle onbestaanbare waarden uit
te sluiten, kunnen veel typefouten bij het invoeren van
gegevens worden afgevangen. Oorspronkelijk werden de
noodzakelijke controles ingebouwd in de programma's
die de betreffende gegevens konden toevoegen of wijzi
gen. Het nadeel hiervan is niet alleen dat het veel werk
is, het is ook een onbetrouwbare methode, omdat bijna
niet te bewaken is dat alle programma's precies dezelfde
controles uitvoeren. Men streeft er daarom naar om het
DataBase Management Systeem (DBMS) zoveel mogelijk
de constraints centraal te laten controleren. Het program
ma hoeft dan alleen na elke wijzigingsopdracht de resul
taatcode te controleren en eventueel de centraal gedefi
nieerde foutboodschap aan de gebruiker voor te houden.
Garantie op programma's
Een hard argument voor een zorgvuldige specificatie en
bewaking van constraints ligt in de rol die zij hebben bij
het garanderen van een goede werking van program
ma's. Een programma kan namelijk heel slecht tegen
onvoorziene waarden van gegevens. Als er letters staan
in een veld waarin het programma alleen getallen ver
wacht, gaat het mis. Als een getal van vijf cijfers terecht
komt in een veld van maximaal vier cijfers, zal het resul
taat onjuist zijn. Wordt het eerste of het laatste cijfer weg
gelaten? Drukt het programma een overloopteken af, of
wordt het programma afgebroken? Hopelijk het laatste,
want dan wordt de fout tenminste ontdekt. Ook het af
breken van tekstvelden kan vervelende gevolgen heb
ben, bijvoorbeeld als daardoor een naam incorrect op een
verkiezingsoproep komt te staan.
Gevaarlijker is het als er wordt gerekend met de ge
gevens. Delen door nul is, zoals bekend, niet gedefi
nieerd. Een computer die de opdracht krijgt om door nul
te delen, zal het betreffende programma moeten afbre
ken. Hoe zeker weet een programmeur die een deling
programmeert, dat de noemer nooit de waarde nul zal
hebben in de gegevensbank? In principe kan hij dat
alleen weten als er een constraint is, die voorschijft dat
het betreffende attribuut ongelijk is aan nul.
De constraints in het gegevensbank-schema vertellen de
programmeur welke waarden hij in de gegevensbank
moet verwachten en waartegen hij zijn programma moet
beveiligen. Staat er in het schema de constraint dat de
inhoud van een huis niet nul kan zijn, dan mag hij de prijs
per m3 eenvoudig programmeren als het quotiënt van
prijs en inhoud. Staat die constraint er niet, dan moet hij
een test inbouwen en het uitzonderingsgeval dat de in
houd nul is, op een andere manier afhandelen.
De constraints in het gegevensbank-schema vormen de
basis voor de garantie dat de programma's die op de
gegevensbank opereren, correct zullen werken. Zonder
constraints moet elk programma een voorziening treffen
voor elke uitzondering, hoe onwaarschijnlijk ook.
Als de constraints niet ergens expliciet zijn vermeld (en
het gegevensbank-schema is daarvoor de aangewezen
plaats), zullen verschillende programmeurs verschillende
aannamen maken over welke waarden wel en niet zullen
voorkomen. Die aannamen kunnen tijdens het ontwerp
van het systeem heel aannemelijk lijken, maar dat kan
later veranderen.
Voorbeeld
Tijdens het ontwerp van het systeem zullen vijf cijfers ruim vol
doende lijken voor bijvoorbeeld de onroerend-goedbelasting
voor woonruimte. Na een aantal jaren inflatie kunnen dan plot
seling foute bedragen op de aanslagen verschijnen. Tijdens
het ontwerp zal de eindgebruiker van het systeem desge
vraagd willen verklaren dat de inhoud van een woning altijd
groter dan nul zal zijn. Hoogstwaarschijnlijk zal zijn opvolger,
of misschien zelfs hijzelf enige tijd later in een situatie komen,
die kan worden opgelost door voor de inhoud van een woning
(tijdelijk) nul op te geven. Aangezien er geen constraint was
gespecificeerd, wordt bij invoer niet op nul gecontroleerd. Eni
ge tijd later breekt het programma af dat gebruik maakt van de
prijs per kubieke meter.
NGT GEODESIA 93 - 7
319
