den relationelle model

Den relationelle model 1

Den relationelle model

Matematisk baggrund for relations-databaser


ER vs. relationelle model, 61

ER-modellen• sprog

– Entity sets– Relationships– Attributes– Sub-klasser

• Systemudvikling– Analyse ("hvad")

Relationelle model• sprog

– Relationer med• Attributter

• Tupler

• Passer til relations-databaser

• Solidt matematisk fundament: Mængdelære

• Systemudvikling– Design ("hvordan")


Terminologi, 61

• Relation (ikke d.s.s. relationship)– 2-dimensional tabel

• Attribut– Kolonne i en tabel

• Skema– Navn på relation + alle attributterne

• Tupel– Række i en relation– Relation består af en mængde af tupler

• Domæne– En mængde af atomiske værdier for en attribut


Relationelt skema vs. instans, 64

Relationelt skema• Strukturen på

relationen.• Defineres [principielt]

en gang for alle.

Relationel instans• Indholdet (data) i

relationen til et bestemt tidspunkt.

• Skifter over tid - data kommer og går.


Konvertering fra ER-diagram til relationel model, 65

1. Entity set → relation, inkl. attributter

2. Relationshipsa. N-M → relation, inkl. attributter + nøgler fra

deltagende entity sets

b. 1-N → integrer attributter + nøgle fra N i 1 relationen

c. 1-1 → integrer (vælg selv i hvilken)

eller slå de 2 entity types helt sammen.


Konvertering II, 71

• Svage entity types → relation inkl. attributter + primærnøgle i tilhørende "stærke" entity type.

• Sub-klasser: Kan ikke udtrykkes direkte i den relationelle model– Flere "hacks" (ikke-perfekte løsninger)


Arv ER-metoden, 77

• Super-typen → 1 relation– Alle generelle data

• 1 relation for hver af sub-typerne– Specifikke data– Nøglen på super-typen– Eksempel

• Person (cpr, navn, adr)• Studerende (cpr, semester)• Lærer (cpr, løn)


Arv, OO metoden78

• En relation for hver type med alle attributter– Data fra sub-typen (specifikke)– Data fra super-typen (generelle)– Eksempel

• Person (cpr, navn, adresse)• Studerende (cpr, navn, adresse, semester)• Lærer (cpr, navn, adresse, løn)


Arv, null metoden 79

• Lav én STOR relation– alle attributter fra super-typen + alle sub-

typerne– mange af attributterne vil have værdien null

• værdien findes ikke

– Eksempel• Person (cpr, navn, adresse, semester, løn)

– semester eller løn er altid null, med mindre man kan være både studerende og lærer!


Funktionelle afhængigheder 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)


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


Nøgler, 84

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

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

karakter)


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!


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


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


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


Design af relationelt skema, 102

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

• Samme information i flere

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

tupler

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

slettes.


Opdeling af relationer, 103

• Relationer med dårlige egenskaber skal opdeles i flere mindre relationer - uden dårlige egenskaber.– Fig. 3.22, side 104– Fig. 3.23, side 105

Movie Star


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.


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)


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


3. normal-form (3NF), 114

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

− Mindre opdeling = hurtigere søgning

De-normalisering

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

X supernøgle eller

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


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


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.


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.


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


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

Rut ,


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


4. normalform (4NF), 122

• Regler for– A1A2…An → → B1B2…Bk er triviel, hvis

i. nogle af B'erne også er blandt A'erne ellerii. A'erne og B'erne tilsammen udgør alle attributterne i relationen

– 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.)


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.

den relationelle model

Documents