op te nemen. Het is duidelijk dat dat weer ten koste gaat
van een ander doel van modulariteit: de eenvoud en her
kenbaarheid van de module. In de volgende sectie komen
nog andere eigenschappen van een goede module aan
de orde.
Modulariteit
De klassieke criteria waaraan een goede module moet
voldoen, zijn: complexiteit, koppeling en cohesie. De
complexiteit van een module kunnen we eenvoudig defi
niëren als het aantal specificaties (het aantal ;'s) in het
schema.
De koppeling is in wezen de mate waarin een module zijn
complexiteit aan de omgeving toont. Hoe meer complexi
teit een module toont, hoe meer consequenties een wijzi
ging in de module zal hebben voor de omgeving, en hoe
moeilijker het zal zijn om de module te wijzigen. Koppe
ling is dus het omgekeerde van „information hiding"
(details van specificaties verbergen voor de omgeving).
Op basis van de complexiteit laat koppeling zich nauw
keurig definiëren als het gemiddelde aantal keren dat
elke specificatie voorkomt in het schema van een andere
module. De koppeling bepaalt daarmee het aantal andere
modulen waarmee elke wijziging in de structuur van de
module zal moeten worden afgestemd. De grootte en het
gewicht (in de zin van aantal lezers) van het publieke
domein is dus bepalend voor de koppeling. De koppeling
van een module is minimaal als het publieke domein leeg
is en maximaal als het hele schema zichtbaar is voor elke
andere module.
De cohesie van een module is de mate waarin een modu
le erin slaagt zich af te sluiten voor de complexiteit van de
omgeving. Een module met een goede cohesie is dus
ongevoelig voor wijzigingen in de structuur van de om
geving. Cohesie laat zich definiëren als het quotiënt van
het aantal eigen en het totale aantal specificaties in het
schema van de module. De cohesie is dus de relatieve
complexiteit van het eigen domein.
Een module met maximale cohesie heeft geen vreemd
domein. Hij gebruikt geen gegevens uit de omgeving.
Een module met minimale cohesie heeft geen eigen do
mein: hij gebruikt uitsluitend gegevens uit de omgeving.
Merk op dat cohesie en koppeling van een module onaf
hankelijk van elkaar kunnen worden gevarieerd. Wel is
het zo dat vergroting van de koppeling van de ene module
vermindering van cohesie voor een andere module im
pliceert.
Modulair beheer van constraints
Door een schema in modulaire vorm te specificeren,
wordt een aantal voordelen verkregen. Het eerste voor
deel is dat de modulen eenvoudig zijn en herkenbaar voor
de gebruiker. Daartoe moeten modulen wel overeen
komen met bestaande taakclusters in de organisatie. Het
is een bekend verschijnsel dat niet-informatici worden
afgeschrikt door gegevensstructuur-diagrammen. Het ge
volg is dat de gebruikers geen binding voelen met het
gegevensbank-schema, en ook geen verantwoordelijk
heid nemen voor structuur en inhoud van de gegevens
bank. De informatici kunnen deze verantwoordelijkheid
echter niet waarmaken, omdat zij onvoldoende binding
hebben met het toepassingsgebied.
Bij een modulaire structuur heeft een gebruiker alleen
met zijn eigen schema te maken. Dat is in principe niet
complexer dan de zaken waarvoor het verantwoordelijk
NGT GEODESIA 93 - 7
is. De ervaring leert dat daardoor de eindgebruikers het
schema accepteren en feitelijk gaan gebruiken. Dit komt
de snelheid van systeemontwikkeling en de kwaliteit van
de gegevens zeer ten goede.
Een tweede voordeel is dat het beheren van het stelsel
van constraints en regels veel gemakkelijker wordt. Bij
een niet modulair schema treft men doorgaans alle
constraints aan in een lange lijst onderaan het schema.
Daarbij worden vaak alleen die constraints opgenomen,
waarvan men verwacht dat het DBMS ze kan controleren.
De overige regels raken verspreid over de documentatie
van de verschillende programma 's.
Omdat doorgaans meerdere programma's met dezelfde
regel te maken hebben, ontstaat een enorme redundantie
in regels en constraints: elke regel staat op verschillende
plaatsen vermeld. Zoals bekend geeft redundantie onver
mijdelijk problemen bij onderhoud: als een regel wijzigt,
is het moeilijk om de consequenties te overzien en niet
onwaarschijnlijk dat de wijziging niet op alle plaatsen
wordt doorgevoerd. Fouten in programma's, verkeerde
gegevens in de gegevensbank en verkeerde resultaten in
rapporten zijn hiervan onvermijdelijk het gevolg.
Bij een modulaire structuur staan regels bij elkaar in het
schema van een module. Zo'n schema is klein en over
zichtelijk. Omdat de vreemde domeinen uit de schema's
kunnen worden afgeleid, kan eenvoudig een programma
worden gemaakt dat aangeeft waar door de wijziging de
onafhankelijkheid van andere modulen wordt verstoord.
Omdat het niet altijd noodzakelijk is om eigen constraints
ook aan andere modulen te laten zien, kunnen de ge
volgen van wijzigingen worden beperkt. Door bij het ont
werp en het onderhoud voortdurend de koppeling en de
cohesie te bewaken, kan de flexibiliteit van het systeem
worden gewaarborgd en bewaakt.
Gevolgen voor (geo)grafische gegevens
In geografische gegevens is de samenhang veel sterker
dan bij conventionele, bestuurlijke toepassingen. Niet
alleen is er meer samenhang door diepere hiërarchische
structuren, ook zijn er meer en complexere constraints.
Daardoor zal het onderhoud van zulke systemen veel
moeilijker zijn dan van klassieke, relationele systemen.
Dezelfde ervaring ziet men bij systemen voor produkt-
gegevens, waar een zelfde soort complexiteit optreedt.
Naarmate meer geografische gegevens in elektronische
vorm worden beheerd en meer gebruik wordt gemaakt
van deze gegevens door geautomatiseerde systemen,
zullen de eisen voor integriteit strenger en daarmee de
problemen bij onderhoud groter zijn. Modulair ontwerp en
beheer van zulke systemen kan dan een oplossing bie
den voor veel problemen.
Literatuur
1. Bekke, J. H. ter, Database Ontwerp. Stenfert Kroese. Leiden
1988.
2. Chen, P., The Entity Relationship Model Towards a Unified
View of Data. TODS, 1:1, 1976.
3. Codd, E. F., A Relational Model of Data for Large Shared Data
Banks. Comm ACM, Vol. 13, no. 16, juni 1970.
4. Date, C. J., An Introduction to Database Systems. 5th ed. Addi
son Wesley, 1990.
5. Elmasri, R., S. B. Navathe, Fundamentals of Database Systems.
Benjamin/Cummings, 1989.
6. Kim, W., F. H. Lochovski (ed.), Object-Oriented Concepts, Data
bases and Applications. ACM Press, 1989.
7. Pels, H. J., Gegevens: Analyse, Modellering en Beheer. Sam-
som, 1992.
8. Wintraecken, J. J. V. R., Informatie-analyse volgens NIAM, in
theorie en praktijk. Academic Service, 1987.
323
