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