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
Handleiding Gegevensdiagrammen Laatst opgeslagen door Tom Vercauteren 1/34

07-09-2001

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 verplicht n, nooit meer, nooit minder nul of n, maar nooit meer dan n n of meer nul, n of meerdere Voorbeeld Een loonperiode hoort steeds bij 1 en slechts 1 werknemer Een werkgever kan een boekhouder hebben, maar nooit meer dan n. Een werkgever heeft n of meer werknemers (als hij er geen heeft, is het geen werkgever, maar een zelfstandige zonder personeel) Een werkgever heeft van SD nul, n of meerdere facturen gekregen sinds zijn aansluiting.

Handleiding Gegevensdiagrammen

2/34

07-09-2001

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

Voorbeelden Volledige relaties tussen gegevens zien er dan zo uit:

n n n

Entiteit WERKGEVER

Omschrijving Relatie is aangesloten bij

Aantallen (symbool) nul of n nul, n of meerdere

Entiteit BOEKHOUDERS WERKGEVERS

BOEKHOUDER heeft als klanten

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 n n

Entiteit AFDELING PROJECT

Omschrijving Relatie financieert maakt deel uit van

Aantallen (symbool) nul, n of meerdere n of meerdere

Entiteit PROJECTEN AFDELINGEN

Handleiding Gegevensdiagrammen

3/34

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 hirarchische groepering van dit gegeven. Een organigram kan je bijvoorbeeld zo weergeven:

n n n

Entiteit PERSOON PERSOON

Omschrijving Relatie heeft onder zich heeft als leidinggevende

Aantallen (symbool) nul, n of meerdere nul of n

Entiteit PERSONEN 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

Handleiding Gegevensdiagrammen

4/34

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. verschil onderscheiden tussen interne en externe medewerkers. dezelfde (naam, adres, ) maar een aantal gegevens verschillen. Je geeft dit als volgt weer:

We kunnen bijvoorbeeld een De meeste gegevens blijven

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.

Handleiding Gegevensdiagrammen

5/34

07-09-2001

Het is vaak nuttig om historische gegevens bij te houden. Een medewerker zal gedurende zijn carrire 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.

Handleiding Gegevensdiagrammen

6/34

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.

Handleiding Gegevensdiagrammen

7/34

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 *

Personeelsnummer: Naam: Adres:

We inventariseren alle gegevens, in dit geval een personeelsfiche: 18654 Jos Vanovertwoater Everzwijnelaan 12 5533 Zweuveneuven LC99

Looncategorie: Loongegevens: Jaar 1999 1999 1999 2000 2000 2000 2000 2000 2000 Maand 10 11 12 1 2 3 4 5 6 Gepresteerde uren 156 160 150 163 180 156 156 156 157

loon 2 621 EUR 2 651 EUR 2 651 EUR 2 156 EUR 2 156 EUR 2 654 EUR 2 445 EUR 2 445 EUR 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. Handleiding Gegevensdiagrammen 8/34

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 personeelsnaam nummer 18654 18655 Jos Vanovertwoater Dirk Janssens adres Everzwijnelaan 12 Brouwersvliet 5 postcode gemeente 5533 2000 looncategorie

Zweuveneuven LC99 Antwerpen DT09

LOON Jaar 1999 1999 Maand 10 11 Gepresteerde uren 156 160 Loon 2 621 EUR 2 621 EUR

Handleiding Gegevensdiagrammen

9/34

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 PersoneelsJaar nummer 18654 18654 1999 1999 Maand 10 11 Gepresteerde uren 156 160 Loon 2 621 EUR 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.

Handleiding Gegevensdiagrammen

10/34

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.

Handleiding Gegevensdiagrammen

11/34

07-09-2001

3NV:

splits die (niet-sleutel-)gegevens af die afhangen van een ander (nietsleutel-)gegeven

1

We merken dat gemeente afhankelijk is van postcode . 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 StudentVak nummer 123 123 456 789 999 fysica muziek biologie fysica fysica Coach Einstein Mozart Darwin Bohr Einstein

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

Handleiding Gegevensdiagrammen

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 StudentVak nummer 123 123 456 789 999 fysica muziek biologie fysica fysica COACH Coach Einstein Mozart Darwin Bohr Vak fysica muziek biologie 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)

Handleiding Gegevensdiagrammen

13/34

07-09-2001

Deze eenvoudige ingreep lost veel op: STUDIERICHTING StudentCoach nummer 123 123 456 789 999 Einstein Mozaret Darwin Bohr Einstein COACH Coach Einstein Mozart Darwin Bohr Vak fysica muziek biologie 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!

Handleiding Gegevensdiagrammen

14/34

07-09-2001

4NV:

Splits die sleutelgegevens af die afhangen van een ander deel van de sleutel
WERKNEMER(personeelsnummer, loon, project)

Stel je het volgende gegeven voor:

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 PersoneelsLoon nummer 100 100 100 100 100 2.000 2.500 3.000 BLOX VISION-X Project

WERKNEMER PersoneelsLoon nummer 100 100 100 2.000 2.500 3.000 Project BLOX VISION-X

WERKNEMER PersoneelsLoon nummer 100 100 100 2.000 2.500 3.000 Project BLOX VISION-X VISION-X 15/34

Handleiding Gegevensdiagrammen

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 PersoneelsProject nummer 100 100 100 2.000 2.500 3.000

PROJECTGEGEVENS PersoneelsProject nummer 100 100 BLOX VISION-X

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

Handleiding Gegevensdiagrammen

16/34

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
AGENT(agent, bedrijf, product) AGENT

Bekijk het volgende voorbeeld even:

Agent Smith Smith Smith Jones

Bedrijf Ford Ford GM Ford

Product auto truck auto auto

In deze kleine tabel zitten bepaalde gegevens dubbel: Ford maakt auto's AGENT Agent Smith Smith Smith Jones Bedrijf Ford Ford GM Ford Product auto truck auto auto

Handleiding Gegevensdiagrammen

17/34

07-09-2001

Smith vertegenwoordigt Ford: AGENT Agent Smith Smith Smith Jones Bedrijf Ford Ford GM Ford Product auto truck auto 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 Ford Ford GM Product auto truck auto BEDRIJF_AGENT Bedrijf Smith Smith Jones Agent Ford GM Ford AGENT_PRODUCT Agent Smith Smith Jones Product auto truck auto

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

Handleiding Gegevensdiagrammen

18/34

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? omgekeerd. Het loon is afhankelijk van het type contract, en niet

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?

Handleiding Gegevensdiagrammen

19/34

07-09-2001

Samenvatting
0NV 1NV 2NV 3NV BCNV 4NV 5NV DS/NV Inventariseer de gegevens, duidt herhalende groepen aan met * Splits de herhalende groepen af. Splits die (niet-sleutel-)gegevens af die afhangen van een deel van de sleutel Splits die (niet-sleutel-)gegevens af die afhangen van een ander (niet-sleutel-) gegeven Als er meer dan 1 kandidaat-sleutel is (en deze overlappen), splits dit gegeven dan zo op dat er geen gegevens verloren gaan. Splits die sleutelgegevens af die afhangen van een ander deel van de sleutel. 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. 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)

Handleiding Gegevensdiagrammen

20/34

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 kopiren naar de juiste directory. Deze bestanden bevatten de relaties al voorgedefinieerd: dit kan je heel wat werk besparen. Controleer het pad via Bestand/Opties:

Handleiding Gegevensdiagrammen

21/34

07-09-2001

Kijk op het tabblad File Paths

naar de directory ingevuld bij Templates

Handleiding Gegevensdiagrammen

22/34

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)

Handleiding Gegevensdiagrammen

23/34

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:

Handleiding Gegevensdiagrammen

24/34

07-09-2001

Kies het tabblad Text Block

Stel Vertical in op Top

Handleiding Gegevensdiagrammen

25/34

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:

Handleiding Gegevensdiagrammen

26/34

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:

Handleiding Gegevensdiagrammen

27/34

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

Handleiding Gegevensdiagrammen

28/34

07-09-2001

Kies het juiste symbool voor Begin en End

Merk op dat we slechts enkele van de vele uiteinden gebruiken: Nummer 24 31 28 29 Symbool

Automatisch schikken Je kan Visio je model automatisch laten schikken als volgt: als je model klaar is ziet het er waarschijnlijk ongeveer zo uit:

Handleiding Gegevensdiagrammen

29/34

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:

Handleiding Gegevensdiagrammen

30/34

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:

Handleiding Gegevensdiagrammen

31/34

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)

Handleiding Gegevensdiagrammen

32/34

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

Handleiding Gegevensdiagrammen

33/34

07-09-2001

Uitgewerkt Voorbeeld:

Handleiding Gegevensdiagrammen

34/34