Datamodellering en –verwerking8C020
college 3
Extra uren (7 en 8) op maandag, 22 oktober, in Auditorium 5
Terugblik college week 2
• Aspecten van modelleren– Meerwaardige atribuut-type– Herhalende groep– Tijdsafhankelijke gegevens
• Classificeren
• ISA relatie
• Constraints (Beperkingen)
• UML
• Oefening E-R modeleren: Ziekenhuis
Onderwerpen college week 3
• Relationeel Model
• Transformatie van ERM naar Relationeel Model
• Opdracht
Software Life Cycle/Fasering
analyseren
eisen
specificeren
ontwerpen
coderen
testen
invoeren
onderhouden
Omgevings anlyse, ontwikkelingsplan (kosten en tijd)
Eisen, planning en begroting, haalbarheidsanalyse
Conceptueel model
Iplementatiemodel, handleidigen, testmodel
Code, onderhoudshandeling
tesrapporten
Installatie, acceptierapport
Correctief, preventief, modificatief
Functie van databasemodel
• een volledig conceptueel model geeft een abstracte beschrijving van het te bouwen informatiesysteem
• datamodel – beschrijft de relevante gegevens
• databasemodel – beschrijft de relevante gegevens passend bij de te gebruiken
databasesoftware
• het databasemodel specificeert dus hoe de informatie concreet wordt ondergebracht in een database
Relationeel model
• een databasemodel hangt af van het te gebruiken DBMS
• in dit college richten wij ons op relationele databases
• het begrip Relationeel Model (de relationele aanpak) duidt eigenschappen en randvoorwaarden aan voor het maken van databasemodellen voor relationele databases
• naam afgeleid van het belangrijkste concept: relatie
• relationeel (database)model – een databasemodel voor relationele databases
Waarschuwing
• in het Nederlands kan verwarring ontstaan door dubbel gebruik van het woord relatie
in ER-model: relationship
in Relationeel Model: relation
Transformatie
• een databasemodel is een uitbreiding van een datamodel
• wij willen dus een relationeel databasemodel maken op basis van een ER-model
• behoefte aan een transformatie van een ER-model naar een (relationeel) databasemodel
• stapsgewijze transformatie:
1. representatie van entiteiten
2. representatie van relaties
3. normalisatie
4. samennemen van relaties
Relationele aanpak
• Relationeel Model – geïntroduceerd in 1970 door Edgar F. Codd
• Turing Award 1981• ook bijdrage in het gebied van cellulaire automaten, “self-
reproducing automata”
• de relationele aanpak wordt nu beschouwd als de standaard
• gegevens worden geordend in de vorm van relaties
• relaties worden gerepresenteerd in de vorm van tabellen
• de aanpak is gebaseerd op een wiskundige theorie: dit geeft een solide theoretische onderbouwing en vele praktische voordelen
Drie componenten
• datastructuren– gegevens zijn georganiseerd in de vorm van tabellen
(relaties)
• datamanipulatie– krachtige operaties om de opgeslagen gegevens te
manipuleren
• data-integriteit– faciliteiten voor het specificeren van (het behouden van) de
integriteit
Relatie
• een relatie is te beschouwen als een twee-dimensionale tabel met gegevens
• elke relatie heeft een – naam, – bestaat uit
• een verzameling van kolommen (elk voorzien van een naam) en uit
• een willekeurig aantal rijen
• elke kolom correspondeert met een attribuut van de relatie
• elke rij correspondeert met een record (instantie, entiteit)
Voorbeeld
WN1WNID NAAM AFD SALARIS100 Anna Bruinsma Verkoop 50.000140 Carla Dik Administratie 41.000110 Eef Groen Informatiesystemen 49.000
190 Henk Israël Inkoop 39.500150 Janny Kramer Verkoop 45.000
Afkorting van de structuur van die relatie:
WN1(WNID, NAAM, AFD, SALARIS)
Atomaire waarden
WN2a
WNID NAAM AFD SALARIS CURSUS DATUM
100 Anna Bruinsma
Verkoop 50.000 PRWord
6-6-941-12-94
140 Carla Dik Administratie 41.000 Belastingen 25-8-94
110 Eef Groen Informatiesystemen 49.000 C++Word
13-11-941-12-94
190 Henk Israël Inkoop 39.500 Logistiek 8-3-94
150 Janny Kramer Verkoop 45.000 PRWorkflow
6-6-9411-12-94
De waarden in de kolommen moeten atomair (ondeelbaar) zijn
Atomaire waarden
WN2
WNID NAAM AFD SALARIS CURSUS DATUM
100 Anna Bruinsma Verkoop 50.000 PR 6-6-94
100 Anna Bruinsma Verkoop 50.000 Word 1-12-94
140 Carla Dik Administratie 41.000 Belastingen 25-8-94
110 Eef Groen Informatiesystemen 49.000 C++ 13-11-94
110 Eef Groen Informatiesystemen 49.000 Word 1-12-94
190 Henk Israël Inkoop 39.500 Logistiek 8-3-94
150 Janny Kramer Verkoop 45.000 PR 6-6-94
150 Janny Kramer Verkoop 45.000 Workflow 11-12-94
Domain
• bij elke kolom hoort een collectie van waarden die mogen voorkomen in de kolom (als waarden voor dat attribuut)
• zo'n collectie van waarden heet een domein
• Voorbeeld:– bij WNID hoort een domein van identificatienummers
– bij DATUM hoort een domein van examendata
Unieke rijen
• elke rij is uniek:– dit drukt uit dat records (instanties) uniek zijn– deze eigenschap wordt gegarandeerd door het aanwijzen van
een primaire sleutel (uit de verzameling kandidaat-sleutels)
• WN1: WNID of NAAM
• WN2: WNID,CURSUS of NAAM,CURSUS
• de waarden van de primaire sleutel mogen niet null zijn
Volgorde irrelevant
• de volgorde van kolommen is irrelevant: het maakt niet uit in welke volgorde de attributen worden vermeld– in de relationele aanpak wordt dit bereikt door te kiezen voor
een verzameling van kolommen
• de volgorde van rijen is irrelevant: het maakt niet uit in welke volgorde de records worden vermeld– in de relationele aanpak wordt dit bereikt door te kiezen voor
een verzameling van records
Goed gestructureerd
• bij het ontwerpen van relaties streef je naar – een minimum aan redundantie en – de situatie dat gebruikers rijen kunnen
• toevoegen, • veranderen, of • wegnemen
zonder dat er fouten ontstaan
Een niet goed gestructureerde relatie
WN2
WNID NAAM AFD SALARIS CURSUS DATUM
100 Anna Bruinsma Verkoop 50.000 PR 6-6-94
100 Anna Bruinsma Verkoop 50.000 Word 1-12-94
140 Carla Dik Administratie 41.000 Belastingen 25-8-94
110 Eef Groen Informatiesystemen 49.000 C++ 13-11-94
110 Eef Groen Informatiesystemen 49.000 Word 1-12-94
190 Henk Israël Inkoop 39.500 Logistiek 8-3-94
150 Janny Kramer Verkoop 45.000 PR 6-6-94
150 Janny Kramer Verkoop 45.000 Workflow 11-12-94
Anomalieën
• anomalie van toevoegen– nieuwe werknemer toevoegen
• een waarde voor beide cursus en wind moet er ingevoerd worden
– werknemer zonder cursus?
• anomalie van verwijderen– verwijderen gegevens werknemer
• als werknemer 140 wordt verwijderd zijn we de informatie kwijt dat er op 25-8-94 iemand een cursus heeft afgerond
• anomalie van wijzigen– veranderen van salaris
• moet in elk van de rijen voor de weknemer gebeuren– niet efficient
Normalisatie
• Probleem– WN2 bevat gegevens over twee entiteiten
• Oplossing – Verdeel zo’n relatie in twee relaties: WN1 en WN-CURSUS
Normalisatie
WN1WNID NAAM AFD SALARIS100 Anna Bruinsma Verkoop 50.000140 Carla Dik Administratie 41.000110 Eef Groen Informatiesystemen 49.000
190 Henk Israël Inkoop 39.500150 Janny Kramer Verkoop 45.000
WN-CURSUS
WNID CURSUS DATUM
100 PR 6-6-94
100 Word 1-12-94
140 Belastingen 25-8-94
110 C++ 13-11-94
110 Word 1-12-94
190 Logistiek 8-3-94
150 PR 6-6-94
150 Workflow 11-12-94
Transformatie van ERM naar Relationeel Model
• als we een relationeel databasemodel ontwerpen willen we het beschikbare datamodel gebruiken
• het transformeren van het datamodel naar een databasemodel is één van de belangrijkste stappen in de ontwikkeling
• (deel van) transformatiemethode:
1. het representeren van entiteiten
2. het representeren van relaties
Representatie entiteiten
• Drie stappen:
1. elk entiteit-type wordt vertaald in een relatie
2. de primaire sleutel van het entiteit-type wordt de primaire sleutel van de relatie
3. elk niet-sleutel attribuut-type van het entiteit-type wordt een (niet-sleutel) attribuut van de relatie
• er volgen mogelijk nog veranderingen als het entiteit-type betrokken is in (ER)relatie-typen
Voorbeeld
KLANT
NAAM
KLANTNUMMER
ADRES WOONPLAATS
KORTING
KLANT(KLANTNUMMER, NAAM, ADRES, WOONPLAATS, KORTING)
KLANT
KLANTNUMMER NAAM ADRES WOONPLAATS KORTING
1273 Super Spullen Markt 1 Eindhoven 10%
6333 Audiogigant Markt 3 Eindhoven 2%
ER:
RM:
Representatie relaties
• onderscheid tussen soorten relatie-typen:– binaire één-op-veel relatie-typen– binaire veel-op-veel relatie-typen– unaire één-op-veel relatie-typen– unaire veel-op-veel relatie-typen– ISA-relatie-typen
Voorbeeld binaire 1-op-veel relatie
ORDER
ORDERDATUM ORDERNUMMER LEVERDATUM
KLANT
Plaatst
NAAM
KLANTNUMMER
ADRES
WOONPLAATS
KORTING
KLANT(KLANTNUMMER, NAAM, WOONPLAATS, KORTING, ADRES)
ORDER(ORDERNUMMER, ORDERDATUM, LEVERDATUM)
PLAATST(KLANTNUMMER, ORDERNUMMER)
Voorbeeld
ORDER
ORDERDATUMORDERNUMMER LEVERDATUM
KLANT
Plaatst
NAAM
KLANTNUMMER
ADRES
WOONPLAATS
KORTING
KLANT(KLANTNUMMER, NAAM, ADRES, WOONPLAATS, KORTING)ORDER(ORDERNUMMER, ORDERDATUM, LEVERDATUM, KLANTNUMMER)
Voorbeeld
KLANT
KLANTNUMMER NAAM ADRES WOONPLAATS KORTING
1273 Super Spullen Markt 1 Eindhoven 10%
6333 Audiogigant Markt 3 Eindhoven 2%
ORDER
ORDERNUMMER ORDERDATUM LEVERDATUM KLANTNUMMER
57194 15-3-94 28-3-94 6333
63725 17-3-94 1-4-94 1273
80149 14-3-94 24-3-94 6333
Binair één-op-veel relatie-type
• stel het datamodel bevat een binair één-op-veel relatie-type tussen A en B
• dit relatie-type wordt gerepresenteerd door het toevoegen van het primaire sleutel attribuut (of attributen) van A als attribuut van B
• zo'n niet-sleutel attribuut (ergens anders wel sleutel) heet een vreemde sleutel (foreign key)
Voorbeeld binair veel-op-veel relatie-type
ORDER
ORDERDATUMORDERNUMMER LEVERDATUM
PRODUKT
Betreft HOEVEELHEID
PRODUKTNUMMER
KLANTNUMMER
BESCHRIJVING
Voorbeeld binair veel-op-veel relatie-type
ORDER
ORDERNUMMER ORDERDATUM LEVERDATUM KLANTNUMMER
57194 15-3-94 28-3-94 6333
63725 17-3-94 1-4-94 1273
80149 14-3-94 24-3-94 6333
PRODUKT
PRODUKTNUMMER BESCHRIJVING
M128 Boekenkast
A261 Wandmeubel
R149 Kastje
ORDERREGEL
ORDERNUMMER PRODUKTNUMMER HOEVEELHEID
57194 M128 2
57194 A261 1
Binair veel-op-veel relatie-type
• stel het datamodel bevat een binair veel-op-veel relatie-type tussen A en B
1. er wordt een nieuwe relatie C (tabel) gevormd
2. de primaire sleutel van C is een combinatie van die van A en B
3. eventuele attribuut-typen (van het relatie-type) worden niet-sleutel attributen van C
Voorbeeld unair één-op-veel relatie-type
WERKNEMER
NAAMWNID GEBOORTEDATUM
Geeft-leiding- aan
WERKNEMER(WNID, NAAM, GEBOORTEDATUM, MANAGER-ID)
Unair één-op-veel relatie-type
• stel het datamodel bevat een unair één-op-veel relatie-type met betrekking tot A
1. A wordt al gerepresenteerd via een relatie (tabel)
2. om het ER-relatie-type uit te drukken voegen we een attribuut (of attributen) toe aan de relatie (tabel) dat refereert naar de primaire sleutel
Voorbeeld unair veel-op-veel relatie-type
PRODUKT
NAAMPRODUKTNUMMER PRIJS
BevatAANTAL
PRODUKT(PRODUKTNUMMER, NAAM, PRIJS)BEVAT(PRODUKTNUMMER, ONDERDEELNUMMER, AANTAL)
Unair veel-op-veel relatie-type
• stel het datamodel bevat een unair veel-op-veel relatie-type met betrekking tot A
• A wordt al gerepresenteerd via een relatie (tabel)
• er wordt een nieuwe relatie B gevormd voor het ER-relatie-type– de primaire sleutel van B is een combinatie van tweemaal de
primaire sleutel van A – eventuele attribuut-typen van het ER-relatie-type worden niet-
sleutel attributen van B
Voorbeeld ISA-relatie-type
STRANDHUIS
ADRES
SKI?
CHALET
AFSTAND-TOT-ZEE
VAKANTIEHUISADRES HUUR
PLAATS AANTAL-KAMERS
ISA ISA
PLAATS ADRES PLAATS
VAKANTIEHUIS(ADRES, PLAATS, AANTAL-KAMERS, HUUR)STRANDHUIS(ADRES, PLAATS, AFSTAND-TOT-ZEE)CHALET(ADRES, PLAATS, SKI?)
ISA-relatie-type
• stel het datamodel bevat een ISA-relatie-type
• er is al een relatie voor elke betrokken (sub)klasse
• de tabel voor de superklasse heeft slechts die attributen die alle (sub)klassen gemeenschappelijk hebben
• de tabel van een subklasse heeft behalve de primaire sleutel slechts die attributen specifiek voor de subklasse