entiteittype in zijn vreemde domein niet alle entiteiten
ziet, die de eigenaar heeft gecreëerd.
Al die entiteittypen, entiteiten en attributen die eigen zijn
voor een bepaalde module, en ook in het zichtdomein van
tenminste één andere module voorkomen, vormen het
publieke domein van die module. Het publieke domein
vormt de uitgaande interface van de module. De overige
gegevens worden beschouwd als het privé domein van
de module.
Van privé gegevens kan de eigenaar zowel de structuur
als de waarde veranderen, zonder dat andere modulen
daar last van hebben. In het beheer van die gegevens is
hij dus autonoom.
Onafhankelijkheid
Merkwaardig genoeg hoeven modulen niet aan veel eisen
te voldoen om te kunnen worden geïntegreerd. Ze heb
ben maar deels dezelfde entiteittypen nodig en per enti
teittype maar deels dezelfde attributen. Beide modulen
behoeven niet dezelfde constraints te hebben voor ge
meenschappelijke entiteittypen. Wil men echter dat de
modulen kunnen worden gebruikt als zelfstandige ge
gevensbanken, dan moeten enkele aanvullende voor
waarden worden gesteld.
Een module noemen we onafhankelijk in het geïntegreer
de systeem als hij de eigenschap heeft dat programma's
die voor de afzonderlijke module zijn getest, ook correct
werken in het geïntegreerde systeem en dat ze niet door
wijzigingen in de schema's van andere modulen kunnen
worden verstoord. Onafhankelijkheid betekent dat noch
de programmeur noch de gebruiker kennis hoeft te
hebben van structuur of gegevens buiten het schema van
de module.
De logische voorwaarde voor onafhankelijkheid is dat de
gebruiker of de programmeur van de module voor elke
wijziging van een gegeven in het eigen domein alle
constraints kan controleren die daarbij een rol kunnen
spelen. Een constraint kan hij alleen controleren als die
voorkomt in zijn schema. Een constraint kan alleen voor
komen als alle gegevens waarnaar die constraint wijst,
zichtbaar zijn volgens het schema van de module. Deze
eis betekent dat geen enkele andere module constraints
mag bevatten, die verwijzen naar eigen gegevens van de
onafhankelijke module en die niet worden geïmpliceerd
door een constraint van de onafhankelijke module.
Deze voorwaarde klinkt wat abstract, maar hij is heel
gemakkelijk te controleren, zoals wordt getoond in het
volgende voorbeeld (zie kader).
Dit voorbeeld toont hoe het de constraints zijn die be
palen of voor een module de juiste interfaces zijn ge
kozen. Die bepalen namelijk of het vreemde domein
voldoende zicht biedt op de omgeving om onder alle om
standigheden alle relevante constraints te kunnen na
leven. De eenvoudigste oplossing om alle modulen onaf
hankelijk te maken, is om alle gegevens in hun schema
Voorbeeld
MODULE HUIS
entiteittype
Persoon(een natuurlijk persoon];
attributen
Naam [achternaam en voorletter];
Adres[volledig postadres];
Geboortedatum
Sofinummer [sociaal-fiscaal nummer);
entiteittype
Huis[een gebouw of gedeelte voor af
zonderlijke bewoning];
attributen
Kadastraal nummer
Woningnr[unieke code per woning];
Eigenaar[de rechtspersoon die eigenaar is
van de woning];
Hoofdbewoner[natuurlijk persoon die hoofdbe
woner is];
Waarde
Oppervlakte [perceelsoppervlak in m2];
Inhoud[inhoud woning in m3];
Adres
eigen-domein
Persoon Huis
Het waterleidingbedrijf beheert de aansluitingen van huizen op
het waterleidingnet. De voor dit beheer benodigde gegevens zijn
beschreven in dit schema.
Module „Waterleiding" Is geïntegreerd met module „Huis". In
deze structuur is module „Waterleiding" eigenaar van „Aan
sluiting" (met wordt aangegeven dat alle attributen eigendom
zijn) en van het attribuut „Aansluitingen" van „Huis". Voor deze
module vormen de overige attributen van „Huis" dus het vreemde
domein. Entiteittype „Huis" hoort tot het publieke domein van
module „Huis".
Constraint C1 voldoet aan de voorwaarde voor onafhankelijkheid,
maar constraint C2 niet. Deze refereert namelijk naar het eigen
MODULE WATERLEIDING
entiteittype
Huis
attributen
Kadastraal nummer
Woningnr
Hoofdbewoner
Inhoud
Adres
Wateraansluiting [de waterleidingaansluiting];
entiteittype
Aansluiting
attributen
Huis[het aangesloten huis];
Maxafname[maximale afname in m3 per uur];
Vorige meterstand
Huidige meterstand
Opnamedatum
constraints
C1 Huidige meterstand Vorige meterstand;
C2 Maxafname Huis. Inhoud;
eigen-domein
Huis (Aansluiting), Aansluiting
attribuut „Inhoud" van module „Huis" en naar attribuut „Maxaf
name" van module „Aansluiting". Dit laatste attribuut is echter
niet zichtbaar voor module „Huis". Als gevolg hiervan is module
„Huis" afhankelijk: stel dat men wegens een verbouwing de in
houd wil verkleinen, dan is het mogelijk dat constraint C2 daar
door wordt geschonden. Dit kan echter niet vanuit module „Huis"
worden gecontroleerd.
Er zijn twee mogelijkheden om module „Huis" onafhankelijk te
maken. De eerste is om het vreemde domein van de module uit
te breiden met het entiteittype „Aansluiting", met eventueel al
leen attribuut „MaxAfname". De andere mogelijkheid is om de
constraint uit module „Waterleiding" te laten vallen.
322
NGT GEODESIA 93 - 7
