3. Funktionelle afhængigheder og normalisering

3. Funktionelle afhængigheder og normalisering

1


Kvalitet i relationer


2

Normalisering 82

• Metoder til database-design– ER-model + konvertering til relationel model

• Top down (start med strukturen)

– Normalisering → relationel model• Baseret på funktionelle afhængigheder• Bottom up (starte med de enkelte data)


3

Funktionelle afh. def. 83

• Funktionel afhængighed i en relation R– ABC → D– Hvis attributterne A, B og C er ens, så skal D også

være ens - for alle tupler, til enhver tid!!– Kræver indgående kendskab til data!– Eksempler

• cpr → navn cpr → adresse• adresse → telefon

– gælder næppe i disse mobil-tider

• postnr → postdistrikt omv. gælder ikke, Viby• cpr, kursusnr → karakter


4

Nøgler, 84

• En nøgle er en mængde af attributter, som alle andre attributter i relationen afhænger af.

• Eksempler– Person (cpr, navn, adr)– Postdistrikt (postnr, distrikt)– Kursus (stud_cpr, kursusnr, tidspunkt,

karakter)


5

Super-nøgler, 86

• Minimal: En nøgle må ikke indeholde unødvendige attributter– Hvis en attribut tage ud af mængden, så

forsvinder nøgle-egenskaben

• Super-nøgle: Mængde af attributter, der indeholder en nøgle + evt. ekstra attributter– En super-nøgle er ikke ekstra god -

tværtimod!


6

Nøgler i ER, 87

• Nøgler i relationelt skema lavet på baggrund af ER– Entity set

• Har allerede nøgle (check minimal)

– Relationship• Nøgle = nøgler fra deltagende entity sets

– Svag entity set• Egen nøgle + nøgle fra "stærke" entity set


7

Regler for funk. afh., 90

• Trivielle afhængigheder– AB…C → A

• Kombiner– AB → C og AB → D, så AB → CD

• Split– AB → CD, så AB → C og AB → D

• Transitiv– A → B og B → C, så A → C


8

Closure, 92

• Aflukningen (closure) af en mængde af attributter:– Alle de attributter, der er afhængige af

attributterne i mængden– Notation: {A, B}+– Hvis X+ er alle attributter i R, så er X

supernøgle i R


9

Design af relationelt skema, 102

• Vi skal undgå relationer med dårlige egenskaber fig. 3.21, side 103– redundans

• Samme information flere gange

– opdaterings-problemer• Opdatering i en tupel, kræver opdatering i andre

tupler

– sletnings-problemer• sletning af en tupel medfører at anden information

slettes.


10

Opdeling af relationer, 103

• Relationer med dårlige egenskaber skal opdeles i flere mindre relationer, der hver især er uden dårlige egenskaber.– Fig. 3.22, side 104– Fig. 3.23, side 105

Movie Star


11

Boyce-Codd normal-form (BCNF), 105

• Normal-form– Reglement for relationer– Høj normalform = få dårlige egenskaber

• BCNF– Hvis X → B (ikke triviel), så er X supernøgle i

relationen.– Enhver determinant (venstre side i funk.

afhængighed) skal være supernøgle.


12

BCNF eksempel

• BCNF eksempel– Person (cpr, navn, adresse, postnr, bynavn)

• cpr → navn, adresse, postnr, bynavn• postnr → bynavn

– Opdeles i • Person2 (cpr, navn, adresse, postnr)• Postdistrikt (postnr, bynavn)


13

Join af relationer, 112

• Opdelte relationer skal kunne samles (join), så de bliver præcis som før– ingen nye (bogus) tupler– ingen manglende tupler


14

3. normal-form (3NF), 114

Svagere udgave af BCNF+ Svagere: Flere dårlige egenskaber

− Mindre opdeling = hurtigere søgning

De-normalisering

Regel:

Hvis X → A (ikke-triviel), så er

X supernøgle eller

A er attribut i en nøgle (ny i forhold til BCNF)


15

3NF eksempel, 114

• Mulige nøgler– {title, city} og {theater, title}

• 3NF OK– City er en del af nøglen {Title, City}

• Brud på BCNF– Theater → City, men Theater er ikke nøgle– Problem: Opdeling {theater, city} for sig selv bryder den

funktionelle afhængighed {title, city} → theater– Løsning: Undladt opdeling, bliv ved 3NF

Title City Theater


16

1NF og 2NF

• 1NFAlle attributter er atomare + alle relationer har en nøgle– Ingen sammensatte attributter

• 2NF Afhængighed af hele nøglen– En attribut må ikke være afhængig af en del af

nøglen.– {cpr, navn, kursusnr, karakter}– cpr → navn kun afhængig af en del af nøglen– Forholdet cpr, navn må ud i en selvstændig relation.


17

The Relational Oath

☺"I promise to use the key, the whole key, and nothing but the key, so help me Codd"

☺Det var Codd, der definerede den relationelle model - og normalformerne.


18

Flerværdi afhængigheder, 118• Multivalued dependencies (MVD)• Generalisering af funk. afhængighed.• 2 mængder af attributter er uafhængige af hinanden.• 2 typer information i samme relation medfører

redundans.• Fig. 3.29 , s. 118 vs.

Star Movie

name street city title year


19

Flerværdi afh. def., 119

A1A2…An → → B1B2…Bk

• Værdierne i B'erne er uafhængige af værdierne af alle andre attributter [end A'erne]

• For alle tupler t, u [ens mht. A'er] eksisterer en tupel v, der er

1. ens med t og u mht. A'er

2. ens med t mht. B'er

3. ens med u mht. alle attributter ikke i A eller B

• Fig. 3.29 side 118 + 120


20

Regler for MVD, 121

• A → → BC medfører ikke A → → B– name → → street holder ikke, da city ikke kan

variere frit

• A → B medfører A → → B– Alm. FD er altså er særtilfælde af MVD


21

4. normalform (4NF), 122• Regler

– A1A2…An → → B1B2…Bk er triviel, hvisi. nogle af B'erne også er blandt A'erne ellerii. A'erne og B'erne tilsammen udgør alle attributterne i relationen

– 4NF• hvis A1A2…An → → B1B2…Bk så skal A1A2…An være en supernøgle

• Hvis en relation ikke overholder 4NF,så må den opdeles i flere mindre relationer, der hver især overholder 4NF.

• Eksempel– name → → street, city– name → → title, year– Opdeles i {name, street, city} og {name, title, year}– Begge afhængigheder er nu trivielle (jf. ii.)


22

Afsluttende kommentarer, 124

• Højere normalform = højere kvalitetskrav– Færre relationer opfylder den høje normalform

end den lave

• Med en instans af en database kan man– ikke påvise funk. afhængigheder– måske afvise funk. afhængigheder

• Funk. afhængigheder må man efterspørge i den modellerede verden.

Documents

3. Funktionelle afhængigheder og normalisering