Den relationelle model Matematisk baggrund for relations-databaser Den relationelle model

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") Den relationelle model

Den relationelle model 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 Den relationelle model

Relationelt skema vs. instans, 64 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. Den relationelle model

Konvertering fra ER-diagram til relationel model, 65 Entity set → relation, inkl. attributter Relationships a. 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. Den relationelle model

Den relationelle model 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) Den relationelle model

Den relationelle model 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) Den relationelle model

Den relationelle model 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) Den relationelle model

Den relationelle model 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! Den relationelle model

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) Den relationelle model

Den relationelle model 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 Den relationelle model

Den relationelle model 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) Den relationelle model

Den relationelle model 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! Den relationelle model

Den relationelle model 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 Den relationelle model

Den relationelle model 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 Den relationelle model

Den relationelle model 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 Den relationelle model

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. Den relationelle model

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 Den relationelle model

Boyce-Codd normal-form (BCNF), 105 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. Den relationelle model

Den relationelle model 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) Den relationelle model

Den relationelle model 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 Den relationelle model

Den relationelle model 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) Den relationelle model

Den relationelle model 3NF eksempel, 114 Title City Theater 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 Den relationelle model

Den relationelle model 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. Den relationelle model

Den relationelle model 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. Den relationelle model

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. Den relationelle model

Den relationelle model 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 ens med t og u mht. A'er ens med t mht. B'er ens med u mht. alle attributter ikke i A eller B Fig. 3.29 side 118 + 120 Den relationelle model

Den relationelle model 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 Den relationelle model

Den relationelle model 4. normalform (4NF), 122 Regler for A1A2…An → → B1B2…Bk er triviel, hvis nogle af B'erne også er blandt A'erne eller 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.) Den relationelle model

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