Constraints in CaseTalk

Constraints in CaseTalk
Intro
Dit document beschrijft hoe je in een Casetalk IGD (Information Grammar Diagram) de constraints op
de juiste manier toevoegt. Deze constraits zijn belangrijk, omdat deze grotendeels bepalen hoe je
tabelstructuur eruit komt te zien aan het einde van de rit. De constraits bepalen namelijk welke
informatie samen in een tabel kan en wat gesplitst moet worden over meerdere tabellen.
Elk feittype dat je hebt ingevoerd geeft in CaseTalk een relatie aan. Bijvoorbeeld:
In dit voorbeeld bekijken we de relatie “opname” die de objecttypen “programma” en “DVD” aan
elkaar koppelt. (Het geeft aan welke programma’s op welke DVD staan).
In je diagram moet je voor elke relatie de constraints aangeven. Er zijn 2 constraints relevant:
-
Totality constraints (TC)
o Geven aan of deelname aan een relatie verplicht of optioneel is.
-
Unicity constraints (UC)
o Geven aan of een object meerdere relaties aan mag gaan met objecten van een
ander type
Deze constraints moet je voor elk van de beide deelnemers (objecttypen) van elke relatie geven. Er
zijn dus meestal 4 constraints per relatie die je moet bekijken. We werken ze voor het bovenstaande
voorbeeld uit.
De “programma”-zijde:
Laten we beginnen aan de “programma”-kant van deze relatie. Om te beslissen of er een TC nodig is
moeten we de volgende vraag beantwoorden:
“Is elke programma verplicht om op een DVD te staan, of zijn er ook programma’s zonderd DVD?”
In deze casus mogen we er vanuit gaan dat elk programma uit de database ook daadwerkelijk op een
DVD staat (het bijhouden hiervan is namelijk het doel van deze database), dus hier kunnen we
concluderen dat er en verplichting is. We moeten dus een totality constraint toevoegen aan ons
diagram:
Klik hiervoor met <ctrl> op je toetsenbord ingedrukt op de “programma”-kant van de relatie (nr 1 in
dit diagram) en klik op de TC knop:
:
Je zien een zwart bolletje verschijnen. Dit geeft aan dat er een TC is toegevoegd.
Om te beslissen of er een UC moet worden toegevoegd, beantwoorden we de volgende vraag:
“Mag een programma op meerdere DVD’s staan?”
De casusinformatie is hier niet volledig in, maar het lijkt redelijk om aan te nemen dat een
programma mogelijk op meerdere DVD’s kan staan. We zullen de vraag dus met “Ja” beantwoorden.
Een totalityconstraint is dus niet nodig.
De “DVD”-zijde
Nu we de ene helft van de relatie hebben bekene, moeten we ook nog de andere kant beoordelen.
Voor het totality constraint stellen we de volgende vraag:
“Moet elke DVD een programma bevatten?”
Het ligt voor de hand dat een DVD pas in de database wordt opgenomen in de database als er ook
daadwerkelijk een programma op staat. We zullen de vraag dus met “Ja” beantwoorden en een
totality constraint toevoegen:
Voor de UC stellen we de vraag:
“Mag een DVD meerdere programma’s bevatten?”
Op een DVD kunnen meerdere programma’s staan, us het antwoord is “Ja”. We voegen dus weer
geen UC toe.
Nu treedt er een soort uitzondering in werking omdat we aan beide kanten geen UC hebben
toegevoegd. De regel is dat als beide kanten geen UC hebben (zoals hier), dat er een UC over beide
kanten tegelijk moet. (Dit geeft feitelijk aan dat elke programma maar 1 keer op elke DVD staat, wel
zo zinnig). Hiervoor selecteer je beide helften uit de relatie en klikt op de UC knop:
Er verschijnt een pijl over beide delen van de relatie en daarmee zijn we klaar.
Tot slot
Een laatste onhandigheidje van CaseTalk is dat hij bij elk objecttype ook een UC wil hebben (om aan
te geven dat elk object uniek is). Waarom daar geen automische knop voor bestaat kun je je afvragen
natuurlijk... Het is gelukkig eenvoudig om te doen. Klik een objecttype aan en klik vervolgens op de
UC knop. Een UC pijl verschijnt nu boven het objecttype. Doe dit voor alle objecten en je bent klaar.
In het volgende deel van de uitleg gaan we de database optimaliseren en exporteren.