Den relationelle model

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

2. 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") ER vs. relationelle model, 61 Den relationelle model

3. 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

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

5. 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

6. 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

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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

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

20. 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

21. 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

22. 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

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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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