handleiding gegevensdiagrammen

Handleiding Gegevensdiagrammen 1/34 Laatst opgeslagen door Tom Vercauteren

Handleiding Gegevensdiagrammen

Definitie Een Gegevensdiagram, of Entity Relationship Diagram (of kortweg ERD) is een grafische voorstelling van de relaties tussen de gegevens van een project / toepassing.

Inhoud

Definitie ......................................................................................................................................... 1 Inhoud ........................................................................................................................................... 1 Nut ................................................................................................................................................. 2 Begrippen:..................................................................................................................................... 2

Entiteiten ......................................................................................................................................................... 2 Relaties ........................................................................................................................................................... 2

Symbolen..................................................................................................................................................... 2 Voorbeelden ................................................................................................................................................ 3 Recursieve relaties ...................................................................................................................................... 4

Opmerkingen .................................................................................................................................................. 4 Problemen opsporen.................................................................................................................... 6

Overtollige relaties .......................................................................................................................................... 6 Relaties met meerdere betekenissen ............................................................................................................. 6 Veel op Veel-relaties waar gegevens in verborgen zitten .............................................................................. 7 Volledig verplichte relaties .............................................................................................................................. 7

Normalisatie.................................................................................................................................. 8 0NV: Inventariseer de gegevens, duidt herhalende groepen aan met *................................................... 8 1NV: splits de herhalende groepen af. ..................................................................................................... 9 2NV: splits die (niet-sleutel-)gegevens af die afhangen van een deel van de sleutel ............................ 11 3NV: splits die (niet-sleutel-)gegevens af die afhangen van een ander (niet-sleutel-)gegeven ......... 12 BCNV: Boyce Codd NormaalVorm: als er meer dan 1 kandidaat-sleutel is (en deze overlappen), splits dit gegeven dan zo op dat er geen gegevens verloren gaan. ...................................................................... 12 4NV: Splits die sleutelgegevens af die afhangen van een ander deel van de sleutel............................ 15 5NV: Als elk stuk van de sleutel afhankelijk is van elk ander stuk van de sleutel, splits je in zoveel stukken als er stukken sleutel zijn ................................................................................................................ 17 DS/NV Domein/Sleutel Normaalvorm: zorg dat iedere randvoorwaarde bij de entiteit een logisch gevolg is van de definitie van de sleutels en de mogelijke waarden............................................................ 19 Samenvatting ................................................................................................................................................ 20 Denormalisatie .............................................................................................................................................. 20 Een ERD tekenen ......................................................................................................................................... 20

Visio............................................................................................................................................. 21 Vooraf ........................................................................................................................................................... 21 Praktische aanpak ........................................................................................................................................ 23

De basisstructuur....................................................................................................................................... 23 Gegevens .................................................................................................................................................. 23 Partitioneren (zie opmerkingen) ................................................................................................................ 24 Relaties ...................................................................................................................................................... 27 Relaties wijzigen ........................................................................................................................................ 28 Automatisch schikken ................................................................................................................................ 29

Afdrukken...................................................................................................................................................... 32 Uitgewerkt Voorbeeld:................................................................................................................ 34

07-09-2001

Handleiding Gegevensdiagrammen 2/34

Nut In een gegevensbeschrijving moeten de relaties tussen de gegevens hoe dan ook beschreven worden, maar bij complexe databanken / systemen verliest de lezer (de programmeur, de DA of DBA) al snel het overzicht. Een ERD is trouwens een erg handig overzicht voor de programmeur.

Begrippen:

Entiteiten De gegevens worden gegroepeerd in logisch samen horende delen, die we Entiteiten noemen. Hoe we deze logische gehelen vinden, lees je in het hoofdstuk “Normalisatie” Voorbeelden van Entiteiten zijn: - Werkgever - SD Persoon - Loonperiode - Werknemer

Relaties Tussen deze Entiteiten liggen relaties, die het verband tussen de gegevens weergeven. Voorbeelden van dergelijke relaties zijn: - een Werkgever heeft 0, 1 of meerdere werknemers - Een loonperiode hoort steeds bij 1 werknemer

Symbolen We geven de verschillende types relaties als volgt weer:

Symbool Verklaring Voorbeeld

verplicht één, nooit meer, nooit minder Een loonperiode hoort steeds bij 1 en slechts 1 werknemer

nul of één, maar nooit meer dan één Een werkgever kan een boekhouder hebben, maar nooit meer dan één.

één of meer Een werkgever heeft één of meer werknemers (als hij er geen heeft, is het geen werkgever, maar een zelfstandige zonder personeel)

nul, één of meerdere Een werkgever heeft van SD nul, één of meerdere facturen gekregen sinds zijn aansluiting.

07-09-2001


Elke relatie heeft 2 kanten, dus volgende combinaties kunnen voorkomen:

Voorbeelden Volledige relaties tussen gegevens zien er dan zo uit:

Één Entiteit Omschrijving Relatie Aantallen (symbool) Entiteit

één WERKGEVER is aangesloten bij nul of één BOEKHOUDERS

één BOEKHOUDER heeft als klanten nul, één of meerdere WERKGEVERS

noot: je leest de relatie altijd als “entiteit, lijn, symbool, entiteit”: je leest de naam van de entiteit waarmee

je begint, negeert het symbool dat je eerst tegenkomt, gaat over de relatielijn, leest het symbool aan de andere kant, en leest de naam van de entiteit waar de relatie naartoe gaat.


één AFDELING financieert nul, één of meerdere PROJECTEN

één PROJECT maakt deel uit van één of meerdere AFDELINGEN

07-09-2001


Recursieve relaties Een speciale relatie is een recursieve relatie. Dit komt voor als een gegeven een relatie met zichzelf heeft. Typisch gaat het om een hiërarchische groepering van dit gegeven. Een organigram kan je bijvoorbeeld zo weergeven:


één PERSOON heeft onder zich nul, één of meerdere PERSONEN

één PERSOON heeft als leidinggevende nul of één PERSOON

Typisch aan dit soort relaties is dat je steeds minimum 0 hebt: de directeur werkt enkel voor zichzelf, en wie onderaan staat heeft geen ondergeschikten.

Opmerkingen - Sommige relaties worden in de praktijk niet gebruikt, meestal omdat men er een alternatief voor

heeft (zie “Normalisatie” en “Problemen opsporen”).

nooit gebruikt zelden gebruikt frequent gebruikt

- Geef elke relatie een zinvolle naam. Bekijk de relatie vanuit de “vader”. Dit is de kant met de

“maximaal 1”-kant.

Bij twijfel kies je voor de kant met “slechts één”

07-09-2001


- Denk ook eens na over de overdraagbaarheid van een relatie. We maken het duidelijk aan de

hand van een voorbeeld: o Een FACTUUR kan niet van WERKGEVER veranderen, want dan gaat het om een nieuwe

factuur. De relatie tussen FACTUUR en WERKGEVER is niet overdraagbaar o Een WERKNEMER kan wel van AFDELING veranderen, wat het blijft de zelfde werknemer,

ongeacht de afdeling waar hij voor werkt. De relatie tussen WERKNEMER en AFDELING is dus overdraagbaar

- Af en toe komt het voor dat 2 relaties elkaar uitsluiten. Zo kan bijvoorbeeld een PRODUKT niet

tegelijk door een LEVERANCIER worden geleverd én door een AFDELING worden gemaakt.

- Af en toe is het nuttig om bepaalde gegevens te partitioneren. We kunnen bijvoorbeeld een

verschil onderscheiden tussen interne en externe medewerkers. De meeste gegevens blijven dezelfde (naam, adres, …) maar een aantal gegevens verschillen. Je geeft dit als volgt weer:

De entiteit MEDEWERKER zal dan een zogenaamd classificerend attribuut hebben. Dat is een veld op basis waarvan we kunnen herkennen of het een interne of externe medewerker is. In dit geval zal dat wellicht een ja/nee-veld zijn. Binnen partitionering bestaan er 2 types:

− Volledig uitgevulde: een werknemer is OF intern OF extern, maar dat is het dan. − Niet volledig uitgevuld: een klant kan bijvoorbeeld een overheidsinstantie zijn of niet, maar

als het geen overheidsinstantie is, houden we geen specifieke gegevens bij.

Je kan ook een partitionering maken op basis van de levenscyclus. Een werknemer kan bijvoorbeeld ongehuwd, gehuwd, gescheiden, … zijn. In dit geval is het classificerend attribuut "burgerlijke staat". Als de werknemer gehuwd is, houden we de naam van de echtgenote bij.

07-09-2001


- Het is vaak nuttig om historische gegevens bij te houden.

Een medewerker zal gedurende zijn carrière af en toe van dienst veranderen. Dus als je wil weten voor welke dienst hij werkt, zal je daar een begin- en einddatum aan moeten toevoegen. Hij heeft een Veel op Veel-relatie met dienst, en op die relatie zitten gegevens (de begin- en einddatum). Je lost dit als volgt op (zie verder: “Veel op Veel-relaties waar gegevens in verborgen zitten”):

Problemen opsporen Soms ga je een ERD met de “losse pols” tekenen, eerder dan de hieronder beschreven stappen van de Normalisatie te volgen. In dat geval gebeurt moet je deze controles zeker nog eens uitvoeren:

Overtollige relaties Relaties die geen nieuwe informatie toevoegen, maar afgeleid kunnen worden uit andere zijn meestal overbodig. Je kan ze gewoon schrappen: In dit voorbeeld hoef je niet bij te houden voor welke werkgevers een werknemer werkt, want je kan dat zien aan de contracten die hij heeft:

Relaties met meerdere betekenissen Als een relatie meerdere betekenissen heeft, zoals in dit voorbeeld:

dan moet die uitgesplitst worden: het gaat eigenlijk om 2 verschillende relaties:

Je kan “bezit” ook als een speciaal type van de relatie “bestuurt” beschouwen. In dat geval valt de relatie “bezit” weg. Op de relatie “bestuurt” hou je dan bij of het om de eigenaar gaat of niet.

07-09-2001


Veel op Veel-relaties waar gegevens in verborgen zitten

Zoals we hierboven zagen, is de relatie tussen WERKNEMER en WERKGEVER bepaald door een arbeidscontract. Een arbeidscontract omvat op zich een aantal gegevens: van wanneer is het geldig, tot wanneer (of is het van onbepaalde duur), gaat het om een full-time, … Ook deze gegevens moeten worden opgeslagen, in het gegeven ARBEIDSCONTRACT:

Ook recursieve relaties gaan we vaak op deze manier uitsplitsen.

Volledig verplichte relaties Als een relatie aan beide kanten verplicht is, kan je er vaak gewoon 1 gegeven van maken:

Je kan beide tabellen gewoon samenvoegen, omdat een persoon enkel voor SD kan werken als hij bij ons een contract heeft, en een contract hoort steeds bij één persoon.

07-09-2001


Normalisatie De principes van normalisatie kunnen tijdens de gegevensanalyse plaats vinden en als laatste confirmatie van het model. Normalisatie heeft als doel herhaalde gegevens op te sporen en te verwijderen, zonder dat er informatie verloren gaat. Dit om tegen te gaan dat dezelfde gegevens op meerdere plaatsen moeten worden gewijzigd, waardoor er gemakkelijker fouten zouden kunnen ontstaan. (Normalisatie verwijdert niet alle herhaalde gegevens. Dat kan niet, omdat er dan informatie verloren zou gaan. Hieronder kan je voorbeelden daarvan terugvinden.) De normalisatieprocedure van Codd omvat de volgende stappen:

0NV: Inventariseer de gegevens, duidt herhalende groepen aan met * We inventariseren alle gegevens, in dit geval een personeelsfiche:

Personeelsnummer: 18654

Naam: Jos Vanovertwoater Adres: Everzwijnelaan 12

5533 Zweuveneuven

Looncategorie: LC99

Loongegevens:

Jaar Maand Gepresteerde uren

loon

1999 10 156 2 621 EUR 1999 11 160 2 651 EUR 1999 12 150 2 651 EUR 2000 1 163 2 156 EUR 2000 2 180 2 156 EUR 2000 3 156 2 654 EUR 2000 4 156 2 445 EUR 2000 5 156 2 445 EUR 2000 6 157 2 445 EUR

We noteren de gegevens als volgt:

WERKNEMER(personeelsnummer, naam, adres, postcode, gemeente, looncategorie, jaar*, maand*,gepresteerde uren*, loon*)

Het sterretje (*) wijst op herhaalde gegevens: per werknemer zijn er meerdere gepresteerde uren en meerdere lonen, namelijk per maand 1. We schakelen de tijd dus uit: "doorheen de tijd zijn er meerdere lonen, … per werknemer" We geven het geheel een zinvolle naam. In dit geval WERKNEMER, omdat alle gegevens horen bij een werknemer. We duiden een sleutel aan: deze identificeert de werknemer ondubbelzinnig. Hij is onderlijnd. (in het voorbeeld dus "personeelsnummer") Een sleutel kan bestaan uit 1 of meerdere attributen.

07-09-2001


1NV: splits de herhalende groepen af.

Neem alle logisch bij elkaar horende herhaalde gegevens en breng ze onder in een nieuw gegeven.

WERKNEMER(personeelsnummer, naam, adres, postcode, gemeente, looncategorie) LOON(jaar, maand, gepresteerde uren, loon)

Als we dit zomaar doen, weten we niet meer welke lonen bij welke medewerker horen. Fysisch moet je je dit zo voorstellen:

WERKNEMER

personeels-nummer naam adres postcode gemeente looncategorie

18654 Jos Vanovertwoater Everzwijnelaan 12 5533 Zweuveneuven LC99

18655 Dirk Janssens Brouwersvliet 5 2000 Antwerpen DT09

… … … … … …

LOON

Jaar Maand Gepresteerde uren Loon

1999 10 156 2 621 EUR

1999 11 160 2 621 EUR

… … … …

07-09-2001


In de tabel LOON kan je niet zien over welke werknemer het gaat! De oplossing bestaat er in dat we de sleutel van WERKNEMER mee opnemen in LOON: WERKNEMER(personeelsnummer, naam, adres, postcode, gemeente, looncategorie) LOON(personeelsnummer, jaar, maand, gepresteerde uren, loon)

LOON

Personeels-nummer Jaar Maand Gepresteerde

uren Loon

18654 1999 10 156 2 621 EUR

18654 1999 11 160 2 621 EUR

… … … … …

Maar, de nieuwe sleutel is onvolledig: per werknemer zijn er immers meerdere loongegevens. De identificatie is niet uniek: we moeten de sleutel uitbreiden tot een sleutel die uniek is per regel. WERKNEMER(personeelsnummer, naam, adres, postcode, gemeente, looncategorie) LOON(personeelsnummer, jaar, maand, gepresteerde uren, loon) Omdat er per werknemer per maand (van een bepaald jaar) exact 1 loon en 1 aantal gepresteerde uren is, is dit wel een goede sleutel. Het zou echter geen goede sleutel zijn als we personeelsnummer en bijvoorbeeld gepresteerde uren zouden nemen. Deze zijn niet uniek: de werknemer kan zowel in maart 1999 als in oktober 1999 bijvoorbeeld 850 uren presteren.

07-09-2001


2NV: splits die (niet-sleutel-)gegevens af die afhangen van een deel van de sleutel

Een gegeven X is functioneel afhankelijkheid van een gegeven Y als het onmogelijk is om 2 entiteiten te hebben met dezelfde X maar een verschillende Y. Een gegeven X moet dus altijd voorkomen samen met een gegeven Y. Werknemersnummer is functioneel afhankelijk van werknemer. Als Peeters werknemersnummer 1599 is, kan er geen andere werknemer zijn met dit nummer. Omgekeerd kan (deze) Peeters geen ander werknemersnummer hebben dan 1599.

Om dit duidelijk te maken breiden we ons voorbeeld iets uit: we voegen toe hoeveel werkdagen er in een bepaalde maand van een bepaald jaar zitten. Op het eerste zicht hoort dit bij loon, omdat daar jaar en maand al inzitten. Indien we "aantal werkdagen" reeds van in het begin hadden meegenomen, had het hier ook gestaan. WERKNEMER(personeelsnummer, naam, adres, postcode, gemeente, looncategorie) LOON(personeelsnummer, jaar, maand, gepresteerde uren, loon, aantal werkdagen) Als we goed kijken, zien we dat "aantal werkdagen" niet afhankelijk is van personeelsnummer, enkel van jaar en maand. Het moet dus niet in loon staan, maar in een apart gegeven. Dit is het doel van 3NV.

WERKNEMER(personeelsnummer, naam, adres, postcode, gemeente, looncategorie) LOON(personeelsnummer, jaar, maand, gepresteerde uren, loon) WERKDAGEN(jaar, maand, aantal werkdagen)

We nemen de sleutel "jaar, maand" over, omdat "aantal werkdagen" daar afhankelijk van is.

07-09-2001


3NV: splits die (niet-sleutel-)gegevens af die afhangen van een ander (niet-sleutel-)gegeven

We merken dat gemeente afhankelijk is van postcode1. Postcode 2000 is Antwerpen en Antwerpen (centrum) heeft als enige mogelijke postcode 2000. Deze moeten we dus opsplitsen: WERKNEMER(personeelsnummer, naam, adres, postcode, looncategorie) LOON(personeelsnummer, jaar, maand, gepresteerde uren, loon) WERKDAGEN(jaar, maand, aantal werkdagen) GEMEENTE(postcode, gemeente) Uiteraard laat je in WERKNEMER het veld postcode staan, of je weet niet meer in welke gemeente de WERKNEMER woont.

Voor de meeste databases is NV3 al goed genoeg. Maar, er zijn echter nog enkele uitzonderlijke situaties waarvoor nog extra normalisatiestappen vereist zijn. Hou ze in je achterhoofd!

BCNV: Boyce Codd NormaalVorm: als er meer dan 1 kandidaat-sleutel is (en deze overlappen), splits dit gegeven dan zo op dat er geen gegevens verloren gaan.

Een gegeven is niet in BCNV (en moet dus aangepast worden) als: ��er een meervoudige sleutel is ��er meer dan 1 kandidaatsleutel in het gegeven zit ��de sleutels elkaar overlappen. Dit wil zeggen dat ze bepaalde gegevens gemeenschappelijk

hebben.

Laten we even het volgende (schoolse) voorbeeld bekijken:

STUDIERICHTING(studentnummer, vak, coach) De tabel kan er dan zo uitzien:

STUDIERICHTING

Student-nummer Vak Coach

123 fysica Einstein

123 muziek Mozart

456 biologie Darwin

789 fysica Bohr

999 fysica Einstein

1 Ok, ik weet dat dit niet helemaal correct is, omdat er postcodes zijn die meerdere gemeenten omvatten, maar kom, laten we deze even negeren.

07-09-2001


We zien hier duidelijk een aantal gegevens herhaald worden, want: ��elke student kan meer dan 1 vak volgen ��elke student heeft per vak 1 coach ��per vak zijn er meerdere coaches mogelijk ��elke coach heeft slechts 1 vak

We zouden dus net zo goed kunnen zeggen:

STUDIERICHTING(studentnummer, vak, coach) Studierichting is dus niet BCNV, want:

��er is een meervoudige sleutel: studentnummer + vak ��er zijn meerdere kandidaatsleutels: studentnummer + vak of studentnummer + coach ��de sleutels overlappen: ze bevatten allebei studentnummer

De oplossing bestaat erin het entiteitstype op te splitsen: Een op het eerste zicht logische opsplisting is deze:

STUDIERICHTING(studentnummer, vak) COACH(coach, vak)

Dit is de FOUTE opsplitsing: de tabellen zien er als volgt uit:

STUDIERICHTING

Student-nummer Vak

123 fysica

123 muziek

456 biologie

789 fysica

999 fysica

COACH

Coach Vak

Einstein fysica

Mozart muziek

Darwin biologie

Bohr fysica

Neem studentnummer 789. Hij studeert fysica. Ga naar de tabel met coachen. Wie coacht student 789? Is het Einstein of Bohr?? Er is informatie verloren gegaan!

De volgende poging geeft deze gegevens:

STUDIERICHTING(studentnummer, coach) COACH(coach, vak)

07-09-2001


Deze eenvoudige ingreep lost veel op:

STUDIERICHTING

Student-nummer Coach

123 Einstein

123 Mozaret

456 Darwin

789 Bohr

999 Einstein

COACH

Coach Vak

Einstein fysica

Mozart muziek

Darwin biologie

Bohr fysica

Neem student 789. Hij wordt gecoached door Bohr. We zoeken in de tabel met coachen op welk vak hij geeft en dat blijkt fysica te zijn. Student 789 volgt fysica met als coach Bohr. Informatie compleet! De reden is dat een coach maar 1 vak kan geven maar een vak door meerdere coaches kan gegeven worden!

07-09-2001


4NV: Splits die sleutelgegevens af die afhangen van een ander deel van de sleutel

Stel je het volgende gegeven voor:

WERKNEMER(personeelsnummer, loon, project)

Een werknemer kan aan een bepaald aantal projecten werken. Totaal onafhankelijk hiervan kan hij een aantal lonen ontvangen. Stel dat werknemer 100 de volgende lonen heeft ontvangen: 2.000, 2.500 en 3.000 (het interesseert ons niet in welke maand). Hij heeft meegewerkt aan BLOX en VISION-X. We kunnen dit op 3 manieren weergeven:

WERKNEMER

Personeels-nummer Loon Project

100 2.000

100 2.500

100 3.000

100 BLOX

100 VISION-X

WERKNEMER


100 2.000 BLOX

100 2.500 VISION-X

100 3.000

WERKNEMER


100 2.000 BLOX

100 2.500 VISION-X

100 3.000 VISION-X

07-09-2001


De eerste tabel biedt het voordeel dat duidelijk is dat loongegevens en projectgegevens niets met elkaar te maken hebben, maar we hebben wel 5 open ruimten en 5 lijnen, wat trager is. De tweede tabel is de meest compacte: er worden geen gegevens herhaald, en er is maar 1 open ruimte. De derde tabel is handig omdat er geen lege ruimten in de database verschijnen. Dit heeft voordelen. Hoe dan ook willen we deze voordelen combineren. We gaan de tabel opsplitsen:

LOONGEGEVENS(personeelsnummer, loon) PROJECTGEGEVENS(personeelsnummer, project)

We krijgen respectievelijk:

LOONGEGEVENS

Personeels-nummer Project

100 2.000

100 2.500

100 3.000

PROJECTGEGEVENS

Personeels-nummer Project

100 BLOX

100 VISION-X

Geen null-waarden, geen herhalingen, … 4NV is bereikt !

07-09-2001


5NV: Als elk stuk van de sleutel afhankelijk is van elk ander stuk van de sleutel, splits je in zoveel stukken als er stukken sleutel zijn

Bekijk het volgende voorbeeld even:

AGENT(agent, bedrijf, product)

AGENT

Agent Bedrijf Product

Smith Ford auto

Smith Ford truck

Smith GM auto

Jones Ford auto

In deze kleine tabel zitten bepaalde gegevens dubbel: Ford maakt auto's

AGENT


Smith Ford auto

Smith Ford truck

Smith GM auto

Jones Ford auto

07-09-2001


Smith vertegenwoordigt Ford:

AGENT


Smith Ford auto

Smith Ford truck

Smith GM auto

Jones Ford auto

In dit geval zijn de 3 elementen van het entiteitstype onlosmakelijk van elkaar verbonden. Toch geeft dit entiteitstype aanleiding tot onduidelijkheden en herhalingen, ondanks het feit dat het perfect in 4NV is. De oplossing? Niet in 2 opdelen, maar in 3! Elke mogelijke combinatie van sleutels moet gemaakt worden…

BEDRIJF_PRODUCT(bedrijf, product) BEDRIJF_AGENT(bedrijf, agent) AGENT_PRODUCT(agent, product)

BEDRIJF_PRODUCT

Bedrijf Product

Ford auto

Ford truck

GM auto

BEDRIJF_AGENT

Bedrijf Agent

Smith Ford

Smith GM

Jones Ford

AGENT_PRODUCT

Agent Product

Smith auto

Smith truck

Jones auto

Persoonlijk vind ik dit riskant, en het komt erg zelden voor, maar omwille van de volledigheid heb ik het toch opgenomen.

07-09-2001


DS/NV Domein/Sleutel Normaalvorm: zorg dat iedere randvoorwaarde bij de entiteit een logisch gevolg is van de definitie van de sleutels en de mogelijke waarden

Randvoorwaarden zijn bijvoorbeeld: ��de klantnummer moet tussen 1 en 5000 liggen ��de naam mag geen getallen bevatten ��een klant kan niet meer dan 5 bestellingen tegelijk lopende hebben ��…

Een randvoorwaarde is dus elke bedrijfs- of andere regel die een beperking oplegt wat betreft de toegelaten waarden, beperkingen binnen een relatie, …. Tijdsvoorwaarden worden niet als randvoorwaarde gezien. Bijvoorbeeld "Het salaris van de huidige periode moet hoger zijn dan dat van de vorige periode" is tijdsgebonden en wordt dus niet als randvoorwaarde geteld. Het domein van een gegeven is de verzameling van zijn mogelijke waarden. Een klantnummer kan bijvoorbeeld als domein de verzameling 1, 2, 3, 4, … hebben. Helaas is tot op heden nog geen formele methode gevonden om een entiteit in DS/NV te zetten. Het komt er dus op aan de domeinen en sleutels zo te kiezen dat aan alle randvoorwaarden wordt voldaan.

Voorbeeld:

WERKNEMER(Werknemernummer, type contract, tewerkstellingsplaats, loon) Een student heeft een nummer, volgt een bepaalde studie, woont in een studentenhuis en betaalt daarvoor een bepaalde huur. Sleutel:

Werknemernummer Randvoorwaarden:

als de werknemer geen contract heeft, krijgt hij ook geen loon de tewerkstellingsplaats mag niet met een 1 beginnen. Domeinen: Werknemernummer: een getal van 5 decimalen waarvan het eerste verschilt van 1 Type contract: PR, F1, F2 of PD Tewerkstellingsplaats: 4 karakters Loon: 4 decimalen Het feit dat de werknemer een contract moet hebben eer hij loon is niet afleidbaar uit de gegevens: het kan niet in de domeinbeschrijving worden opgenomen. We gaan de entiteit opsplitsen:

WERKNEMER(Werknemernummer, type contract, tewerkstellingplaats) CONTRACT(type contract, loon)

Waarom is “type contract” de sleutel? Het loon is afhankelijk van het type contract, en niet omgekeerd. Natuurlijk klopt dit niet helemaal: het loon is waarschijnlijk afhankelijk van een specifiek contract, en niet van het type contract, maar goed, het gaat om het principe, niet?

07-09-2001


Samenvatting

0NV Inventariseer de gegevens, duidt herhalende groepen aan met *

1NV Splits de herhalende groepen af.

2NV Splits die (niet-sleutel-)gegevens af die afhangen van een deel van de sleutel

3NV Splits die (niet-sleutel-)gegevens af die afhangen van een ander (niet-sleutel-) gegeven

BCNV Als er meer dan 1 kandidaat-sleutel is (en deze overlappen), splits dit gegeven dan zo op dat er geen gegevens verloren gaan.

4NV Splits die sleutelgegevens af die afhangen van een ander deel van de sleutel.

5NV Als elk stuk van de sleutel afhankelijk is van elk ander stuk van de sleutel, splits je in zoveel stukken als er stukken sleutel zijn.

DS/NV Zorg dat iedere randvoorwaarde bij de entiteit een logisch gevolg is van de definitie van de sleutels en de mogelijke waarden.

Denormalisatie Tevreden over je werk? Fijn zo! Maar misschien is het nu nodig te denormaliseren. Wacht 'ns? Eerst normaliseren en dan denormaliseren??? Tja, wat wil je? We hebben de gegevens zo geanalyseerd dat we zo min mogelijk herhalingen hebben. Zo min mogelijk herhalingen leidt tot een zo klein mogelijke database, maar niet tot een zo snel mogelijke database !!! Om de vereiste snelheid te behalen zal het soms nodig zijn sommige entiteiten toch terug samen te nemen… Dit is het werk van database-specialisten, dus daar gaan we hier niet verder op in.

Een ERD tekenen Eens de normalisatie gedaan is, kan je gemakkelijk een ERD tekenen. Even terug naar het oorspronkelijke voorbeeld: WERKNEMER(personeelsnummer, naam, adres, postcode, looncategorie) LOON(personeelsnummer, jaar, maand, gepresteerde uren, loon) GEMEENTE(postcode, gemeente) WERKDAGEN(jaar, maand, aantal werkdagen)

07-09-2001


Hoe weet je waar de relaties tussen moeten liggen? Simpel: neem de sleutel van elk gegeven en zoek deze in een ander gegeven. De sleutel van GEMEENTE is postcode. We vinden deze postcode terug in WERKNEMER. Er ligt dus een relatie tussen gemeente en werknemer. Omdat postcode de sleutel is van GEMEENTE, kan er nooit meer dan 1 gemeente zijn met dezelfde postcode. Er kunnen echter wel meerdere werknemers zijn die in dezelfde gemeente wonen.

��een werknemer woont per definitie in een gemeente: 1 en slechts 1 gemeente ��een gemeente kan 0, één of meerdere werknemers van ons huisvesten.

Zo vinden we ook het personeelsnummer (van WERKNEMER) terug in (een deel van de sleutel) van LOON en we vinden de sleutel van WERKDAGEN (jaar en maand) terug, eveneens in de sleutel van LOON.

Visio

Vooraf Voor je begint moet je de beide bestanden “ERD.vst” en “ERD.vss” kopiëren naar de juiste directory. Deze bestanden bevatten de relaties al voorgedefinieerd: dit kan je heel wat werk besparen. - Controleer het pad via Bestand/Opties:

07-09-2001


- Kijk op het tabblad “File Paths”…

- … naar de directory ingevuld bij “Templates”

07-09-2001


- en kopieer de bestanden naar deze directory

Praktische aanpak

De basisstructuur - Start Visio 2002 op - Kies voor Software, ERD:

Gegevens - Daarna sleep je een “entity” (gegeven) …

07-09-2001


- … naar het werkblad

- Druk op F2 (of begin gewoon te typen) om de naam van het gegeven in te vullen

Partitioneren (zie opmerkingen) - Teken het gegeven dat je zal partitioneren, en geef het een naam

- De tekst zal niet in het midden, maar bovenaan moeten staan. Dit doe je als volgt:

07-09-2001


- Kies het tabblad “Text Block”

- Stel “Vertical” in op “Top”

07-09-2001


- Stel ook Margins/Top in op “2 pt”

- klik op “OK”

- Zet de onderliggende gegevens op het scherm:

- Selecteer het bovenliggende gegeven:

- Sleep het groene blokje onderaan in het midden naar beneden, tot het gegeven groot genoeg is:

07-09-2001


- Herhaal dit voor het blokje rechts opzij:

- Selecteer de volledige groep:

- Klik rechts en kies “Shape”, “Group”

Dit heeft als voordeel dat je de groep als geheel kan verplaatsen, terwijl je toch aan elk gegeven een relatie kan hangen.

Relaties - de relatie tussen 2 gegevens toe te voegen, sleep je de juiste relatie uit de lijst links naar het

werkblad:

07-09-2001


- Uiteraard gaan we de pijlpunten nog aan de gegevens koppelen:

- Selecteer de relatie

- Sleep een uiteinde naar het bijhorende gegeven. Je zal merken dat het uiteinde rood wordt op sommige punten van het gegeven

- Herhaal voor de andere kant:

- en zet er een beschrijving op (F2 of gewoon beginnen typen):

Relaties wijzigen - Soms merk je achteraf dat je een verkeerde relatie hebt genomen. Je moet dan niet

herbeginnen, want je kan de bestaande aanpassen: klik rechts op de relatie en kies “Format”, “Line”

07-09-2001


- Kies het juiste symbool voor “Begin” en “End”

- Merk op dat we slechts enkele van de vele uiteinden gebruiken:

Nummer Symbool

24

31

28

29

Automatisch schikken - Je kan Visio je model automatisch laten schikken als volgt: als je model klaar is ziet het er

waarschijnlijk ongeveer zo uit:

07-09-2001


- Kies in het menu “Shape” voor “Lay Out Shapes”

- Kies “Flowchart/Tree”

- klik op OK. Je model ziet er nu al iets beter uit, maar sommige relaties kruisen elkaar, wat de duidelijkheid niet ten goede komt:

07-09-2001


- Selecteer een van de kruisende relaties

- Neem het rode vierkantje en versleep het langs de rand van het gegeven:

- Als je een rood vierkantje krijgt, kan je de relatie terug loslaten:

07-09-2001


- Herhaal voor de andere relatie:

- Het model is klaar:

Afdrukken Met Visio is het mogelijk om een zelfde model:

- af te drukken op een A4-blad (de standaardinstelling) - als poster af te drukken op bijvoorbeeld 2 x 2 bladen (die je dan wel zelf aan elkaar moet

kleven)

07-09-2001


Dit laatste doe je als volgt:

- kies “File”, “Page Setup”

- Vul bij “Print Zoom” “Fit to” 2 across en 2 down in:

- print zoals gewoonlijk

07-09-2001


Uitgewerkt Voorbeeld:

handleiding gegevensdiagrammen

Documents