Modulaire gegevensstructuren
wisselen van modulen. Als criteria voor een goede modu
le golden:
beperkte complexiteit;
minimale koppeling met de omgeving;
maximale cohesie.
In het volgende zullen we deze begrippen toepassen op
gegevensstructuren.
Modulariteit in gegevensbank-gebruik
In de gangbare gegevensbank-theorie missen we deze
modulariteit. De ontwerpmethoden eisen dat eerst een
conceptueel schema wordt ontworpen voor de hele ge
gevensbank en dat daarna de toepassingsprogramma
tuur wordt ontwikkeld. Nadat de gegevensbank gereed is,
blijkt het meestal bijzonder lastig om nog nieuwe gege
vens en nieuwe toepassingen aan het geheel toe te
voegen. Het informatiesysteem wordt starder naarmate
het aantal toepassingen toeneemt.
Voor elke wijziging in het schema zal de gebruiker een
verzoek moeten indienen bij de gegevensbank-beheer
der. Deze zal het verzoek inbrengen in de wijzigingspro
cedure, hetgeen betekent dat vertegenwoordigers van
alle gebruikers de kans krijgen om na te gaan of zij van
de wijziging geen nadeel ondervinden. Hoe groter het
aantal gebruikers, hoe langer die procedure duurt.
Een ander nadeel voor de gebruiker is dat, naarmate het
systeem groter wordt, hem steeds vaker zal worden ge
vraagd zijn programma's aan te passen aan verande
ringen ten behoeve van andere gebruikers. Ook zal hij
steeds vaker worden verrast door storingen in zijn pro
gramma's, die veroorzaakt worden door acties van ande
re gebruikers.
Een derde probleem is dat het steeds meer zal voor
komen dat een gebruiker bij het toevoegen of wijzigen
van een gegeven een onbegrijpelijke foutboodschap
krijgt van het DBMS. Bijvoorbeeld omdat een andere
gebruiker ergens een waarde heeft staan, die om privacy-
redenen niet kan worden gelezen, maar die toch in con
flict is met de voorgenomen wijziging.
Om deze nadelen te ondervangen, zou het mogelijk moe
ten zijn een gegevensbank-systeem op te delen in afzon
derlijke modulen, elk met zijn eigen sub-gegevensbank
en zijn eigen programma's. De gebruiker kan dan zijn
eigen programma's (laten) ontwikkelen en wijzigen, zon
der met anderen rekening te hoeven houden. Uiteraard
moet het systeem wel zijn geïntegreerd: gegevens die op
verschillende plaatsen worden gebruikt, moeten maar
één keer worden ingegeven.
Geografische informatiesystemen hebben te maken met
een complexe structuur waarin veel constraints voor
komen (zie het openingsartikel van deze mini-serie). Ze
krijgen in toenemende mate te maken met een hoge mate
van veranderlijkheid. Daarbij neemt de behoefte aan inte
gratie snel toe, omdat steeds meer verschillende dien
sten gebruik gaan maken van geografische gegevens.
Daarom is zo'n modulaire structuur voor geografische
systemen van direct belang. Een structuur waarin dat
mogelijk is, wordt in de volgende sectie beschreven.
Gebruiksrecht en interfaces
Voor het definiëren van een modulaire gegevensbank
gaan we terug naar het beeld van een kantooromgeving
waarin mensen, ieder achter zijn eigen bureau, hun werk
doen. Dit beeld is weergegeven in fig. 1.
Het bureau is het eigen domein van de klerk. De docu
menten die op zijn bureau liggen, kan hij lezen en be
schrijven. Hij ontvangt informatie uit zijn omgeving via de
inkomende postbak. Voor de duidelijkheid is deze naast
het bureau getekend. Op de documenten van anderen
word je geacht niet te schrijven. Je mag ze alleen lezen.
Informatie die ook door anderen moet worden gelezen,
plaatst hij in zijn uitgaande postbak. In zekere zin bestaat
de totale kijk van de klerk op zijn werk uit zijn bureau,
inclusief de uitgaande postbak en de inkomende postbak.
Analoog aan dit beeld worden modulen in een gegevens
bank gedefinieerd. Het schema van de module omvat
alles wat de gebruiker kan zien, gespecificeerd in de
vorm van entiteittypen, attributen en constraints. Ten
einde onderscheid te kunnen maken tussen gegevens die
door de module zelf worden gecreëerd en onderhouden
en gegevens die de module van anderen ontvangt (dus
om het bureau van de inkomende postbak te scheiden),
wordt een deel van de zichtbare gegevens afgebakend
als het zogenaamde eigen domein. Het eigen domein
omvat de subset van zichtbare gegevens waarvoor de
module wijzigingsrecht geeft. Deze subset kan worden
gespecificeerd in de vorm van een view, bepaald door de
constraints waaraan de eigen entiteiten moeten voldoen
(view een vooraf gedefinieerd filter waarmee kan
worden bepaald welk deel van tabellen zichtbaar is en
welk deel niet).
Fig. 1.
De gegevens die volgens het schema van de module niet
eigen zijn, vormen het vreemde domein. De module geeft
voor deze gegevens alleen raadpleegrecht. Dit betekent
dat de module veronderstelt dat hij geïntegreerd zal zijn
met één of meer andere modulen, die dan de eigenaars
van deze gegevens zullen zijn. Het vreemde domein
vormt als het ware de ingaande interface van de module
met zijn omgeving. Het eigen en vreemd domein samen
wordt het zichtdomein van de module genoemd.
Integratie van modulen
Als twee modulen zijn geïntegreerd, betekent dat, dat
gelijknamige entiteittypen met elkaar overeenkomen.
Binnen gelijknamige entiteittypen komen gelijknamige
attributen met elkaar overeen. Als de gegevensbanken
van twee modulen worden geïntegreerd, blijven de enti
teiten uniek. Gelijke entiteiten in beide modulen repre
senteren dus hetzelfde feit. Het beeld van dat feit kan in
beide modulen verschillen, omdat zij niet dezelfde attribu
ten hoeven te zien. Gelijke attributen hebben uiteraard
wel gelijke waarden in beide modulen. Ook ziet een
module in zijn vreemde domein alleen de entiteiten die
voldoen aan de constraints in zijn eigen schema. Als
gevolg daarvan is het mogelijk dat een module van een
NGT GEODESIA 93 - 7
321
