Upload
fien-bakker
View
215
Download
0
Tags:
Embed Size (px)
Citation preview
Opleiding AIcursus Databases
Tweede college
Donderdag 17 februari 2004
Drs. F. de Vries
Database ontwerp & normalisatie
Rolland, “The Essence of Databases”,
Hoofdstuk 4
Database ontwerp
Ontwerp van een conceptueel database schema
Top-down benadering.– E/R model stapsgewijs transformeren naar
database schema.
Bottum-up benadering.– Normalisatie van gegevensbestanden naar een
efficiënte structuur.
Van E/R model naar database schema
Creëer een E/R model.
Transformeer in 8 stappen naar een verzameling relaties met specificatie van attributen, domeinen en sleutels.
Controleer op “normalisatie”.
Stap1: sterke entiteiten
Voor elke sterke entiteit:
Maak een ‘base-relation’ met de naam van die entiteit,
Maak een kolom voor elk (eenvoudig) attribuut,
Het sleutelattribuut van de entiteit wordt de primaire sleutel van de tabel.
E/R model: (sterke) entiteiten
Stap 2: zwakke entiteiten
Voor elke zwakke entiteit: Maak een ‘base-relation’ met de naam van die
entiteit, Maak een kolom voor elk (eenvoudig) attribuut, Voeg – als verwijssleutel(s) – de(het)
sleutelattribu(u)t(en) toe van de entiteit(en) waarvan deze zwakke entiteit afhangt,
De primaire sleutel wordt de verzameling van deze verwijssleutels.
E/R model : zwakke entiteit
Stap 3: 1-M relaties
Voor elke 1-M relatie: Voeg in de M-relatie een extra kolom toe die
– als verwijssleutel – het verband representeert.
Gebruik de naam van het verband als kolomnaam.
Het domein van deze kolom (de verwijssleutel-waarden) moet zijn: de verzameling van primaire sleutelwaarden uit de tabel waarnaar verwezen wordt.
E/R model: 1:M relatie
Stap 4: 1-1 relaties
Voor elke 1-1 relatie: Maak een kolom in één relatie (en ook echt maar
in één!) die de verwijzing representeert.– Aan beide zijden leidt tot dataredundantie !!!
Deze kolom bevat een verwijssleutel naar de relatie waarmee het verband bestaat.
Bij voorkeur verwijssleutel opnemen in de entiteit met de (meest) volledige deelname,– Voorkomt een overdaad aan NULLs.
Gebruik de naam van het verband als kolomnaam.
x
Stap 5: M-N relaties
Voor elke M-N relatie: Maak een nieuwe tabel die het verband
representeert. Voeg als kolommen verwijssleutels toe naar
de bijbehorende relaties. De primaire sleutel wordt de verzameling van
deze verwijssleutels. Voeg eventuele attributen van het verband
toe als kolommen aan deze tabel.
E/R model : M:N relatie
Stap 6a: Multi-valued attributen
Voor elk multi-valued attribuut: Maak een ‘base-relation’ met de naam van
het verband. Voeg verwijssleutel naar de bijbehorende
entiteit toe. Maak een kolom voor het attribuut. De primaire sleutel bestaat uit de combinatie
van verwijssleutel en attribuut.
Stap 6b: Samengestelde attributen
Voor elk samengesteld attribuut: Maak, in plaats van een kolom met de
naam van het samengestelde attribuut, een stel kolommen met namen van de samenstellende attribuut-delen.
Stap 7: n-ary relations
Voor elke n-ary relation: Maak een ‘base-relation’ met de naam van het
verband. Voeg verwijssleutels toe naar de bijbehorende
relaties. De primaire sleutel wordt de verzameling van deze
verwijssleutels. Voeg eventuele attributen van het verband toe als
kolommen aan deze tabel. N.B.: Dit kan eenvoudiger als er 1-1 of 1-M
verbanden bestaan!
x
Stap 8: Subtype relaties
Voor elke sub-type relatie:Als het subtype een subset is met een specifieke
attribuutwaarde:– Gebruik een view.
Als het subtype nieuwe attributen heeft: Maak een nieuwe ‘base-relation’ voor het sub-type. Voeg een verwijssleutel toe naar het supertype van
deze relatie. Dit is tevens de primaire sleutel van deze relatie.
Voeg kolommen toe met de attributen van dit sub-type
E-E/R model: subtyping
Par 4.2 Normalisatie
Doel normalisatie
Ontwikkelen van een verzameling van relationele tabellen met “wenselijke eigenschappen” gegeven de betekenis van de gegevens in de organisatie.
Meestal uitgevoerd als een serie tests op een relationele tabel.
Belangrijk doel bij ontwerp van een relationele database is het minimaliseren van redundantie in de gegevens.
Normalisatie bewerkstelligt dit. Redundantie leidt tot:
– onderhoudsproblemen (update anomalies).– verspilling van opslag capaciteit.
Normalisatie onderwerpen
Doel van normaliseren.– problemen bij tabellen in niet-normaalvorm.
Het begrip “Functionele afhankelijkheid”. Het normalisatie-proces. 1e normaalvorm (1NF), 2e normaalvorm
(2NF), 3e normaalvorm (3NF) en de Boyce-Codd normaalvorm (BCNF),(4e normaalvorm (4NF) en 5e normaalvorm
(5NF).)
ER modellering Normalisatie
ER modellering: top-down benadering.
Normalisatie:– meer bottum-up (vanuit de bestaande
datastructuren).– of als aanvullende check op een relationeel
model afgeleid uit ER-modellering.
Voorbeeld gegevens redundantie
Update anomalies
ToevoegenToevoegen: staflid toevoegen branch gegevens toevoegen (dupliceren?).
WeghalenWeghalen: laatste staflid van een afdeling weg? afdelingsgegevens weg.
VeranderenVeranderen: tel_no van afdeling wijzigen mogelijk vele plaatsen wijzigen (inconsistenties!).
Normalisatie intuïties
(zoveel mogelijk) voorkomen van redundantie.
kleine tabellen met steeds betekenisvol samenhangende attributen (ER-modellering leidt “vanzelf” tot RDB in 3e normaalvorm!).
decomponeren van tabellen in deeltabellen:
– zodat zonder verlies oorspronkelijke tabel gereproduceerd kan worden.
– zonder dat afhankelijkheden tussen attributen verloren raken.
Decompositie van tabellen
Zonder verliesvan gegevens
(nonloss-decomposition)
Met verliesvan gegevens
Afhankelijkheden
Normalisatie heeft alles met (functionele) afhankelijkheden tussen attributen te maken– S# STATUS– S# CITY– STATUS CITY
Functionele afhankelijkheden
Centraal begrip bij normalisatie! Beschrijft relatie(s) tussen attributen in een
relatie. Voorbeeld: ALS R(A,B) waarin A en B
verzamelingen van attributen van de relatie R voorstellen, DAN is B functioneel afhankelijk van A als elke waarde van B eenduidig vastligt vanuit de waarden voor A.
Functionele afhankelijkheid
Functioneel want: de eenduidigheid van het reaultaat hangt af van de betekenis van de attributen!
Notatie: determinanten van de functionele afhankelijkheid links van de pijl.
Een functionele afhankelijkheid is een M:1 relatie tussen twee verzamelingen attributen.
Voorbeeld functionele afhankelijkheid
Functionele afhankelijkheden -Vb
4) is triviale afhankelijkheid (oninteressant)
5) Moet zo zijn als {S#, P#} primaire sleutel zijn
7) & 8) zijn “toevallig” (niet functioneel)
2) is redundant t.o.v. 6) [en 1) t.o.v. 7), maar de laatste is “toevallig”]
1) {S#, P#} {QTY}2) {S#, P#} {CITY}3) {S#, P#} {CITY, QTY}4) {S#, P#} {S#}5) {S#, P#} {S#, P#, CITY, QTY}6) {S# } {CITY}7) {S# } {QTY}8) {QTY } {S#}9) … … … …
1e normaalvorm (1NF)
Elke “cel” bevat precies één waarde
0NF 1NF:– door toevoegen van extra tuples– of door de zich herhalende groep(en) in een aparte
tabel te zetten
Bestand in 0NF
Voorbeeld 0NF 1NF
extra tuples, duplicering van studentnummer en naam
afsplitsing van tabel
2e normaalvorm (2NF)
Een relatie is in de 2e normaalvorm als:– de tabel is in de 1e normaalvorm
EN elk (niet-sleutel)attribuut is volledig functioneel afhankelijk van de volledige primaire sleutel.
1NF 2NF:– afsplitsen van de attributen die afhangen van
een gedeelte van de primaire sleutel in een aparte tabel.
Voorbeeld 1NF 2NF
3e normaalvorm (3NF)
Een relatie is in de 3e normaalvorm als:– de tabel in de 2e normaalvorm is
EN elk (niet sleutel-)attribuut is volledig functioneel ONafhankelijk van alle overige attributen (m.a.w. er is géén indirecte sleutelafhankelijkheid)
2NF 3NF– afsplitsen van de indirect afhankelijke
attributen in een aparte tabel
Voorbeeld 2NF 3NF
Boyce-Codd normaalvorm (BCNF)
Tot nu alleen gekeken naar afhankelijkheden met de primaire sleutel (d.w.z. geen gedeeltelijke afhanke-lijkheden en geen indirecte afhankelijkheden)
Maar zulke afhankelijkheden kunnen er ook bestaan met andere kandidaat sleutels (als ze er zijn!).
Een relatie is in de BCNF normaalvorm als:alle determinanten zijn minimaal kandidaat-sleutels … geen afhankelijkheden meer van niet sleutels.
3NF !! ; BCNF ??
Client_No + IDate ITime, Staff_No, Room Staff_No +IDate + ITime Client_No, Room Room + IDate + ITime Client_No, Staff_No Staff_No + IDate Room
3NF BCNF
Nogmaals 3NF !! ; BCNF ??
Veronderstel:– voor elke cursus en voor elke student geldt dat deze cursus
voor hem door slechts één docent onderwezen worden;– elke docent geeft slechts één cursus.
Dan:– Student + Cursus Docent– Docent Cursus
Student Cursus DocentSmid M&T BesselaarSmid MCI Wielingade Boer M&T Besselaarde Boer MCI de Vries
Student Cursus Docent
Nogmaals 3NF !! ; BCNF ??
Wel in 3NF, maar niet in BCNF want er zijn 2 kandidaat-sleutels:– Student + Cursus– Student + Docenten ... Cursus wordt al
gedetermineerd doorDocent alleen ...
Problemen:– o.a. als je ‘de Boer’ bij `MCI’ weghaalt
Student Cursus DocentSmid M&T BesselaarSmid MCI Wielingade Boer M&T Besselaarde Boer MCI de Vries
Student Cursus Docent
BCNF
Maar … … toevoegen:Smid + de Vries
mag niet! Want de Vries geeft MCI en dat krijgt Smid al van docent Wielinga … …
– Deze afhankelijkheid wordt echter niet meer afgedwongen! (is verloren geraakt).
Student DocentSmid BesselaarSmid Wielingade Boer Besselaarde Boer de Vries
Docent CursusBesselaar M&TWielinga MCIde Vries MCI
BCNF altijd wenselijk?
Soms bestaat er een functionele afhankelijkheid die verloren raakt …
Dan een keuze maken tussen twee “kwaden”:– redundante informatie
– mogelijk verlies van een functionele (betekenisvolle ?) afhankelijkheid bijvoorbeeld:
{Room#, Int_date, Int_Time} {Staff#, Client#}
Relaties uit het boek
Normaliseren
Par 4.2
p.72-85
ongenormaliseerd
1 NF
2NV 3NV
3NV
Voorbeeld vereisten