normalisatie – deel 2

Katrien Verbert

katrien.verbert@cs.kuleuven.be

inhoud

• decompositie: algoritmen en eigenschappen

• meerwaardige afhankelijkheden, 4e normaalvorm

• join-afhankelijkheden en 5e normaalvorm

verschillende benaderingen

1. via hoogniveau modellering (top-down)

– ER-schema bouwen

– ER-schema omzetten naar relationeel gegevensbankschema

– o.a. partiële en transitieve afhankelijkheden wegwerken

2. meteen een relationeel gegevensschema bouwen

(bottom-up)

– universeel schema met alle attributen

– technieken, algoritmes voor decompositie

decompositie:

algoritmen en eigenschappen

• Vertrek van 1 universele relatie R

– met schema SR = < UR, FR>

• Gewenst:

– decompositie (SR) = { SR1 , SR2 , ..., SRk } (met k > 1) zodat

• elke Ri in BCNF of 3NF is

• alle informatie behouden blijft

• alle functionele afhankelijkheden bewaard blijven

– Laatste 2 voorwaarden zijn niet zo evident!

behoud van informatie

• informatie blijft behouden

a.s.a.

oorspronkelijke relatie volledig gereconstrueerd kan

worden uit decompositie

• voorbeeld: EMP_LOCS en EMP_PROJ1

– oorspronkelijke relatie niet reconstrueerbaar:

join levert onechte tupels op

– dus geen volledig behoud van informatie

resultaat van natuurlijke join op de tuples boven de stippellijn: er worden onechte tupels ingevoerd

bewaren van afhankelijkheden

• functionele afhankelijkheden zijn intrarelationele restricties

– X Y: X en Y zijn attributenverz. van dezelfde relatie

• bij decompositie geven deze afhankelijkheden aanleiding tot:

– intrarelationele afhankelijkheden in Ri: URi(FR0)

• projectie van FR0 op URi :

enkel die X Y blijven over waarvoor X Y URi

– interrelationele afhankelijkheden

• deze zijn moeilijker te controleren door DBMS :

join nodig om na te gaan of nieuw toegevoegde tupels voldoen

Def: Een decompositie (SR) = {SR1 , SR2 , ..., SRk} van R bewaart de afhankelijkheden van R indien ( UR1(FR) ... URk(FR) ) + = FR

+

Als INTER INTRA+, dan zeggen we dat

(SR) de afhankelijkheden van F bewaart

decompositie-algoritme 1

• algoritme voor afhankelijkheden-bewarende

decompositie naar 3NF:

Helaas: kan tot informatieverlies aanleiding geven vb (probeer uit):

1. zoek een minimale overdekking G voor F 2. voor elke X die ergens in G voorkomt in de linkerzijde van een functionele afhankelijkheid: maak een schema {X A1 A2 ... Am} waarbij X A1, ..., X Am alle afhankelijkheden in G zijn met X als linkerlid 3. plaats alle overblijvende attributen in een enkel relatieschema

A B C D

voorbeeld

Emp_ssn Pno Esal Ephone Dno Pname Plocation

U

Afhankelijkheden

{Emp_ssn} {Esal, Ephone, Dno}

{Pno} {Pname, Plocation}

{Emp_ssn, Pno} {Esal, Ephone, Dno, Pname, Plocation}

minimale overdekking

Emp_ssn Pno Esal Ephone Dno Pname Plocation

U

Afhankelijkheden

1.{Emp_ssn} {Esal, Ephone, Dno}

2.{Pno} {Pname, Plocation}

3.{Emp_ssn, Pno} {Esal, Ephone, Dno, Pname, Plocation}

Kunnen we afhankelijkheden weglaten?

Minimale overdekking

{Emp_ssn} {Esal, Ephone, Dno}

{Pno} {Pname, Plocation}

{Emp_ssn, Pno}+={Emp_ssn, Pno, Esal, Ephone, Dno, Pname,

Plocation}

decompositie

Emp_ssn Pno Esal Ephone Dno Pname Plocation

U

Minimale verzameling G

{Emp_ssn} {Esal, Ephone, Dno}

{Pno} {Pname, Plocation}

voor elke X die ergens in G voorkomt in de linkerzijde van een functionele afhankelijkheid: maak een schema {X A1 A2 ... Am} waarbij X A1, ..., X Am alle afhankelijkheden in G zijn met X als linkerlid

Emp_ssn Esal Ephone Dno Pno Pname Plocation

oefening

Model# Serial# Price Color Name Year

Stock

afhankelijkheden

{M, S} {P, C}

{S} {Y}

{M} {N}

{N,Y} {P}

minimale verzameling

{M, S} {C}

{S} {Y}

{M} {N}

{N,Y} {P}

Model# Serial# Color

Name Year Price Model# Name

Serial# Year

Def: Een decompositie SR) = {SR1 , SR2 , ..., SRk} is verliesloos a.s.a. voor elke toegestane extensie r van R (d.i. een extensie die aan FR voldoet) geldt: UR1(r) * ... * URk (r) = r

verliesloze decomposities

• m.a.w. join van relaties in decompositie levert geen onechte tupels op (lossless of nonadditive join property)

• testen of een decompositie verliesloos is: d.m.v. het "chase" algoritme

• Dé vraag is: kan elk tupel van de originele relatie R gereconstrueerd worden op basis van de tupels in de decompositie?

het Chase-algoritme

• maakt gebruik van een matrix

– kolommen = alle attributen Aj van originele relatie R

– een rij per relatie Ri in de decompositie

• voor elke rij i:

– vul aj in op positie j als Aj in schema SRi voorkomt; anders bij

– de a's stellen de aanwezige waarden voor

• redenering:

– als X Y, en de waarden voor X zijn gelijk in 2 rijen, dan ook

die voor Y

– dit aanduiden in matrix

• doorgaan tot geen verandering meer optreedt

• 1 rij vol a's verliesloos

Algoritme: Test of decompositie D = {R1, ..., Rn} van een relatie R met afhankelijkheden F verliesloos is: maak een matrix S met 1 rij i voor elke relatie Ri in de decompositie D, en 1 kolom j voor elk attribuut Aj in R voor elke rij i : voor elke kolom j : als Aj als attribuut voorkomt in Ri dan Sij := aj anders Sij := bij herhaal tot S niet meer verandert: voor elke functionele afhankelijkheid X Y in F: voor elke verzameling rijen V in S waarvoor geldt dat de symbolen in de kolommen overeenkomend met X dezelfde zijn:

{m.a.w. i1,i2 V: j | Aj X : Si1j=Si2j} maak de symbolen in de kolommen van Y ook gelijk, als volgt: als een van de rijen in V een aj bevat dan voor elke k in V: Skj := aj anders

kies een i V voor elke k in V: Skj := bij { D is verliesloos a.s.a. er een rij bestaat die enkel a's bevat }

eigenschappen van verliesloze decomposities

• Eigenschap LJ1: Niet-additieve Join Test voor Binaire Decomposities

– (SR) = { SR1 , SR2 } is verliesloos t.o.v. F a.s.a.

– eenvoudiger test dan "chase" algoritme

– maar enkel toepasselijk op splitsing in 2 schema's

(UR1 UR2) (UR1 \ UR2) F+ of (UR1 UR2) (UR2 \ UR1) F+

voorbeeld

• UR = EMP_DEPT = {Ename, Ssn, Bdate, Address, Dnumber,

Dname, Dmgr_ssn}

• F= {Ssn {Ename, Bdate, Address, Dnumber},

Dnumber {Dname, Dmgr_ssn}}

• UR1 = ED1 = {Ename, Ssn, Bdate, Address, Dnumber}

• UR2 = ED2 = {Dnumber, Dname, Dmgr_ssn}

• (UR1 UR2) (UR1 \ UR2) F+ of (UR1 UR2) (UR2 \ UR1) F+ ?

• UR1 UR2 = {Dnumber}

• UR1 - UR2 = {Ename, Ssn, Bdate, Address}

• UR2 – UR1 = {Dname, Dmgr_ssn}

• (UR1 UR2) (UR1 \ UR2) = Dnumber Dname, Dmgr_ssn

• Verliesloos!

:= {SR} zolang er een relatieschema SRi in niet in BCNF is : zoek een functionele afhankelijkheid X Y binnen SRi die volgens BCNF niet toegelaten is vervang SRi in door twee schema’s SRi \ Y en X Y : := \ {SRi} {SRi \ Y, X Y}

Afhankelijkheden kunnen nu verloren gaan!

verliesloze decompositie van een

relatie R naar BCNF

voorbeeld van ontwerp via

decompositie

• Gegevensbank met info over huizen in een gemeente

• Universele relatie R1(O,S,H,P,W,B,D)

• UR1 = {O,S,H,P,W,B,D}

– O = identificatienr van huis

– S = straat

– H = huisnummer

– P = postcode

– W = wijk

– B = naam bouwmaatschappij

– D = directeur bouwmaatschappij

id.nr (O)

wijk (W)

directeur (D)

bouwmij (B)

huisnr (H) straatnaam (S)

postcode (P)

FR1 = { O BSH, B D, D B, SH OP, P S,

S W }

O S H P W B D

15351 Perenstraat 23 2745 DD Fruitwijk Bouwlust P. Akker

15352 Perenstraat 25 2745 DD Fruitwijk Bouwlust P. Akker

15788 Appelstraat 8 2745 EG Fruitwijk Solide Z. Glas

20371 Beukenstraat 94 2751 BE Bomenwijk Solide Z. Glas

20372 Beukenstraat 96 2751 BE Bomenwijk Solide Z. Glas

20167 Beukenstraat 1 2751 BB Bomenwijk Bouwlust P. Akker

Redundante gegevens

voorbeeld van een extensie van R1

• Relatie is reeds in 1NF

• 3 kandidaatsleutels voor R1:

– O, SH, PH

– dus O,S,H,P zijn sleutelattributen van R1; W,B,D niet

• Is R1 in 2NF?

Is R1 in 2NF?

Idnr (O) Straat (S) Huisnummer(H) Postcode(P) Wijk (W) BouwM.(B) Directeur

= { O BSH, B D, D

B, SH OP, P S,

S W }

Is R1 in 2NF?

• Nee:

– W partieel afhankelijk van kand.sleutel SH

– S W

• Normalisatie:

• W uit R1 verwijderen, resulterend in

– R2 met UR2 = { O, S, H, P, B, D }

• en

– R20 maken met UR20 = { S, W }

voorbeeld

Idnr (O) Straat (S) Huisnummer(H) Postcode(P) BouwM.(B) Directeur (D)

= { O BSH, B D, D

B, SH OP, P S,

S W } Straat (S) Wijk (W)

R2

R20

vorige voorbeeldextensie wordt nu

O S H P B D

15351 Perenstraat 23 2745 DD Bouwlust P. Akker

15352 Perenstraat 25 2745 DD Bouwlust P. Akker

15788 Appelstraat 8 2745 EG Solide Z. Glas

20371 Beukenstraat 94 2751 BE Solide Z. Glas

20372 Beukenstraat 96 2751 BE Solide Z. Glas

20167 Beukenstraat 1 2751 BB Bouwlust P. Akker

S W

Perenstraat Fruitwijk

Appelstraat Fruitwijk

Beukenstraat Bomenwijk

Alle relaties in 3NF?

Idnr (O) Straat (S) Huisnummer(H) Postcode(P) BouwM.(B) Directeur (D)

= { O BSH, B D, D

B, SH OP, P S,

S W } Straat (S) Wijk (W)

R2

R20

Alle relaties in 3NF?

• R20: ja

• R2: nee

– transitieve afh. : D is trans. afh. van O via B

– afhankelijkheid B D (en D B) afsplitsen

• (SR2) = { SR3, SR30 } met

– UR3 = UR2 \ { D } = { O, S, H, P, B }

– UR30 = { B, D }

extensie volgens huidig

gegevensbankschema – :

O S H P B

15351 Perenstraat 23 2745 DD Bouwlust

15352 Perenstraat 25 2745 DD Bouwlust

15788 Appelstraat 8 2745 EG Solide

20371 Beukenstraat 94 2751 BE Solide

20372 Beukenstraat 96 2751 BE Solide

20167 Beukenstraat 1 2751 BB Bouwlust

S W

Perenstraat Fruitwijk

Appelstraat Fruitwijk

Beukenstraat Bomenwijk

B D

Bouwlust P. Akker

Solide Z. Glas

Alle relaties in BCNF?

Idnr (O) Straat (S) Huisnummer(H) Postcode(P) BouwM.(B)

= { O BSH, B D, D

B, SH OP, P S,

S W } Straat (S) Wijk (W)

R3

R20

BouwM. (B) Directeur (D)

kandidaatsleutels van R3: O, SH, PH

R30

• Alle relaties nu in 3NF

• Ook in BCNF?

– R20 en R30 wel

– R3 niet

• kandidaatsleutels van R3: O, SH, PH

• sleutelattribuut S is transitief afh. van SH via P

• daarom P S weer afsplitsen naar extra relatie

Welke afhankelijkheden zijn "verloren gegaan"?

m.a.w. welke restricties zijn nu moeilijker te controleren?

uiteindelijke extensie van

gegevensbank

O H P B

15351 23 2745 DD Bouwlust

15352 25 2745 DD Bouwlust

15788 8 2745 EG Solide

20371 94 2751 BE Solide

20372 96 2751 BE Solide

20167 1 2751 BB Bouwlust

S W

Perenstraat Fruitwijk

Appelstraat Fruitwijk

Beukenstraat Bomenwijk

B D

Bouwlust P. Akker

Solide Z. Glas

S P

Perenstraat 2745 DD

Appelstraat 2745 EG

Beukenstraat 2751 BE

Beukenstraat 2751 BB

FR1 = { O BSH, B D, D B, SH

OP, P S, S W }

• We hebben nu

– verliesloze decompositie naar BCNF

– afhankelijkheden-behoudende decompositie naar 3NF

• Combinatie van beide mogelijk?

– m.a.w.: verliesloos en afhankelijkheden-behoudend

• Ja, maar enkel tot 3NF (BCNF niet steeds bereikbaar)

1. zoek een minimale overdekking G voor F 2. voor elke X die ergens in G voorkomt in de linkerzijde van een functionele afhankelijkheid: maak een schema {X A1 A2 ... Am} waarbij X A , ..., X Am alle afhankelijkheden in G zijn met X als linkerlid 3. plaats alle overblijvende attributen in een enkel relatieschema 4. als geen van de relatieschema's een sleutel van R bevat dan maak een extra relatieschema dat attributen bevat die een sleutel voor R vormen

verliesloze en afhankelijkheden-

bewarende decompositie naar 3NF

• zelfde algoritme als voorheen voor afh.bewarende

decompositie, met één extra stap

voorbeeld

Emp_ssn Pno Esal Ephone Dno Pname Plocation

U

Afhankelijkheden

{Emp_ssn} {Esal, Ephone, Dno}

{Pno} {Pname, Plocation}

{Emp_ssn, Pno} {Esal, Ephone, Dno, Pname, Plocation}

Emp_ssn Esal Ephone Dno

Pno Pname Plocation

Emp_ssn Pno

Minimale overdekking

{Emp_ssn} {Esal, Ephone, Dno}

{Pno} {Pname, Plocation} 1

2

4

algoritme voor vinden van een sleutel

Input: universele relatie R en verzameling functionele afhankelijkheden F

(1) K := R

(2) Voor elk attribuut A in K

bereken (K – A)+ t.o.v. F

als (K – A)+ alle attributen van R bevat, dan K := K – {A}

oefening

• R(A, B, C, D, E)

• F = {AB C, CD E, DE B}

• Kandidaatsleutel?

(1) K := R

(2) Voor elk attribuut A in K

bereken (K – A)+ t.o.v. F

als (K – A)+ alle attributen van R bevat, dan K := K – {A}

nulwaarden kunnen problemen geven

• effect van nulwaarden op aggregaatfuncties?

• ook problematisch voor reconstructie van originele relatie

uit decompositie

– nulwaarden in verwijssleutels

– bv. 2 nieuwe werknemers, nog geen dept. DNUM = nul

– * op EMPLOYEE en DEPARTMENT vermeldt die werknemers niet

– worden “dangling tuples” genoemd

– deze gaan verloren bij (inwendige) join

– uitwendige join biedt oplossing

natuurlijke join

left outer join

nadelen van decompositiemethode

• functionele afhankelijkheden moeten vooraf bekend zijn

– kan moeilijk zijn bij grote gegevensbanken met veel attributen

• de algoritmen zijn niet deterministisch

– minimale overdekking van F: meerdere oplossingen

– decompositie is afhankelijk van volgorde waarin f.a. bekeken

worden

• na decompositie (dure) joins nodig om originele info

terug te vinden

– kan performantie nadelig beïnvloeden

besluit

• methode niet blindelings toepassen

• combinatie van normalisatie en ER-ontwerp is

aangewezen

• voorbeeld:

– begin met (E)ER-model

– beeld af op relationeel model

– zoek functionele afhankelijkheden

– controleer of verdere decompositie wenselijk is

MEERWAARDIGE AFHANKELIJKHEDEN

EN VIERDE NORMAALVORM

meervoudige afhankelijkheden

• meervoudige afhankelijkheden zijn een gevolg van 1NF

• betekenis: elke docent gebruikt elke tekst

(onafhankelijkheid van Teacher en Text)

Course Teacher Text

Physics Green Brown Black

Mechanics Thermodynamics

Math white

Algebra Geometry

meervoudige afhankelijkheden

In het voorbeeld: Course ->> Teacher en Course ->>Text

Course Teacher Text

Physics Green Mechanics

Physics Green Thermodynamics

Physics Brown Mechanics

Physics Brown Thermodynamics

Physics Black Mechanics

Physics Black Thermodynamics

Math White Algebra

Math White Geometry

Def: Een attributenverzameling Y van een relatie R is meerwaardig

afhankelijk van een attributenverzameling X van R, genoteerd

X ->> Y,

a.s.a.

voor elke toegestane extensie r van R geldt :

als er 2 tupels t1 en t2 in r zijn zodat t1[X]=t2[X],

dan bestaan er twee tupels t3 en t4 in r zodat

t3[X] = t4[X] = t1[X] = t2[X] en

t3[Y] = t1[Y] en t4[Y] = t2[Y] en

t3[UR\X\Y] = t2[UR\X\Y] en t4[UR\X\Y] = t1[UR\X\Y]

meerwaardige afhankelijkheden

• X bepaalt eenduidig een verzameling Y's ( "X

multidetermineert Y")

• welke Y's bij X horen hangt niet af van andere attributen

meervoudige afhankelijkheden

• gegeven een relatie R, X en Y zijn deelverzamelingen van

attributen in R en Z= R – (X U Y)

• X ->> Y geldt als er 2 tupels t1 en t2 in r zijn zodat t1[X]=t2[X], dan

bestaan er twee tupels t3 en t4 in r zodat

– t3[X] = t4[X] = t1[X] = t2[X] en

– t3[Y] = t1[Y] en t4[Y] = t2[Y] en

– t3[Z] = t2[Z] en t4[Z] = t1[Z]

X Y Z

t1 a b1 c1

t2 a b2 c2

t3 a b1 c2

t4 a b2 c1

ENAME ->> PNAME

en ENAME ->> DNAME

voorbeeld

voorbeeld

• T-shirts van bepaald model, met maat (S,M,L,XL) en

kleur

• Model ->> Maat betekent:

– elk model wordt in welbepaalde maten geleverd, onafhankelijk

van de kleur

– Dus als 1 model in kleuren blauw en grijs bestaat, en in maten M,

L, XL, betekent dit dat elke combinatie van maat en kleur

beschikbaar is

– Anders gezegd: elke combinatie van kleur en maat is mogelijk

• dus automatisch ook Model ->> Kleur

belang

• Als X meerdere attribuutverzamelingen

multidetermineert: combinatorische explosie!

• Voorbeeld

– om < x1, { a1,a2 } , { b1,b2,b3 } , { c1,c2,c3 } > voor te stellen

– 2 x 3 x 3 = 18 tupels nodig

• Daarom mwa's weren uit relaties 4NF

Def: Een meerwaardige afhankelijkheid X->>Y in relatie R is een triviale meerwaardige afhankelijkheid a.s.a. Y X of X Y = UR

definitie van triviale mwa

• Merk op :

– X ->> UR \ X geldt steeds

ENAME ->> PNAME

en ENAME ->> DNAME

voorbeeld

vierde normaalvorm

Def: Een relatieschema SR = < U,F > is in de vierde

normaalvorm

a.s.a.

voor elke niet-triviale meerwaardige afhankelijkheid van

de vorm X->>Y van F+ geldt:

X is een supersleutel van R.

Belang van 4NF: vermijden van redundantie en anomalieën

(a) EMP relatie met MVDs: ENAME ->> PNAME en ENAME ->> DNAME

ENAME is geen supersleutel

(b) EMP geprojecteerd op EMP_PROJECTS en EMP_DEPENDENTS)

ENAME ->> PNAME en ENAME ->> DNAME zijn nu triviale MVDs

algoritme voor verliesloze

decompositie naar 4NF

• Merk op : garandeert geen behoud van

afhankelijkheden!

:= {R} zolang er een relatieschema SRi in is dat niet in 4NF is : zoek een niet-triviale mwa X->>Y binnen SRi die volgens 4NF niet toegelaten is; vervang SRi in door twee relatieschema’s SRi\Y en X Y: := \ {S Ri} {S Ri \ Y, X Y}

(a) EMP relatie met MVDs: ENAME ->> PNAME en ENAME ->> DNAME

ENAME is geen supersleutel

(b) EMP geprojecteerd op EMP_PROJECTS en EMP_DEPENDENTS)

ENAME ->> PNAME en ENAME ->> DNAME zijn nu triviale MVDs

oefening

• breng relatie in 4NF

• Course ->> Teacher en Course ->>Text

Course Teacher Text

Physics Green Mechanics

Physics Green Thermodynamics

Physics Brown Mechanics

Physics Brown Thermodynamics

Physics Black Mechanics

Physics Black Thermodynamics

Math White Algebra

Math White Geometry

JOIN-AFHANKELIJKHEDEN EN

VIJFDE NORMAALVORM

voorbeeld

Agent Company Product

Smith Ford truck

Smith GM car

Smith GM truck

Jones Ford car

voorbeeld

Agent Company Product

Smith Ford car

Smith Ford truck

Smith GM truck

Smith GM Car

Jones Ford car

Er is geen verliesloze decompositie mogelijk in 2 relaties, want

Agent Product

Smith car

Smith Truck

Jones car

Agent Company

Smith Ford

Smith GM

Jones Ford

*

=

levert onechte tupels op

voorbeeld

Agent Company Product

Smith Ford car

Smith Ford truck

Smith GM truck

Smith GM Car

Jones Ford Car

Jones Ford truck

En:

Company Product

Ford car

Ford Truck

GM car

GM truck

Agent Company

Smith Ford

Smith GM

Jones Ford

*

=

levert onechte tupels op

Join-afhankelijkheid

• Als dit het geval is, spreken we van een join

afhankelijkheid

• Voorbeeld

– als ( A = a en B = b ) samen voorkomen,

– en ( B = b en C = c ) komt voor,

– en ( A = a en C = c ) komt voor,

– dan komt ( A = a, B = b, C = c ) voor

• Voorbeeld 2

– als ( Agent = Jones en Company = Ford ) samen voorkomen,

– en ( Company = Ford en Product = Car ) komt voor,

– en ( Agent = Jones en Product = Car ) komt voor,

– dan komt ( Agent = Jones, Company = Ford, Product = Car ) voor

Voorbeeld

JD ({Agent, Company}, {Company, Product}, {Agent, Product})

voorwaarde voor het voorkomen van een combinatie is strenger

Def: Een join-afhankelijkheid JD(U1, ..., Un) in relatie R is een restrictie die aangeeft dat voor elke extensie r van R geldt: er is een verliesloze decompositie in relaties R1,...,Rn met attributen U1, U2, ..., Un; m.a.w. U1(r) U2(r) ... Un(r) = r

voorbeeld

• aanbod van T-shirts met bepaald model, maat en kleur

voldoet aan volgende restrictie:

als dergelijke tupels voorkomen in een extensie van R...

dan ook dit tupel

Dit is de join-afhankelijkheid

JD ( {Model,Maat} , {Maat,Kleur} , {Model,Kleur} )

Wat is het verschil met Model->>Maat ?

Model Maat Kleur

x y

x z

y z

x y z

triviale JD

Def: Een join-afhankelijkheid JD(U1, ..., Un) in relatie R is een triviale join-afhankelijkheid a.s.a. een van de Ui gelijk is aan UR.

als dergelijke tupels voorkomen in een extensie van R...

dan ook dit tupel

Voorbeeld van triviale JD:

Model Maat Kleur

x y

x z

x y z

x y z

Def: Een join-afhankelijkheid JD(U1, ..., Un) in relatie R is een triviale join-afhankelijkheid a.s.a. een van de Ui gelijk is aan UR.

vijfde normaalvorm

Methode om relatieschema naar 5NF te normaliseren:

voor elke JD() in FR+: splits R op volgens

Voorbeeld : T-shirts

UR = { Model, Maat, Kleur }

splits op in { Model, Maat }, { Maat, Kleur }, { Model, Kleur }

Def: Een relatieschema SR = <U,F> is in de vijfde normaalvorm (of project-join-normaalvorm) a.s.a. voor elke niet-triviale join-afhankelijkheid JD(U1, ..., Un) van F+ geldt: U1 , ..., Un zijn allemaal supersleutels van R.

ander voorbeeld: relatie SUPPLY

• Leverancier (supplier) s levert onderdeel (part) p aan

project j

• restrictie:

– als leverancier s deel p kan leveren,

– en project j gebruikt onderdeel p,

– en leverancier s levert aan project j,

– dan levert s onderdeel p aan project j

• genoteerd:

– JD ( {SNAME, PARTNAME} , {SNAME,PROJNAME},

{PARTNAME, PROJNAME} )

voorbeeld examenvraag

Gegeven de volgende relatie die gegevens bevat van koelkasten

REFRIG { ModelNr, Jaar, Prijs, Fabriek, Kleur }

met de functionele afhankelijkheden F:

– { ModelNr } { Fabriek }

– { ModelNr, Jaar } { Prijs }

– { Fabriek } { Kleur }

Gevraagd:

– Bepaal een kandidaatsleutel.

– In welke normaalvorm is de relatie REFRIG?

– Normaliseer REFRIG zover je kan en geef aan in welke normaalvorm

het resultaat is.

VRAGEN?