SlideShare a Scribd company logo
functionele afhankelijkheden
en normalisatie – deel 1



Katrien Verbert
katrien.verbert@cs.kuleuven.be
inhoud

•   informele richtlijnen voor het ontwerp van een gegevensbank
•   een voorbeeld van normalisatie
•   functionele afhankelijkheden
•   normaalvormen (1e, 2e, 3e, Boyce-Codd)
ontwerp van relationele
gegevensbanken
• verschillende benaderingen:
   1. via hoogniveau modellering:
      • werkelijkheid analyseren
      • ER-schema bouwen
      • ER-schema omzetten naar relationeel gegevensbankschema
   2. meteen een relationeel gegevensschema bouwen
      • informele richtlijnen
      • technieken, algoritmes
           – belangrijk begrip: normaliseren

• belangrijke punten:
   – minimale redundantie, maximale performantie, ...
waarom minder goed ontwerp?
informele richtlijnen
1. Ontwerp een relatieschema zo dat zijn betekenis
   gemakkelijk verklaard kan worden



   – betekenis van attributen moet duidelijk zijn
   – betekenis van relatie moet duidelijk zijn
informele richtlijnen
2. Ontwerp een relatieschema zo dat redundantie vermeden wordt
   en geen toevoeg-, weglaat- of wijziging-anomalieën voorkomen
redundante informatie
problemen bij toevoegen
( "toevoeg-anomalieën”)
 EMP_DEPT
 EName   SSN      Bdate    Address   Dnumber Dname    Dmgr



• nieuwe werknemer toevoegen
   – nieuwe gegevens moeten consistent zijn met bestaande
     departement gegevens
   – null waarden als geen dept info voorhanden is
• hoe een departement toevoegen dat nog geen
  werknemers heeft?
weglaat-anomalieën
 EMP_DEPT
 EName   SSN    Bdate   Address   Dnumber Dname   Dmgr



• laatste werknemer uit een departement weg  alle info
  over dat departement ook weg!
wijziging-anomalieën

 EMP_DEPT
 EName   SSN     Bdate   Address   Dnumber Dname   Dmgr



• bv. manager van dept 5 wijzigen  wijziging moet in
  alle tupels van EMP_DEPT gebeuren, anders wordt
  gegevensbank inconsistent
informele richtlijnen

3. Vermijd zoveel mogelijk attributen waarvan de waarden
   nul kunnen zijn
   – nul = niet van toepassing / onbekend / nog niet geregistreerd
informele richtlijnen

4. Ontwerp relatieschema's zo dat ze na een join met = op
   attributen die primaire of verwijssleutels zijn, geen
   onechte tupels opleveren
slechte voorstelling van de EMP_PROJ relatie:
door twee relaties EMP_LOCS en EMP_PROJ1
resultaat van natuurlijke join op de tuples boven de stippellijn:
er worden onechte tupels ingevoerd
voorbeeld van normalisatie

• "Kaartenbak"-voorbeeld
   – context: "open universiteit"
• Kaarten met gegevens over:
   – StudentNr, Naam, Cursus
   – Cursus =
       • Code, Titel, InschrijvingsDatum, StudiecentrumCode, StudiecentrumNaam

• een student kan meerdere cursussen volgen
   –  Cursus is een meerwaardig samengesteld attribuut
       • niet toegelaten in relationeel model!
       • weghalen van meerwaardige / samengestelde attributen
          "eerste normaalvorm"
• Bekijk gegevens: welke kunnen aanleiding geven tot
  anomalieën?
   – waar is er redundantie?
   – m.a.w. welke gegevens volgen uit andere?
• Identificatie van afhankelijkheden
• Herwerken van relatieschema's
   –  2e en 3e normaalvorm
functionele afhankelijkheden
• Definitie
      Zij gegeven een relatieschema R = {A1, A2, ..., An} en
      attributenverzamelingen X en Y.
      We zeggen dat Y functioneel afhankelijk is van X,
      genoteerd X  Y,
      als en slechts als
      1. X  
      2.  mogelijke extensies r van R:
         t1, t2  r en t1[X] = t2[X]  t1[Y] = t2[Y]
Merk op:
"voor alle mogelijke extensies" (= eigenschap van relatieSCHEMA)
hangt af van betekenis van de relatie!
uit die betekenis volgen nl. bepaalde restricties waaraan de extensies
moeten voldoen
doel van functionele afhankelijkheden

• expliciet beschrijven van bepaalde restricties waaraan
  de relatie steeds moet voldoen
• vb: relatie EMP_PROJ
   – SSN  ENAME
   – PNUMBER  { PNAME, PLOCATION }
   – { SSN,PNUMBER }  HOURS
• notatie in schema's: via pijlen, bv:


 SSN    PNUMBER       HOURS     ENAME    PNAME   PLOCATION
TEXT  COURSE ?
              kan niet besloten worden uit de extensie

maar niet TEACHER  COURSE
                want een tegenvoorbeeld is in de extensie aanwezig
afleidingsregels voor functionele
afhankelijkheden
• een verzameling functionele afhankelijkheden van R
  kan nieuwe functionele afhankelijkheden impliceren
   – bv. A  B en B  C impliceert A  C
   – Notatie: { A  B, B  C } |= A  C
• afleidingsregels voor functionele afhankelijkheden
   – laten toe alle functionele afhankelijkheden te vinden die door
     een verzameling F van functionele afhankelijkheden
     geïmpliceerd worden
• sluiting van F, genoteerd F+,
   – is de verzameling van alle f.a. die door F geïmpliceerd worden
voorbeeld

• F={Ssn{Ename, Bdate, Address, Dnumber},
  Dnumber {Dname, Dmgr_ssn}}

• Functionele afhankelijkheden afgeleid uit F
   – Ssn  {Dname, Dmgr_ssn}
   – Ssn  Ssn
   – Dnumber  Dname
basis afleidingsregels

• FD1. reflexiviteitsregel: Y  X  X  Y
• FD2. uitbreidingsregel: { X  Y } |= XZ  YZ
• FD3. transitiviteitsregel: { X  Y, Y  Z } |= X  Z
basisregels zijn correct en volledig

• correct (of "gezond", Eng. "sound")
   – alle afhankelijkheden die afgeleid kunnen worden, worden ook
     werkelijk geïmpliceerd
• volledig
   – alle afhankelijkheden die geïmpliceerd worden, kunnen ook met
     de regels afgeleid worden
bewijs van correctheid

  – FD1 en FD3: bewijs als oefening
  – FD2: { X  Y } |= XZ  YZ

Bewijs FD2:

X  Y betekent:  t1, t2 : t1[X] = t2[X]  t1[Y] = t2[Y].

Voor eender welke 2 tupels t1, t2 waarvoor geldt t1[XZ] = t2[XZ],
geldt:
 t1[XZ] = t2[XZ]  t1[X] = t2[X] en t1[Z] = t2[Z]
                     t1[Y] = t2[Y] en t1[Z] = t2[Z] (uit X  Y)
                     t1[YZ] = t2[YZ]
We hebben dus
       t1, t2 : t1[XZ] = t2[XZ]  t1[YZ] = t2[YZ]
wat equivalent is met XZ  YZ.
extra afleidingsregels

• FD4: decompositieregel
  { X  YZ } |= X  Y
• FD5: verenigingsregel
  { X  Y, X  Z } |= { X  YZ }
• FD6: pseudo-transitiviteitsregel
  { X  Y, WY  Z } |= WX  Z


    Uit     X      Y                     X
                            Z                Z
                                volgt:   W
                   W
bewijs FD4-6

• ofwel via definitie, ofwel via FD1-3 (die immers correct
  en volledig zijn)
• vb: bewijs FD4: { X  YZ } |= { X  Y }
   – 1:         X  YZ (geg)
   – 2:         uit FD1 volgt YZ  Y
   – uit (1) en (2) via FD3:    XY
hoe alle functionele afhankelijkheden
in een relatieschema vinden?
• uit betekenis van relaties en attributen:  verzameling
  afhankelijkheden F
   – onvermijdelijk: afhankelijkheden volgen uit betekenis
• via afleidingsregels worden alle functionele
  afhankelijkheden bekomen die uit F volgen: F+
• hoe:
   – voor elke verzameling attributen X, die links in een funct.
     afhankelijkheid van F voorkomt, bepaal XF+
• XF+ ("sluiting van X t.o.v. F"):
   – = verzameling van alle attributen die funct. bepaald zijn door X
• algoritme:
   – voor elke X  Y  F, bepaal XF+ met de afleidingsregels
• Algoritme: bepaal XF+, sluiting van X onder F

     XF+ := X
     herhaal
        oldXF+ := XF+
        voor elke Y  Z in F :
           als Y  XF+ dan XF+ := XF+  Z
     tot (oldXF+ = XF+)


XF+ soms genoteerd X+ (indien geen verwarring m.b.t. F
mogelijk is)
Voorbeeld: EMP_PROJ

• F = { SSN  ENAME,
       PNUMBER  { PNAME, PLOCATION },
       { SSN, PNUMBER }  HOURS }

• Sluitingen t.o.v. F zijn dan:
   – { SSN }+ = { SSN, ENAME }
   – { PNUMBER }+ = { PNUMBER, PNAME, PLOCATION }
   – { SSN, PNUMBER }+ = { SSN, PNUMBER, ENAME,
     PNAME, LOCATION, HOURS}
oefening

• G={Ssn  {Ename, Bdate, Address, Dnumber},
  Dnumber  {Dname, Dmgr_ssn}}

• {Ssn}+?
                    XF+ := X
• {Dnumber}+?       herhaal
                      oldXF+ := XF+
                      voor elke Y  Z in F :
                          als Y  XF+ dan XF+ := XF+  Z
                    tot (oldXF+ = XF+)
oplossing

• G={Ssn  {Ename, Bdate, Address, Dnumber},
  Dnumber  {Dname, Dmgr_ssn}}

• {Ssn}+={Ssn, Ename, Bdate, Address, Dnumber,
  Dname, Dmgr_ssn}
• {Dnumber}+={Dnumber, Dname, Dmgr_ssn}
overdekking, equivalentie

• Zij E en F verzamelingen f.a. van R

• E wordt overdekt door F a.s.a. E  F+
   – alle f.a. in E volgen uit F via afleidingsregels
   – automatisch ook E+  F+


• E en F zijn equivalent a.s.a. E+ = F+

• Nagaan of F E overdekt:
   – voor alle X  Y in E: bepaal XF+ en controleer of Y  XF+
oefening

• Relatie R{A,B,C,D,E,F,G}

• Met afhankelijkheden
   – AB
   – BC  DE
   – AEF  G


• Sluiting {A,C,F}+?
• Kan ACFDF afgeleid worden uit deze verzameling?
oefening

• Overdekt F de verzameling E?

   E = {A  BC, D  AE}
   F = {A  B, AB  C, D  AC, D  E}

Nagaan of F E overdekt:
voor alle X  Y in E: bepaal XF+ en controleer of Y  XF+
oplossing

• Overdekt F de verzameling E?
  E = {A  BC, D  AE}
  F = {A  B, AB  C, D  AC, D  E}

voor alle X  Y in E: bepaal XF+ en controleer of Y  XF+

• A  BC
   – AF+={A, B, C}
   – BC  {A, B, C}
• D  AE
   – DF+={D, A, C, E, B}
   – AE  {D, A, C, E, B}
oefening

• Overdekt E de verzameling F?
  E = {A  BC, D  AE}
  F = {A  B, AB  C, D  AC, D  E}

voor alle X  Y in F: bepaal XE+ en controleer of Y  XE+
• AB                  • D  AC
   – A+E={A, B, C}        – D+E= {D, A, E, B, C}
   – B  {A, B, C}        – AC  {D, A, E, B, C}
• AB  C               • DE
   – AB+E={A, B, C}       – D+E={D, E, A, C, B}
   – C  {A, B, C}        – E  {D, E, A, C, B}
minimale verzameling functionele
afhankelijkheden
• F is een minimale verzameling a.s.a. er geen
  equivalente verzameling G is te vormen door het
  weglaten van
   – een afhankelijkheid uit F
   – of een attribuut uit de rechterkant van een afhankelijkheid in F
   – of een attribuut uit de linkerkant van een afhankelijkheid in F


• E is een minimale overdekking van F a.s.a. E F
  overdekt en minimaal is
stelling

• een verzameling f.a. F is minimaal als
   – rechterlid van elke afhankelijkheid een singleton is
       •  geen attribuut kan weggelaten worden uit rechterlid
   – en geen enkele strikte deelverzameling van F equivalent is met
     F
       • geen afhankelijkheid kan weggelaten worden
   – en voor geen enkele X  A van F bestaat er een echte
     deelverzameling Z  X waarvoor F  { X  A }  { Z  A }
     equivalent is met F
       • geen attr. kan weggelaten worden uit linkerlid
– Algoritme voor berekening van een minimale overdekking G
  van F:

G := F
voor elke X  A1A2...An in G (met n > 1) :
     G := G  {X  A1A2...An}  {X  A1, ..., X  An}

voor elke X  A in G :
     voor elke B  X :
        X' := X  {B}
         G' := G  {X  A}  {X'  A}
        als B  X’G’+ dan G := G'

voor elke X  A in G :
     G' := G  {X  A}
     als A  XG'+ dan G := G’
{G is een minimale overdekking van F}
voorbeeld

• E: {BA, DA, ABD}

• Stap 1 = OK
Voorbeeld: stap 2

• E: {BA, DA, ABD}

• ABD : Vervangen door BD?

  – F={BA, DA, BD}

  – A  B+F?

  – B+F={B, A, D}  vervanging OK!


• E: {BA, DA, BD}
voorbeeld: stap 3

• E: {BA, DA, BD}

• BA : Weglaten?

  – E’= {DA, BD}

  – A  B+E’?

  – B+E’={B, D, A}  weglating OK!


• E: {DA, BD}
oefening

• Afhankelijkheden
   –   {M, S}  {P, C}
   –   {S}  {Y}
   –   {M}  {N}
   –   {N,Y}  {P}


• Bereken minimale verzameling
oplossing stap 1

• Afhankelijkheden
   –   {M, S}  {C}
   –   {M, S}  {P}
   –   {S}  {Y}
   –   {M}  {N}
   –   {N,Y}  {P}


• Welke afhankelijkheden kunnen weggelaten worden?
oplossing

• minimale verzameling afhankelijkheden G
   –   {M, S}  {C}
   –   {S}  {Y}
   –   {M}  {N}
   –   {N,Y}  {P}


• Want {M,S}  P afleidbaar uit G
   – {M,S}G+={M, S, C, Y, N, P}
   – P  {M,S}G+
normaalvormen

• afhankelijkheden in een relatieschema kunnen oorzaak
  zijn van
   – redundantie van gegevens in een extensie
   – problemen bij het onderhoud
• daarom:
   – indeling van relatieschema’s in groepen op grond van soorten
     afhankelijkheden: NORMAALVORMEN
   – hoe hoger de normaalvorm, des te minder afhankelijkheden
     zich kunnen voordoen
normaalvormen

• een normaalvorm legt bepaalde eisen op aan relaties
• normalisatie
   = relatie in een bepaalde normaalvorm brengen
   methode: decompositie
      • relatieschema's die niet voldoen aan de eisen opdelen in kleinere
        relatieschema's die wel voldoen

• een goede decompositie van een schema
   – bevat dezelfde informatie
   – bevat geen onnodige relaties
   – is efficiënt te onderhouden
• Notatie: voor een relatie R noteren we
   –   het relatieschema : SR
   –   de attributenverzameling van SR : UR
   –   een verz. afhankelijkheden van SR : FR
   –   SR = < UR, FR >
• Definitie: decompositie

Def:
Een verzameling relatieschema's
     (SR) = {SR1 , SR2 , ..., SRk}    (k > 1)
is een decompositie van SR a.s.a. UR = UR1  UR2  ...  URk .
voorbeelden

• SR met UR = ABCD
   –    1(SR) = {SR1 , SR2 }      met UR1 = ABC, UR2 = BCD
   –    2(SR) = {SR1 , SR2 }      met UR1 = AB, UR2 = CD
   –    3(SR) = {SR1, SR2, SR3}   met UR1 = AB, UR2 = BC, UR3 = AD
   –    4(SR) = {SR1, SR2, SR3}   met UR1=AB,    UR2=BCD, UR3=ABC


•  2:
   – disjuncte attribuutverzamelingen  verband tussen bepaalde
      gegevens gaat verloren

•  4:
   – bevat redundante gegevens:    UR1  UR3
• afhankelijkheden in een relatieschema kunnen oorzaak
  zijn van
   – redundantie
   – problemen bij onderhoud (anomalieën)
• als er dergelijke afhankelijkheden zijn in een schema:
   – via decompositie verwijderen
• normaalvormen leggen afwezigheid van
  afhankelijkheden in relatieschema's op
• normaliseren
  = voor elke relatie in de gegevensbank een
  decompositie bepalen zo dat alle resulterende relaties
  in een bepaalde normaalvorm zijn
• Opeenvolgende normaalvormen:
   –   1NF:    eerste normaalvorm
   –   2NF:    tweede normaalvorm
   –   3NF:    derde normaalvorm
   –   BCNF:   Boyce-Codd normaalvorm
   –   4NF:    vierde normaalvorm
   –   5NF:    vijfde normaalvorm
   –   DKNF:   domain-key normaalvorm
• Elke NF speciaal geval van vorige
als aanloop tot normaalvormen: enkele
definities
        Def: K is een supersleutel voor een relatie R met schema SR = <U,F>
              a.s.a.
        K  U en K  U  F+

Een supersleutel determineert elk attribuut in R;
of nog: voor een supersleutel K geldt KF+ = U

        Def: K is een sleutel of kandidaatsleutel voor een relatie R met
        schema SR = <U,F>
               a.s.a.
        K een supersleutel is voor R
        en geen enkele echte deelverzameling van K een supersleutel is voor R



          Def: een attribuut A is een sleutelattribuut voor een relatie R met
          schema SR = <U,F>
                  a.s.a.
          er bestaat een sleutel K voor R waarvoor geldt A  K
• primaire sleutel
   – = één uit de kandidaatsleutels gekozen sleutel

   – attributen in primaire sleutel mogen nooit nul zijn


• alternatieve sleutel
   – = een kandidaatsleutel die niet als primaire sleutel gekozen is
voorbeeld

• Supersleutel EMPLOYEE
   – {Ssn, Ename}, {Ssn, Ename, Bdate}
   – Elke verzameling van attributen die Ssn bevat=supersleutel
• Sleutel
   – {Ssn}
nulde normaalvorm

Een relatieschema SR = <U,F> is in de nulde normaalvorm :

er zijn geen voorwaarden opgelegd aan de attributen (m.a.w. ze
mogen samengesteld of meerwaardig zijn)
eerste normaalvorm

Def: Een relatieschema SR = <U,F> is in de eerste normaalvorm
     a.s.a.
het domein van elk attribuut van U enkelvoudig is.
– m.a.w. geen verzamelingen of tupels als waarde van een attribuut
  toegelaten
– relatie in 1NF brengen :
    • samengesteld attribuut in meerdere attributen opsplitsen
    • voor meerwaardig attribuut meerdere tupels voorzien of nieuwe relatie creëren met
      zelfde sleutel
– nieuwe gegevensbank bevat zelfde informatie als oospronkelijke

– Merk op: er is geen enkele eis gesteld aan de verzameling functionele
  afhankelijkheden F
DLOCATIONS: meerwaardig attribuut: niet in 1 NF
daarom: ofwel
- splitsen in 2 relaties (zoals in voorbeeld vroeger
reeds is gebeurd)
- een tupel voor elke locatie: primaire sleutel
vergroot en redundantie neemt toe:
  zie (c)
samengestelde attributen die
zelf meerwaardig zijn
(= geneste relaties) :
zijn ook niet toegelaten

normalisatie:
geneste attributen  naar
een nieuwe relatie (+ primaire
sleutel)
tweede normaalvorm

 • Voornamelijk van historisch belang, als aanloop tot 3NF

    Def: Als X  Y, dan zeggen we dat Y partieel functioneel
    afhankelijk is van X
    indien er een Z  X bestaat zodat Z  Y;
    anders noemen we Y volledig functioneel afhankelijk van X.


 Def: Een relatieschema SR = <U,F> is in de tweede normaalvorm
 a.s.a.
 voor geen enkel niet-sleutelattribuut A van U geldt dat A partieel
 functioneel afhankelijk is van een kandidaatsleutel van R.

m.a.w.: voor elk niet-sleutel-attribuut moet de hele primaire sleutel nodig
zijn om het te determineren
voorbeeld 2

  • sleutel is StudNr,CursCode
  • CursNaam echter volledig bepaald door CursCode




StudNr   CursCode   CursNaam   InschrDatum   SCCode SCNaam
methode 1NF  2NF

• Gegeven SR1 = < UR1, FR1 > in 1NF
• Voor elk attribuut A dat partieel functioneel afhankelijk is
  van een kandidaatsleutel K:
   – zoek een subset K' in K waarvan A volledig functioneel
     afhankelijk is
   – Elimineer A uit UR1
   – Maak een nieuw relatieschema SR2 met attributenverzameling
     UR2 = K'  A
voorbeeld



StudNr     CursCode    CursNaam   InschrDatum   SCCode SCNaam




StudNr     CursCode    InschrDatum   SCCode SCNaam


CursCode    CursNaam
oefening
CAR_SALE
Car        Date_Sold   Salesman   Commission   Discount




                   2NF?
DERDE NORMAALVORM
transitieve functionele afhankelijkheden

   Def: Een functionele afhankelijkheid X  Y is een triviale functionele
   afhankelijkheid
         a.s.a.
   Y  X.

  Def: Een functionele afhankelijkheid X->Y is een transitieve functionele
  afhankelijkheid
         a.s.a.
  er een Z bestaat zodat volgende 3 voorwaarden voldaan zijn:
   1. Z is volledig en niet-triviaal functioneel afhankelijk van X
   2. Z is geen (echte of onechte) deelverzameling van een kandidaatsleutel
   3. Y is niet-triviaal functioneel afhankelijk van Z

  We zeggen dat Y transitief functioneel afhankelijk is van X via Z.


             X          Z         Y
voorbeeld

• SR < UR, FR >
  met UR = A B C en FR = { A  B, B  C }
  met een mogelijke extensie:


        A       B        C
        A1      b1       c1
        a2      b1       c1
        a3      b2       c2

• A  C is een transitieve functionele afhankelijkheid
• A is een kandidaatsleutel van R
• C is transitief afhankelijk van de kandidaatsleutel A via B
derde normaalvorm

   Def: Een 2NF-relatieschema SR = <U,F> is in de derde normaalvorm
          a.s.a.
   voor geen enkel niet-sleutelattribuut A van U geldt:
   A is transitief functioneel afhankelijk van een of andere
   kandidaatsleutel van de relatie R.



Alternatieve definitie:

  Def: Een 1NF-relatieschema SR = < U,F> is in de derde normaalvorm
         a.s.a.
  voor elke niet-triviale functionele afhankelijkheid X  A van F+
  geldt:
         A is een sleutelattribuut
  of     X is een supersleutel voor R.
voorbeeld


• SCNaam is volledig bepaald door SCCode




StudNr   CursCode   InschrDatum   SCCode   SCNaam
methode 2NF  3NF

• Gegeven SR1 = < UR1,FR1 > in 2NF
• Voor elk niet-sleutelattribuut A dat transitief functioneel
  afhankelijk is van een kandidaatsleutel via Z:
   – Elimineer A uit UR1
   – Maak een nieuw relatieschema SR2 met attributenverzameling
     UR2 = Z  A
voorbeeld



StudNr    CursCode    InschrDatum    SCCode   SCNaam




 StudNr    CursCode    InschrDatum   SCCode


SCCode      SCNaam
oefening
CAR_SALE
Car        Date_Sold   Salesman   Commission   Discount




                   2NF? 3NF?
boyce-codd normaalvorm
• Bij 3NF zijn binnen sleutels nog functionele afhankelijkheden
  toegestaan
• Deze wegwerken  BCNF

    Def: Een 3NF-relatieschema SR = <U,F> is in Boyce-Codd normaalvorm
           a.s.a.
    voor geen enkel sleutelattribuut A van U geldt:
    A is partieel of transitief functioneel afhankelijk van een of andere
    kandidaatsleutel van R.

Of nog:


    Def: Een 1NF-relatieschema SR = <U,F> is in Boyce-Codd normaalvorm
          a.s.a.
    voor elke niet-triviale functionele afhankelijkheid X  A in F+ geldt
    dat X een supersleutel is.
methode 3NF  BCNF

• zoals 1NF  2NF  3NF, maar met sleutelattributen
• BCNF ideaal m.b.t. functionele afhankelijkheden?
   – ja:
       • alle ongewenste functionele afhankelijkheden zijn weg
   – helaas:
       • niet steeds bereikbaar zonder andere problemen te
         creëren...
       • sommige f.a. worden moeilijker te controleren
       • zie ook verder
voorbeeld

• stel dat inschrijvingsdatum eenduidig CursCode bepaalt
   – bij voorbeeld omdat inschrijvingen voor cursussen enkel
     gedurende bepaalde dagen kunnen (die verschillen voor elke
     cursus)
• onderstaand schema is in 3NF, niet in BCNF




            StudNr   CursCode     InschrDatum   SCCode
opsplitsing naar BCNF


   StudNr    CursCode     InschrDatum   SCCode




 StudNr     InschrDatum   SCCode          InschrDatum   CursusCode

Redundantie is verwijderd;
maar: de f.a.     StudNr, CursCode  InschrDatum, SCCode
wordt moeilijker te controleren!
FD5: oppervlakte van de
                                  loten bepaalt
                                  COUNTY




FD2 gaat verloren in deze BCNF normalisatie




 in 3NF, niet in BCNF
VRAGEN?

More Related Content

Similar to Functionele afhankelijkheden en normalisatie

20130221 GB les 3
20130221 GB les 320130221 GB les 3
20130221 GB les 3mleeuwen
 
relationele algebra en relationele calculus
relationele algebra en relationele calculusrelationele algebra en relationele calculus
relationele algebra en relationele calculusKatrien Verbert
 
Fis 03functions
Fis 03functionsFis 03functions
Fis 03functions
roy-de-zomer
 
Fis 04recursion
Fis 04recursionFis 04recursion
Fis 04recursion
roy-de-zomer
 
Les 1 inleiding, betekenis afgeleide en rekenregels
Les 1 inleiding, betekenis afgeleide en rekenregelsLes 1 inleiding, betekenis afgeleide en rekenregels
Les 1 inleiding, betekenis afgeleide en rekenregels
Karel de Grote Hogeschool
 
Integraalrekening 1 les 2
Integraalrekening 1 les 2Integraalrekening 1 les 2
Integraalrekening 1 les 2
Bart Habraken
 
Integraalrekening 1 les 5
Integraalrekening 1 les 5Integraalrekening 1 les 5
Integraalrekening 1 les 5
Bart Habraken
 
gebruik van quantoren in relationele calculus
gebruik van quantoren in relationele calculusgebruik van quantoren in relationele calculus
gebruik van quantoren in relationele calculusKatrien Verbert
 
Integraalrekening 1 les 3
Integraalrekening 1 les 3Integraalrekening 1 les 3
Integraalrekening 1 les 3
Bart Habraken
 
Inleiding matlab
Inleiding matlabInleiding matlab
Inleiding matlabtechna05
 
Handleiding r aw van der vaart
Handleiding r   aw van der vaartHandleiding r   aw van der vaart
Handleiding r aw van der vaartdarkhomey
 

Similar to Functionele afhankelijkheden en normalisatie (13)

Relationele algebra
Relationele algebra Relationele algebra
Relationele algebra
 
20130221 GB les 3
20130221 GB les 320130221 GB les 3
20130221 GB les 3
 
relationele algebra en relationele calculus
relationele algebra en relationele calculusrelationele algebra en relationele calculus
relationele algebra en relationele calculus
 
Fis 03functions
Fis 03functionsFis 03functions
Fis 03functions
 
Fis 04recursion
Fis 04recursionFis 04recursion
Fis 04recursion
 
Les 1 inleiding, betekenis afgeleide en rekenregels
Les 1 inleiding, betekenis afgeleide en rekenregelsLes 1 inleiding, betekenis afgeleide en rekenregels
Les 1 inleiding, betekenis afgeleide en rekenregels
 
Gegevensbanken 2010 les14
Gegevensbanken 2010 les14Gegevensbanken 2010 les14
Gegevensbanken 2010 les14
 
Integraalrekening 1 les 2
Integraalrekening 1 les 2Integraalrekening 1 les 2
Integraalrekening 1 les 2
 
Integraalrekening 1 les 5
Integraalrekening 1 les 5Integraalrekening 1 les 5
Integraalrekening 1 les 5
 
gebruik van quantoren in relationele calculus
gebruik van quantoren in relationele calculusgebruik van quantoren in relationele calculus
gebruik van quantoren in relationele calculus
 
Integraalrekening 1 les 3
Integraalrekening 1 les 3Integraalrekening 1 les 3
Integraalrekening 1 les 3
 
Inleiding matlab
Inleiding matlabInleiding matlab
Inleiding matlab
 
Handleiding r aw van der vaart
Handleiding r   aw van der vaartHandleiding r   aw van der vaart
Handleiding r aw van der vaart
 

More from Katrien Verbert

Explainability methods
Explainability methodsExplainability methods
Explainability methods
Katrien Verbert
 
Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?
Katrien Verbert
 
Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?
Katrien Verbert
 
Human-centered AI: how can we support lay users to understand AI?
Human-centered AI: how can we support lay users to understand AI?Human-centered AI: how can we support lay users to understand AI?
Human-centered AI: how can we support lay users to understand AI?
Katrien Verbert
 
Explaining job recommendations: a human-centred perspective
Explaining job recommendations: a human-centred perspectiveExplaining job recommendations: a human-centred perspective
Explaining job recommendations: a human-centred perspective
Katrien Verbert
 
Explaining recommendations: design implications and lessons learned
Explaining recommendations: design implications and lessons learnedExplaining recommendations: design implications and lessons learned
Explaining recommendations: design implications and lessons learned
Katrien Verbert
 
Designing Learning Analytics Dashboards: Lessons Learned
Designing Learning Analytics Dashboards: Lessons LearnedDesigning Learning Analytics Dashboards: Lessons Learned
Designing Learning Analytics Dashboards: Lessons Learned
Katrien Verbert
 
Human-centered AI: towards the next generation of interactive and adaptive ex...
Human-centered AI: towards the next generation of interactive and adaptive ex...Human-centered AI: towards the next generation of interactive and adaptive ex...
Human-centered AI: towards the next generation of interactive and adaptive ex...
Katrien Verbert
 
Explainable AI for non-expert users
Explainable AI for non-expert usersExplainable AI for non-expert users
Explainable AI for non-expert users
Katrien Verbert
 
Towards the next generation of interactive and adaptive explanation methods
Towards the next generation of interactive and adaptive explanation methodsTowards the next generation of interactive and adaptive explanation methods
Towards the next generation of interactive and adaptive explanation methods
Katrien Verbert
 
Personalized food recommendations: combining recommendation, visualization an...
Personalized food recommendations: combining recommendation, visualization an...Personalized food recommendations: combining recommendation, visualization an...
Personalized food recommendations: combining recommendation, visualization an...
Katrien Verbert
 
Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...
Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...
Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...
Katrien Verbert
 
Learning analytics for feedback at scale
Learning analytics for feedback at scaleLearning analytics for feedback at scale
Learning analytics for feedback at scale
Katrien Verbert
 
Interactive recommender systems and dashboards for learning
Interactive recommender systems and dashboards for learningInteractive recommender systems and dashboards for learning
Interactive recommender systems and dashboards for learning
Katrien Verbert
 
Interactive recommender systems: opening up the “black box”
Interactive recommender systems: opening up the “black box”Interactive recommender systems: opening up the “black box”
Interactive recommender systems: opening up the “black box”
Katrien Verbert
 
Interactive Recommender Systems
Interactive Recommender SystemsInteractive Recommender Systems
Interactive Recommender Systems
Katrien Verbert
 
Web Information Systems Lecture 2: HTML
Web Information Systems Lecture 2: HTMLWeb Information Systems Lecture 2: HTML
Web Information Systems Lecture 2: HTML
Katrien Verbert
 
Information Visualisation: perception and principles
Information Visualisation: perception and principlesInformation Visualisation: perception and principles
Information Visualisation: perception and principles
Katrien Verbert
 
Web Information Systems Lecture 1: Introduction
Web Information Systems Lecture 1: IntroductionWeb Information Systems Lecture 1: Introduction
Web Information Systems Lecture 1: Introduction
Katrien Verbert
 
Information Visualisation: Introduction
Information Visualisation: IntroductionInformation Visualisation: Introduction
Information Visualisation: Introduction
Katrien Verbert
 

More from Katrien Verbert (20)

Explainability methods
Explainability methodsExplainability methods
Explainability methods
 
Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?
 
Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?Human-centered AI: how can we support end-users to interact with AI?
Human-centered AI: how can we support end-users to interact with AI?
 
Human-centered AI: how can we support lay users to understand AI?
Human-centered AI: how can we support lay users to understand AI?Human-centered AI: how can we support lay users to understand AI?
Human-centered AI: how can we support lay users to understand AI?
 
Explaining job recommendations: a human-centred perspective
Explaining job recommendations: a human-centred perspectiveExplaining job recommendations: a human-centred perspective
Explaining job recommendations: a human-centred perspective
 
Explaining recommendations: design implications and lessons learned
Explaining recommendations: design implications and lessons learnedExplaining recommendations: design implications and lessons learned
Explaining recommendations: design implications and lessons learned
 
Designing Learning Analytics Dashboards: Lessons Learned
Designing Learning Analytics Dashboards: Lessons LearnedDesigning Learning Analytics Dashboards: Lessons Learned
Designing Learning Analytics Dashboards: Lessons Learned
 
Human-centered AI: towards the next generation of interactive and adaptive ex...
Human-centered AI: towards the next generation of interactive and adaptive ex...Human-centered AI: towards the next generation of interactive and adaptive ex...
Human-centered AI: towards the next generation of interactive and adaptive ex...
 
Explainable AI for non-expert users
Explainable AI for non-expert usersExplainable AI for non-expert users
Explainable AI for non-expert users
 
Towards the next generation of interactive and adaptive explanation methods
Towards the next generation of interactive and adaptive explanation methodsTowards the next generation of interactive and adaptive explanation methods
Towards the next generation of interactive and adaptive explanation methods
 
Personalized food recommendations: combining recommendation, visualization an...
Personalized food recommendations: combining recommendation, visualization an...Personalized food recommendations: combining recommendation, visualization an...
Personalized food recommendations: combining recommendation, visualization an...
 
Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...
Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...
Explaining and Exploring Job Recommendations: a User-driven Approach for Inte...
 
Learning analytics for feedback at scale
Learning analytics for feedback at scaleLearning analytics for feedback at scale
Learning analytics for feedback at scale
 
Interactive recommender systems and dashboards for learning
Interactive recommender systems and dashboards for learningInteractive recommender systems and dashboards for learning
Interactive recommender systems and dashboards for learning
 
Interactive recommender systems: opening up the “black box”
Interactive recommender systems: opening up the “black box”Interactive recommender systems: opening up the “black box”
Interactive recommender systems: opening up the “black box”
 
Interactive Recommender Systems
Interactive Recommender SystemsInteractive Recommender Systems
Interactive Recommender Systems
 
Web Information Systems Lecture 2: HTML
Web Information Systems Lecture 2: HTMLWeb Information Systems Lecture 2: HTML
Web Information Systems Lecture 2: HTML
 
Information Visualisation: perception and principles
Information Visualisation: perception and principlesInformation Visualisation: perception and principles
Information Visualisation: perception and principles
 
Web Information Systems Lecture 1: Introduction
Web Information Systems Lecture 1: IntroductionWeb Information Systems Lecture 1: Introduction
Web Information Systems Lecture 1: Introduction
 
Information Visualisation: Introduction
Information Visualisation: IntroductionInformation Visualisation: Introduction
Information Visualisation: Introduction
 

Functionele afhankelijkheden en normalisatie

  • 1. functionele afhankelijkheden en normalisatie – deel 1 Katrien Verbert katrien.verbert@cs.kuleuven.be
  • 2. inhoud • informele richtlijnen voor het ontwerp van een gegevensbank • een voorbeeld van normalisatie • functionele afhankelijkheden • normaalvormen (1e, 2e, 3e, Boyce-Codd)
  • 3. ontwerp van relationele gegevensbanken • verschillende benaderingen: 1. via hoogniveau modellering: • werkelijkheid analyseren • ER-schema bouwen • ER-schema omzetten naar relationeel gegevensbankschema 2. meteen een relationeel gegevensschema bouwen • informele richtlijnen • technieken, algoritmes – belangrijk begrip: normaliseren • belangrijke punten: – minimale redundantie, maximale performantie, ...
  • 5. informele richtlijnen 1. Ontwerp een relatieschema zo dat zijn betekenis gemakkelijk verklaard kan worden – betekenis van attributen moet duidelijk zijn – betekenis van relatie moet duidelijk zijn
  • 6. informele richtlijnen 2. Ontwerp een relatieschema zo dat redundantie vermeden wordt en geen toevoeg-, weglaat- of wijziging-anomalieën voorkomen
  • 8. problemen bij toevoegen ( "toevoeg-anomalieën”) EMP_DEPT EName SSN Bdate Address Dnumber Dname Dmgr • nieuwe werknemer toevoegen – nieuwe gegevens moeten consistent zijn met bestaande departement gegevens – null waarden als geen dept info voorhanden is • hoe een departement toevoegen dat nog geen werknemers heeft?
  • 9. weglaat-anomalieën EMP_DEPT EName SSN Bdate Address Dnumber Dname Dmgr • laatste werknemer uit een departement weg  alle info over dat departement ook weg!
  • 10. wijziging-anomalieën EMP_DEPT EName SSN Bdate Address Dnumber Dname Dmgr • bv. manager van dept 5 wijzigen  wijziging moet in alle tupels van EMP_DEPT gebeuren, anders wordt gegevensbank inconsistent
  • 11. informele richtlijnen 3. Vermijd zoveel mogelijk attributen waarvan de waarden nul kunnen zijn – nul = niet van toepassing / onbekend / nog niet geregistreerd
  • 12. informele richtlijnen 4. Ontwerp relatieschema's zo dat ze na een join met = op attributen die primaire of verwijssleutels zijn, geen onechte tupels opleveren
  • 13. slechte voorstelling van de EMP_PROJ relatie: door twee relaties EMP_LOCS en EMP_PROJ1
  • 14. resultaat van natuurlijke join op de tuples boven de stippellijn: er worden onechte tupels ingevoerd
  • 15. voorbeeld van normalisatie • "Kaartenbak"-voorbeeld – context: "open universiteit" • Kaarten met gegevens over: – StudentNr, Naam, Cursus – Cursus = • Code, Titel, InschrijvingsDatum, StudiecentrumCode, StudiecentrumNaam • een student kan meerdere cursussen volgen –  Cursus is een meerwaardig samengesteld attribuut • niet toegelaten in relationeel model! • weghalen van meerwaardige / samengestelde attributen  "eerste normaalvorm"
  • 16. • Bekijk gegevens: welke kunnen aanleiding geven tot anomalieën? – waar is er redundantie? – m.a.w. welke gegevens volgen uit andere? • Identificatie van afhankelijkheden • Herwerken van relatieschema's –  2e en 3e normaalvorm
  • 17. functionele afhankelijkheden • Definitie Zij gegeven een relatieschema R = {A1, A2, ..., An} en attributenverzamelingen X en Y. We zeggen dat Y functioneel afhankelijk is van X, genoteerd X  Y, als en slechts als 1. X   2.  mogelijke extensies r van R: t1, t2  r en t1[X] = t2[X]  t1[Y] = t2[Y] Merk op: "voor alle mogelijke extensies" (= eigenschap van relatieSCHEMA) hangt af van betekenis van de relatie! uit die betekenis volgen nl. bepaalde restricties waaraan de extensies moeten voldoen
  • 18. doel van functionele afhankelijkheden • expliciet beschrijven van bepaalde restricties waaraan de relatie steeds moet voldoen • vb: relatie EMP_PROJ – SSN  ENAME – PNUMBER  { PNAME, PLOCATION } – { SSN,PNUMBER }  HOURS • notatie in schema's: via pijlen, bv: SSN PNUMBER HOURS ENAME PNAME PLOCATION
  • 19. TEXT  COURSE ? kan niet besloten worden uit de extensie maar niet TEACHER  COURSE want een tegenvoorbeeld is in de extensie aanwezig
  • 20. afleidingsregels voor functionele afhankelijkheden • een verzameling functionele afhankelijkheden van R kan nieuwe functionele afhankelijkheden impliceren – bv. A  B en B  C impliceert A  C – Notatie: { A  B, B  C } |= A  C • afleidingsregels voor functionele afhankelijkheden – laten toe alle functionele afhankelijkheden te vinden die door een verzameling F van functionele afhankelijkheden geïmpliceerd worden • sluiting van F, genoteerd F+, – is de verzameling van alle f.a. die door F geïmpliceerd worden
  • 21. voorbeeld • F={Ssn{Ename, Bdate, Address, Dnumber}, Dnumber {Dname, Dmgr_ssn}} • Functionele afhankelijkheden afgeleid uit F – Ssn  {Dname, Dmgr_ssn} – Ssn  Ssn – Dnumber  Dname
  • 22. basis afleidingsregels • FD1. reflexiviteitsregel: Y  X  X  Y • FD2. uitbreidingsregel: { X  Y } |= XZ  YZ • FD3. transitiviteitsregel: { X  Y, Y  Z } |= X  Z
  • 23. basisregels zijn correct en volledig • correct (of "gezond", Eng. "sound") – alle afhankelijkheden die afgeleid kunnen worden, worden ook werkelijk geïmpliceerd • volledig – alle afhankelijkheden die geïmpliceerd worden, kunnen ook met de regels afgeleid worden
  • 24. bewijs van correctheid – FD1 en FD3: bewijs als oefening – FD2: { X  Y } |= XZ  YZ Bewijs FD2: X  Y betekent:  t1, t2 : t1[X] = t2[X]  t1[Y] = t2[Y]. Voor eender welke 2 tupels t1, t2 waarvoor geldt t1[XZ] = t2[XZ], geldt: t1[XZ] = t2[XZ]  t1[X] = t2[X] en t1[Z] = t2[Z]  t1[Y] = t2[Y] en t1[Z] = t2[Z] (uit X  Y)  t1[YZ] = t2[YZ] We hebben dus  t1, t2 : t1[XZ] = t2[XZ]  t1[YZ] = t2[YZ] wat equivalent is met XZ  YZ.
  • 25. extra afleidingsregels • FD4: decompositieregel { X  YZ } |= X  Y • FD5: verenigingsregel { X  Y, X  Z } |= { X  YZ } • FD6: pseudo-transitiviteitsregel { X  Y, WY  Z } |= WX  Z Uit X Y X Z Z volgt: W W
  • 26. bewijs FD4-6 • ofwel via definitie, ofwel via FD1-3 (die immers correct en volledig zijn) • vb: bewijs FD4: { X  YZ } |= { X  Y } – 1: X  YZ (geg) – 2: uit FD1 volgt YZ  Y – uit (1) en (2) via FD3: XY
  • 27. hoe alle functionele afhankelijkheden in een relatieschema vinden? • uit betekenis van relaties en attributen:  verzameling afhankelijkheden F – onvermijdelijk: afhankelijkheden volgen uit betekenis • via afleidingsregels worden alle functionele afhankelijkheden bekomen die uit F volgen: F+ • hoe: – voor elke verzameling attributen X, die links in een funct. afhankelijkheid van F voorkomt, bepaal XF+ • XF+ ("sluiting van X t.o.v. F"): – = verzameling van alle attributen die funct. bepaald zijn door X • algoritme: – voor elke X  Y  F, bepaal XF+ met de afleidingsregels
  • 28. • Algoritme: bepaal XF+, sluiting van X onder F XF+ := X herhaal oldXF+ := XF+ voor elke Y  Z in F : als Y  XF+ dan XF+ := XF+  Z tot (oldXF+ = XF+) XF+ soms genoteerd X+ (indien geen verwarring m.b.t. F mogelijk is)
  • 29. Voorbeeld: EMP_PROJ • F = { SSN  ENAME, PNUMBER  { PNAME, PLOCATION }, { SSN, PNUMBER }  HOURS } • Sluitingen t.o.v. F zijn dan: – { SSN }+ = { SSN, ENAME } – { PNUMBER }+ = { PNUMBER, PNAME, PLOCATION } – { SSN, PNUMBER }+ = { SSN, PNUMBER, ENAME, PNAME, LOCATION, HOURS}
  • 30. oefening • G={Ssn  {Ename, Bdate, Address, Dnumber}, Dnumber  {Dname, Dmgr_ssn}} • {Ssn}+? XF+ := X • {Dnumber}+? herhaal oldXF+ := XF+ voor elke Y  Z in F : als Y  XF+ dan XF+ := XF+  Z tot (oldXF+ = XF+)
  • 31. oplossing • G={Ssn  {Ename, Bdate, Address, Dnumber}, Dnumber  {Dname, Dmgr_ssn}} • {Ssn}+={Ssn, Ename, Bdate, Address, Dnumber, Dname, Dmgr_ssn} • {Dnumber}+={Dnumber, Dname, Dmgr_ssn}
  • 32. overdekking, equivalentie • Zij E en F verzamelingen f.a. van R • E wordt overdekt door F a.s.a. E  F+ – alle f.a. in E volgen uit F via afleidingsregels – automatisch ook E+  F+ • E en F zijn equivalent a.s.a. E+ = F+ • Nagaan of F E overdekt: – voor alle X  Y in E: bepaal XF+ en controleer of Y  XF+
  • 33. oefening • Relatie R{A,B,C,D,E,F,G} • Met afhankelijkheden – AB – BC  DE – AEF  G • Sluiting {A,C,F}+? • Kan ACFDF afgeleid worden uit deze verzameling?
  • 34. oefening • Overdekt F de verzameling E? E = {A  BC, D  AE} F = {A  B, AB  C, D  AC, D  E} Nagaan of F E overdekt: voor alle X  Y in E: bepaal XF+ en controleer of Y  XF+
  • 35. oplossing • Overdekt F de verzameling E? E = {A  BC, D  AE} F = {A  B, AB  C, D  AC, D  E} voor alle X  Y in E: bepaal XF+ en controleer of Y  XF+ • A  BC – AF+={A, B, C} – BC  {A, B, C} • D  AE – DF+={D, A, C, E, B} – AE  {D, A, C, E, B}
  • 36. oefening • Overdekt E de verzameling F? E = {A  BC, D  AE} F = {A  B, AB  C, D  AC, D  E} voor alle X  Y in F: bepaal XE+ en controleer of Y  XE+ • AB • D  AC – A+E={A, B, C} – D+E= {D, A, E, B, C} – B  {A, B, C} – AC  {D, A, E, B, C} • AB  C • DE – AB+E={A, B, C} – D+E={D, E, A, C, B} – C  {A, B, C} – E  {D, E, A, C, B}
  • 37. minimale verzameling functionele afhankelijkheden • F is een minimale verzameling a.s.a. er geen equivalente verzameling G is te vormen door het weglaten van – een afhankelijkheid uit F – of een attribuut uit de rechterkant van een afhankelijkheid in F – of een attribuut uit de linkerkant van een afhankelijkheid in F • E is een minimale overdekking van F a.s.a. E F overdekt en minimaal is
  • 38. stelling • een verzameling f.a. F is minimaal als – rechterlid van elke afhankelijkheid een singleton is •  geen attribuut kan weggelaten worden uit rechterlid – en geen enkele strikte deelverzameling van F equivalent is met F • geen afhankelijkheid kan weggelaten worden – en voor geen enkele X  A van F bestaat er een echte deelverzameling Z  X waarvoor F { X  A }  { Z  A } equivalent is met F • geen attr. kan weggelaten worden uit linkerlid
  • 39. – Algoritme voor berekening van een minimale overdekking G van F: G := F voor elke X  A1A2...An in G (met n > 1) : G := G {X  A1A2...An}  {X  A1, ..., X  An} voor elke X  A in G : voor elke B  X : X' := X {B} G' := G {X  A}  {X'  A} als B  X’G’+ dan G := G' voor elke X  A in G : G' := G {X  A} als A  XG'+ dan G := G’ {G is een minimale overdekking van F}
  • 40. voorbeeld • E: {BA, DA, ABD} • Stap 1 = OK
  • 41. Voorbeeld: stap 2 • E: {BA, DA, ABD} • ABD : Vervangen door BD? – F={BA, DA, BD} – A  B+F? – B+F={B, A, D}  vervanging OK! • E: {BA, DA, BD}
  • 42. voorbeeld: stap 3 • E: {BA, DA, BD} • BA : Weglaten? – E’= {DA, BD} – A  B+E’? – B+E’={B, D, A}  weglating OK! • E: {DA, BD}
  • 43. oefening • Afhankelijkheden – {M, S}  {P, C} – {S}  {Y} – {M}  {N} – {N,Y}  {P} • Bereken minimale verzameling
  • 44. oplossing stap 1 • Afhankelijkheden – {M, S}  {C} – {M, S}  {P} – {S}  {Y} – {M}  {N} – {N,Y}  {P} • Welke afhankelijkheden kunnen weggelaten worden?
  • 45. oplossing • minimale verzameling afhankelijkheden G – {M, S}  {C} – {S}  {Y} – {M}  {N} – {N,Y}  {P} • Want {M,S}  P afleidbaar uit G – {M,S}G+={M, S, C, Y, N, P} – P  {M,S}G+
  • 46. normaalvormen • afhankelijkheden in een relatieschema kunnen oorzaak zijn van – redundantie van gegevens in een extensie – problemen bij het onderhoud • daarom: – indeling van relatieschema’s in groepen op grond van soorten afhankelijkheden: NORMAALVORMEN – hoe hoger de normaalvorm, des te minder afhankelijkheden zich kunnen voordoen
  • 47. normaalvormen • een normaalvorm legt bepaalde eisen op aan relaties • normalisatie = relatie in een bepaalde normaalvorm brengen methode: decompositie • relatieschema's die niet voldoen aan de eisen opdelen in kleinere relatieschema's die wel voldoen • een goede decompositie van een schema – bevat dezelfde informatie – bevat geen onnodige relaties – is efficiënt te onderhouden
  • 48. • Notatie: voor een relatie R noteren we – het relatieschema : SR – de attributenverzameling van SR : UR – een verz. afhankelijkheden van SR : FR – SR = < UR, FR > • Definitie: decompositie Def: Een verzameling relatieschema's (SR) = {SR1 , SR2 , ..., SRk} (k > 1) is een decompositie van SR a.s.a. UR = UR1  UR2  ...  URk .
  • 49. voorbeelden • SR met UR = ABCD –  1(SR) = {SR1 , SR2 } met UR1 = ABC, UR2 = BCD –  2(SR) = {SR1 , SR2 } met UR1 = AB, UR2 = CD –  3(SR) = {SR1, SR2, SR3} met UR1 = AB, UR2 = BC, UR3 = AD –  4(SR) = {SR1, SR2, SR3} met UR1=AB, UR2=BCD, UR3=ABC •  2: – disjuncte attribuutverzamelingen  verband tussen bepaalde gegevens gaat verloren •  4: – bevat redundante gegevens: UR1  UR3
  • 50. • afhankelijkheden in een relatieschema kunnen oorzaak zijn van – redundantie – problemen bij onderhoud (anomalieën) • als er dergelijke afhankelijkheden zijn in een schema: – via decompositie verwijderen • normaalvormen leggen afwezigheid van afhankelijkheden in relatieschema's op • normaliseren = voor elke relatie in de gegevensbank een decompositie bepalen zo dat alle resulterende relaties in een bepaalde normaalvorm zijn
  • 51. • Opeenvolgende normaalvormen: – 1NF: eerste normaalvorm – 2NF: tweede normaalvorm – 3NF: derde normaalvorm – BCNF: Boyce-Codd normaalvorm – 4NF: vierde normaalvorm – 5NF: vijfde normaalvorm – DKNF: domain-key normaalvorm • Elke NF speciaal geval van vorige
  • 52. als aanloop tot normaalvormen: enkele definities Def: K is een supersleutel voor een relatie R met schema SR = <U,F> a.s.a. K  U en K  U  F+ Een supersleutel determineert elk attribuut in R; of nog: voor een supersleutel K geldt KF+ = U Def: K is een sleutel of kandidaatsleutel voor een relatie R met schema SR = <U,F> a.s.a. K een supersleutel is voor R en geen enkele echte deelverzameling van K een supersleutel is voor R Def: een attribuut A is een sleutelattribuut voor een relatie R met schema SR = <U,F> a.s.a. er bestaat een sleutel K voor R waarvoor geldt A  K
  • 53. • primaire sleutel – = één uit de kandidaatsleutels gekozen sleutel – attributen in primaire sleutel mogen nooit nul zijn • alternatieve sleutel – = een kandidaatsleutel die niet als primaire sleutel gekozen is
  • 54. voorbeeld • Supersleutel EMPLOYEE – {Ssn, Ename}, {Ssn, Ename, Bdate} – Elke verzameling van attributen die Ssn bevat=supersleutel • Sleutel – {Ssn}
  • 55. nulde normaalvorm Een relatieschema SR = <U,F> is in de nulde normaalvorm : er zijn geen voorwaarden opgelegd aan de attributen (m.a.w. ze mogen samengesteld of meerwaardig zijn)
  • 56. eerste normaalvorm Def: Een relatieschema SR = <U,F> is in de eerste normaalvorm a.s.a. het domein van elk attribuut van U enkelvoudig is. – m.a.w. geen verzamelingen of tupels als waarde van een attribuut toegelaten – relatie in 1NF brengen : • samengesteld attribuut in meerdere attributen opsplitsen • voor meerwaardig attribuut meerdere tupels voorzien of nieuwe relatie creëren met zelfde sleutel – nieuwe gegevensbank bevat zelfde informatie als oospronkelijke – Merk op: er is geen enkele eis gesteld aan de verzameling functionele afhankelijkheden F
  • 57. DLOCATIONS: meerwaardig attribuut: niet in 1 NF daarom: ofwel - splitsen in 2 relaties (zoals in voorbeeld vroeger reeds is gebeurd) - een tupel voor elke locatie: primaire sleutel vergroot en redundantie neemt toe: zie (c)
  • 58. samengestelde attributen die zelf meerwaardig zijn (= geneste relaties) : zijn ook niet toegelaten normalisatie: geneste attributen  naar een nieuwe relatie (+ primaire sleutel)
  • 59. tweede normaalvorm • Voornamelijk van historisch belang, als aanloop tot 3NF Def: Als X  Y, dan zeggen we dat Y partieel functioneel afhankelijk is van X indien er een Z  X bestaat zodat Z  Y; anders noemen we Y volledig functioneel afhankelijk van X. Def: Een relatieschema SR = <U,F> is in de tweede normaalvorm a.s.a. voor geen enkel niet-sleutelattribuut A van U geldt dat A partieel functioneel afhankelijk is van een kandidaatsleutel van R. m.a.w.: voor elk niet-sleutel-attribuut moet de hele primaire sleutel nodig zijn om het te determineren
  • 60. voorbeeld 2 • sleutel is StudNr,CursCode • CursNaam echter volledig bepaald door CursCode StudNr CursCode CursNaam InschrDatum SCCode SCNaam
  • 61. methode 1NF  2NF • Gegeven SR1 = < UR1, FR1 > in 1NF • Voor elk attribuut A dat partieel functioneel afhankelijk is van een kandidaatsleutel K: – zoek een subset K' in K waarvan A volledig functioneel afhankelijk is – Elimineer A uit UR1 – Maak een nieuw relatieschema SR2 met attributenverzameling UR2 = K'  A
  • 62. voorbeeld StudNr CursCode CursNaam InschrDatum SCCode SCNaam StudNr CursCode InschrDatum SCCode SCNaam CursCode CursNaam
  • 63.
  • 64. oefening CAR_SALE Car Date_Sold Salesman Commission Discount 2NF?
  • 66. transitieve functionele afhankelijkheden Def: Een functionele afhankelijkheid X  Y is een triviale functionele afhankelijkheid a.s.a. Y  X. Def: Een functionele afhankelijkheid X->Y is een transitieve functionele afhankelijkheid a.s.a. er een Z bestaat zodat volgende 3 voorwaarden voldaan zijn: 1. Z is volledig en niet-triviaal functioneel afhankelijk van X 2. Z is geen (echte of onechte) deelverzameling van een kandidaatsleutel 3. Y is niet-triviaal functioneel afhankelijk van Z We zeggen dat Y transitief functioneel afhankelijk is van X via Z. X Z Y
  • 67.
  • 68. voorbeeld • SR < UR, FR > met UR = A B C en FR = { A  B, B  C } met een mogelijke extensie: A B C A1 b1 c1 a2 b1 c1 a3 b2 c2 • A  C is een transitieve functionele afhankelijkheid • A is een kandidaatsleutel van R • C is transitief afhankelijk van de kandidaatsleutel A via B
  • 69. derde normaalvorm Def: Een 2NF-relatieschema SR = <U,F> is in de derde normaalvorm a.s.a. voor geen enkel niet-sleutelattribuut A van U geldt: A is transitief functioneel afhankelijk van een of andere kandidaatsleutel van de relatie R. Alternatieve definitie: Def: Een 1NF-relatieschema SR = < U,F> is in de derde normaalvorm a.s.a. voor elke niet-triviale functionele afhankelijkheid X  A van F+ geldt: A is een sleutelattribuut of X is een supersleutel voor R.
  • 70. voorbeeld • SCNaam is volledig bepaald door SCCode StudNr CursCode InschrDatum SCCode SCNaam
  • 71. methode 2NF  3NF • Gegeven SR1 = < UR1,FR1 > in 2NF • Voor elk niet-sleutelattribuut A dat transitief functioneel afhankelijk is van een kandidaatsleutel via Z: – Elimineer A uit UR1 – Maak een nieuw relatieschema SR2 met attributenverzameling UR2 = Z  A
  • 72. voorbeeld StudNr CursCode InschrDatum SCCode SCNaam StudNr CursCode InschrDatum SCCode SCCode SCNaam
  • 73.
  • 74.
  • 75. oefening CAR_SALE Car Date_Sold Salesman Commission Discount 2NF? 3NF?
  • 76.
  • 77. boyce-codd normaalvorm • Bij 3NF zijn binnen sleutels nog functionele afhankelijkheden toegestaan • Deze wegwerken  BCNF Def: Een 3NF-relatieschema SR = <U,F> is in Boyce-Codd normaalvorm a.s.a. voor geen enkel sleutelattribuut A van U geldt: A is partieel of transitief functioneel afhankelijk van een of andere kandidaatsleutel van R. Of nog: Def: Een 1NF-relatieschema SR = <U,F> is in Boyce-Codd normaalvorm a.s.a. voor elke niet-triviale functionele afhankelijkheid X  A in F+ geldt dat X een supersleutel is.
  • 78. methode 3NF  BCNF • zoals 1NF  2NF  3NF, maar met sleutelattributen • BCNF ideaal m.b.t. functionele afhankelijkheden? – ja: • alle ongewenste functionele afhankelijkheden zijn weg – helaas: • niet steeds bereikbaar zonder andere problemen te creëren... • sommige f.a. worden moeilijker te controleren • zie ook verder
  • 79. voorbeeld • stel dat inschrijvingsdatum eenduidig CursCode bepaalt – bij voorbeeld omdat inschrijvingen voor cursussen enkel gedurende bepaalde dagen kunnen (die verschillen voor elke cursus) • onderstaand schema is in 3NF, niet in BCNF StudNr CursCode InschrDatum SCCode
  • 80. opsplitsing naar BCNF StudNr CursCode InschrDatum SCCode StudNr InschrDatum SCCode InschrDatum CursusCode Redundantie is verwijderd; maar: de f.a. StudNr, CursCode  InschrDatum, SCCode wordt moeilijker te controleren!
  • 81. FD5: oppervlakte van de loten bepaalt COUNTY FD2 gaat verloren in deze BCNF normalisatie in 3NF, niet in BCNF