Functionele afhankelijkheden en normalisatie
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Functionele afhankelijkheden en normalisatie

on

  • 6,219 views

 

Statistics

Views

Total Views
6,219
Views on SlideShare
5,860
Embed Views
359

Actions

Likes
1
Downloads
140
Comments
0

4 Embeds 359

https://cygnus.cc.kuleuven.be 293
http://www.slideshare.net 60
https://canis-major.cc.kuleuven.be 5
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Functionele afhankelijkheden en normalisatie Presentation Transcript

  • 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, ...
  • 4. waarom minder goed ontwerp?
  • 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
  • 7. redundante informa-e 
  • 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 rela-e:  door twee rela-es EMP_LOCS en EMP_PROJ1 
  • 14. resultaat van natuurlijke join op de tuples boven de s-ppellijn:  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}+? •  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 A→D? –  F={B→A, D→A, A→D} –  B ∈ A+F? –  A+F={A, D} → vervanging niet OK! •  E: {B→A, D→A, AB→D}
  • 42. 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}
  • 43. 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}
  • 44. oefening •  Afhankelijkheden –  {M, S} → {P, C} –  {S} → {Y} –  {M} → {N} –  {N,Y} → {P} •  Bereken minimale verzameling
  • 45. oplossing stap 1 •  Afhankelijkheden –  {M, S} → {C} –  {M, S} → {P} –  {S} → {Y} –  {M} → {N} –  {N,Y} → {P} •  Welke afhankelijkheden kunnen weggelaten worden?
  • 46. 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+
  • 47. 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
  • 48. 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
  • 49. •  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 .
  • 50. 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
  • 51. •  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
  • 52. •  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
  • 53. 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
  • 54. •  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
  • 55. voorbeeld •  Supersleutel EMPLOYEE –  {Ssn, Ename}, {Ssn, Ename, Bdate} –  Elke verzameling van attributen die Ssn bevat=supersleutel •  Sleutel –  {Ssn}
  • 56. 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)
  • 57. 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
  • 58. DLOCATIONS: meerwaardig aPribuut: niet in 1 NF  daarom: ofwel     ‐ splitsen in 2 rela-es (zoals in voorbeeld vroeger  reeds is gebeurd)  ‐  een tupel voor elke loca-e: primaire sleutel  vergroot en redundan-e neemt toe:         zie (c) 
  • 59. samengestelde aPributen die  zelf meerwaardig zijn   (= geneste rela-es) :   zijn ook niet toegelaten  normalisa-e:  geneste aPributen → naar   een nieuwe rela-e (+ primaire  sleutel) 
  • 60. 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
  • 61. voorbeeld 2 •  sleutel is StudNr,CursCode •  CursNaam echter volledig bepaald door CursCode StudNr CursCode CursNaam InschrDatum SCCode SCNaam
  • 62. 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
  • 63. voorbeeld StudNr CursCode CursNaam InschrDatum SCCode SCNaam StudNr CursCode InschrDatum SCCode SCNaam CursCode CursNaam
  • 64. oefening CAR_SALE Car  Date_Sold  Salesman  Commission  Discount  2NF?
  • 65. DERDE NORMAALVORM
  • 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. 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
  • 68. 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.
  • 69. voorbeeld •  SCNaam is volledig bepaald door SCCode StudNr CursCode InschrDatum SCCode SCNaam
  • 70. 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
  • 71. voorbeeld StudNr CursCode InschrDatum SCCode SCNaam StudNr CursCode InschrDatum SCCode SCCode SCNaam
  • 72. oefening CAR_SALE Car  Date_Sold  Salesman  Commission  Discount  2NF? 3NF?
  • 73. 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.
  • 74. 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
  • 75. 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
  • 76. 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!
  • 77. FD5: oppervlakte van de loten bepaalt COUNTY FD2 gaat verloren in deze BCNF normalisatie in 3NF, niet in BCNF
  • 78. VRAGEN?