Relasjonsdatabasedesign

En entitet er et konkret objekt vi vil lagre data om — f.eks. studenten "Knut Moen" med fnr 17059812345.

En entitetstype er klassen eller skjemaet for like entiteter — f.eks. Student som mal for alle studenter.

I ER-diagrammer tegner vi typer, ikke individuelle entiteter — rektangler representerer entitetstyper, og hver tabell i relasjonsskjemaet svarer til én entitetstype. Tilsvarende: i SQL er CREATE TABLE Student typen, hver rad er en entitet.

Pensum: Kap. 4A — Entiteter og attributter

Enkelt: én atomær verdi (alder, fnr). Tegnes som ovalt med enkel ramme.

Komposit: består av flere subattributter — Adresse → (gate, postnr, by). Tegnes som ovalt med subovaler hengende på.

Flerverdi: kan ha flere verdier per entitet (en person har flere telefonnumre). Tegnes med dobbel ramme. Kan ikke ligge direkte i tabellen — krever egen tabell ved oversettelse.

Derivert: kan beregnes ut fra annet (Alder fra Fødselsdato). Tegnes med stiplet ramme. Lagres typisk ikke — beregnes ved spørring for å unngå redundans.

Pensum: Kap. 4A — Attributter

Supernøkkel: en attributtmengde som unikt identifiserer en entitet. Trenger ikke være minimal.

Kandidatnøkkel: en minimal supernøkkel — fjerner du en attributt, mister du unikheten.

Primærnøkkel: den kandidatnøkkelen designeren velger. Får PRIMARY KEY i DDL og blir mål for fremmednøkler. Ofte basert på praktiske kriterier (kortest, mest stabil).

Eksempel: i Bruker(fnr, epost, brukerid, navn) der alle tre første er unike — supernøkler inkluderer {fnr}, {epost}, {fnr, navn}, {fnr, epost, brukerid}; kandidatnøkler er {fnr}, {epost}, {brukerid}; primærnøkkel velger man én av disse tre.

Forhold: PK ⊂ kandidatnøkler ⊂ supernøkler.

Pensum: Kap. 4A — Nøkler

1:1: Hver entitet på én side er knyttet til høyst én på den andre. (En person ↔ ett pass.)

1:N: En 1-side kan være knyttet til mange N-er, men hver N kobles til høyst én 1-er. (En avdeling har mange ansatte; hver ansatt har én avdeling.)

M:N: Begge sider kan ha mange. (Studenter ↔ Emner.)

Hvorfor det betyr noe ved oversettelse: 1:1 og 1:N kan løses med en fremmednøkkel-kolonne. M:N krever en mellomtabell — det er ingen "én side" å plassere FK-en på.

Pensum: Kap. 4A — Relasjoner og kardinalitet

Total deltakelse (obligatorisk): hver entitet i settet må delta i relasjonen. Tegnes med dobbel linje mellom entitet og relasjon.

Partiell deltakelse (valgfri): noen entiteter kan stå utenfor relasjonen. Tegnes med enkel linje.

Eksempel: Hvis hver Ansatt MÅ jobbe i en Avdeling, er Ansatt-siden total. Hvis en Avdeling KAN være tom, er Avdeling-siden partiell.

Konsekvens for skjema: total deltakelse oversettes til NOT NULL på fremmednøkkelen. Partiell tillater null-verdier.

Pensum: Kap. 4A — Deltakelse

En svak entitet har ingen egen primærnøkkel — den kan ikke identifiseres alene. Den «låner» nøkkelen fra en eier-entitet (sterk entitet) gjennom en identifiserende relasjon (tegnet med dobbel diamant).

For å skille svake entiteter med samme eier brukes en diskriminator (delnøkkel). Primærnøkkelen blir {eierens PK, diskriminator}.

Eksempel: Avhengig(navn) er en svak entitet eid av Ansatt. Avhengighetens identitet er (Ansatt.fnr, navn) — to ansatte kan ha avhengige med samme navn, men ingen ansatt har to avhengige med samme navn.

I ER-diagrammet: dobbel ramme rundt entiteten, og deltakelsen mot eieren er alltid total.

Pensum: Kap. 4A — Svake entiteter

Riktig: A.

(min, max)-notasjonen leses som: hver entitet på denne siden må delta i mellom min og max instanser av relasjonen.

(1,1) på Ansatt-siden = total deltakelse + maks 1 → hver ansatt jobber i nøyaktig én avdeling. (0, *) på Avdeling-siden = partiell deltakelse + ubegrenset → en avdeling kan ha 0 eller mange ansatte. Sum: 1:N med total deltakelse fra Ansatt-siden.

B snur betydningen av (1,1) og (0,*). C antar total fra begge sider — feil siden Avdeling har min=0. D er feil — siden Ansatt har max=1, kan dette ikke være M:N.

Pensum: Kap. 4A — Notasjon for kardinalitet

En identifiserende relasjon kobler en svak entitet til sin eier. Den er nødvendig fordi den svake entiteten henter halvparten av primærnøkkelen sin (eierens nøkkel) gjennom relasjonen.

I ER-diagrammet tegnes den som en dobbel diamant. Deltakelsen fra svak side er alltid total — hadde det ikke vært en eier, kunne den svake entiteten heller ikke eksistert (eksistens-avhengighet).

Ved oversettelse blir den identifiserende relasjonen ikke en egen tabell — den er allerede uttrykt gjennom FK-en i den svake entitetens tabell.

Pensum: Kap. 4A — Svake entiteter

(1) Kommunikasjon. ER-diagram er et språk stakeholders forstår uten å være DBA. Det er enklere å validere modellens regler ("én ansatt jobber alltid i én avdeling, ja?") enn DDL.

(2) Strukturell tenkning. Du tvinges til å skille entitet (eget identitetsobjekt) fra attributt (egenskap) fra relasjon (kobling). Hopper man over, ender man ofte med en bred tabell som blander.

(3) Mekanisk oversettelse. Når ER er ferdig og normalisert, er DDL nesten avskrivning — hvert valg om svake entiteter, kardinalitet og deltakelse er allerede gjort.

Resultatet: færre iterasjoner og bedre normalisert resultat.

Pensum: Kap. 4 — Hvorfor design

Lag én tabell med samme navn som entiteten. Én kolonne per atomært attributt. Primærnøkkelen blir entitetens primærnøkkel.

Eksempel: Student med fnr (PK), navn, fødselsdato → Student(fnr, navn, fødselsdato).

Komposite attributter «flatpakkes» — Person med Adresse(gate, postnr, by) gir kolonnene gate, postnr, by direkte i Person-tabellen, ikke en samletekst.

Flerverdi-attributter må bli en egen tabell (se eget kort) — de kan ikke ligge inni hovedtabellen uten å bryte 1NF.

Pensum: Kap. 4B — Sterke entiteter

Et flerverdi-attributt blir en egen tabell med to kolonner: FK til eier-entiteten + selve verdien. PK = kombinasjonen.

Eksempel: Student(fnr, navn) med flerverdi-attributtet Telefon:

• Student(fnr, navn)
• StudentTelefon(fnr [FK→Student], telefon)

Hvorfor: 1NF tillater ingen multi-set-celler. En kolonne med {tlf1, tlf2, tlf3} bryter atomaritet. Å duplisere studentraden per telefon ville gitt redundans i navn/fnr og åpnet for oppdateringsanomali.

Pensum: Kap. 4B — Attributter

I M:N kan en A peke på flere B-er, og en B peke på flere A-er. En enkelt FK-kolonne kan kun lagre én verdi per rad — det dekker bare 1:N.

Den eneste lossless representasjonen er en junction table (mellomtabell) med to FK-kolonner og kombinasjonen som primærnøkkel:

Student M:N Emne → StudentTarEmne(fnr [FK→Student], emnekode [FK→Emne], semester, karakter)

Eventuelle attributter på selve relasjonen (semester, karakter) plasseres i mellomtabellen — de hører ikke hjemme i Student eller Emne alene.

Pensum: Kap. 4B — Relasjoner

Riktig: C.

Tommelfingerregel: i 1:1 plasseres FK-en på siden som har total deltakelse. Da garanterer NOT NULL at FK-en faktisk peker, og UNIQUE sikrer at ingen person har flere pass.

A er overkill — ingen redundans å unngå, og en mellomtabell kompliserer joins. B fjerner skillet og bryter 3NF hvis Person har attributter som ikke hører til Pass. D ville krevd at FK-en kan være null (siden ikke alle personer har pass), og er konseptuelt mer rotete enn C — men ville fungere teknisk hvis vi godtok null + UNIQUE-på-not-null.

Pensum: Kap. 4B — Relasjoner

Tabellen får:

• Eierens primærnøkkel (FK + del av PK).
• Diskriminatoren (også del av PK).
• Alle attributter på den svake entiteten.

PK = {eierens PK, diskriminator}. FK-en mot eieren markeres typisk ON DELETE CASCADE for å reflektere eksistens-avhengigheten.

Eksempel: Avhengig(ansatt_fnr [FK→Ansatt], navn, fødselsdato, relasjon).

Den identifiserende relasjonen blir ikke en egen tabell — den er allerede uttrykt gjennom FK-en i den svake entitetens tabell.

Pensum: Kap. 4B — Svake entiteter

Riktig: C.

Eksemplar er en svak entitet — eier=Bok, diskriminator=kopinr. Mappes til en tabell med eierens nøkkel (ISBN) + diskriminator (kopinr) som sammensatt PK + svake attributter (hyllenr). FK på ISBN bør ha ON DELETE CASCADE.

A: kollapser alt til én tabell — bryter 1NF/3NF (én bok kan ha mange eksemplarer; hyllenr blir flerverdi). B: gjør Eksemplar til sterk entitet med kunstig nøkkel og taper eksistens-avhengigheten — eks_id sier ingenting om koblingen til Bok. D: blander attributter feil — tittel/forfatter hører til Bok, hyllenr til Eksemplar.

Pensum: Kap. 4B — Svake entiteter

I et dårlig skjema Ansatt(fnr, navn, avd_navn, avd_budsjett):

Innsettingsanomali: Vil legge inn ny avdeling som ennå ikke har ansatte → kan ikke uten falsk Ansatt-rad eller null på fnr (som er PK).

Sletteanomali: Sletter siste ansatt i en avdeling → informasjonen om avdelingens budsjett forsvinner med raden.

Oppdateringsanomali: Endrer du budsjettet, må alle ansatte-rader oppdateres samtidig. Glemmer du én, blir tabellen inkonsistent.

Løsning: del i Ansatt(fnr, navn, avd_id) + Avdeling(avd_id, navn, budsjett). Hvert faktum lagres nøyaktig ett sted.

Pensum: Kap. 4B — Anomalier

(1) Konsistensbyrde: Du må sørge for at alle kopier oppdateres samtidig. SQL gir ingen automatisk garanti — hver UPDATE må eksplisitt oppdatere alle kopiene.

(2) Anomalier: Innsetting krever dummy-data, sletting taper informasjon, oppdatering kan glemme rader.

(3) Plass: Sekundært. Disk er billig, men store, repetisjonstunge tabeller laster bufferet og senker spørringer.

Normalisering eliminerer redundans ved å spalte tabeller slik at hvert ikke-key-faktum lagres bare én gang. Resultatet: integritet håndheves strukturelt (av skjemaet) i stedet for prosedyralt (av applikasjonskoden).

Pensum: Kap. 4B — Motivasjon for normalisering

For ethvert lovlig forekomst av relasjonen: hvis to rader er like på X-attributtene, er de også like på Y-attributtene. Det er en constraint på dataene — uavhengig av aktuelle innstanser.

FD-er stammer fra reglene i den modellerte verden, ikke fra konkrete data. Du kan ikke lese dem ut av en eksempeltabell — du må vite hva som må holde.

Eksempel: I Bil(regnr, modell, eierfnr, eier_navn) holder:
• regnr → modell, eierfnr (regnr identifiserer bilen unikt)
• eierfnr → eier_navn (personnummer er unikt per person)

Men ikke eier_navn → eierfnr — flere personer kan hete det samme.

Pensum: Kap. 4C — Funksjonelle avhengigheter

En FD X → Y er triviell hvis Y ⊆ X. Den følger automatisk av definisjonen og gir ingen informasjon om relasjonen.

Eksempel: AB → A er triviell. AB → AC er delvis triviell (delen AB → A) men ikke fullstendig triviell.

En ikke-triviell FD er X → Y der minst én attributt i Y ikke er med i X — f.eks. AB → C der C ikke er i AB.

Hvorfor det betyr noe: alle definisjoner av normalformer (3NF, BCNF) krever bare at ikke-trivielle FD-er tilfredsstilles. Hvis vi krevde alle FD-er, ville BCNF være umulig — trivielle FD-er finnes overalt.

Pensum: Kap. 4C — FD-er

Tre regler som er fullstendige (kan utlede alle gyldige FD-er) og sunne (utleder bare gyldige):

1. Refleksivitet: Hvis Y ⊆ X, så X → Y. (Trivielle FD-er holder alltid.)

2. Augmentasjon: Hvis X → Y, så XZ → YZ. (Begge sider kan utvides med samme attributter.)

3. Transitivitet: Hvis X → Y og Y → Z, så X → Z. (FD-er kan kjedes.)

Avledede regler (utledet fra aksiomene, men praktiske):

• Union: X→Y, X→Z ⊢ X→YZ
• Dekomposisjon: X→YZ ⊢ X→Y, X→Z
• Pseudotransitivitet: X→Y, WY→Z ⊢ WX→Z

Aksiomene danner basis for lukningsalgoritmen {X}⁺.

Pensum: Kap. 4C — Armstrongs aksiomer

Riktig: D — {A, B, C, D, E}.

Iterativ algoritme: start med X⁺ = {A, C}, anvend FD-er til fix-punkt.

1. Start: {A, C}.
2. A → B: A er i settet → legg til B. Nå {A, B, C}.
3. BC → D: BC er i settet → legg til D. Nå {A, B, C, D}.
4. D → E: D er i settet → legg til E. Nå {A, B, C, D, E}.
5. Ingen flere FD-er kan utvides — fix-punkt nådd.

Siden lukningen er hele R, er {A, C} en supernøkkel.

A: glemmer å bruke FD-er. B: stopper etter A→B og overser at BC→D nå er bruksbar. C: hopper over A→B og prøver å bruke BC→D før vi har B.

Pensum: Kap. 4C — Lukning

To krav som begge må gjelde:

1. Supernøkkel: {X}⁺ = R (hele attributtmengden). X bestemmer alt.

2. Minimal: for hver delmengde Y ⊊ X, {Y}⁺ ≠ R. Du kan ikke fjerne noen attributt fra X uten å miste supernøkkel-egenskapen.

Algoritme:
• Beregn {X}⁺. Hvis ikke = R → ikke engang supernøkkel, ferdig.
• Ellers, prøv å fjerne hver attributt fra X i tur. Hvis lukningen fortsatt = R, var den attributten redundant — kandidatnøkkelen er mindre.

For å finne alle kandidatnøkler: identifiser attributter som aldri står på høyre side av en FD — de må være med i hver kandidatnøkkel.

Pensum: Kap. 4C — Supernøkler og kandidatnøkler

Riktig: B — bare {A}.

Beregn {A}⁺ = {A,B,C,D} via A→B→C→D. A er supernøkkel, og siden den bare har én attributt er den minimal — altså kandidatnøkkel.

Sjekk de andre: {B}⁺ = {B, C, D} (mangler A); {C}⁺ = {C, D}; {D}⁺ = {D}. Ingen er supernøkkel.

Triks: A står aldri på høyresiden av en FD — derfor må A være med i enhver kandidatnøkkel. Siden {A} alene er supernøkkel, kan ingen større mengde være kandidatnøkkel (de blir ikke-minimale).

A: feil — {A} er supernøkkel. C: feil — {B} er ikke supernøkkel. D: feil av samme grunn.

Pensum: Kap. 4C — Kandidatnøkler

En minimal cover F_c er en FD-mengde ekvivalent med F (samme lukning av enhver attributtmengde) men strippet:

1. Hver høyreside er én attributt (X → A, ikke X → AB).
2. Ingen FD i F_c er redundant (kan fjernes uten å endre lukningen).
3. Ingen attributt på venstresiden er overflødig (kan fjernes fra X uten å miste FD-en).

Hvorfor: 3NF-syntese-algoritmen krever en minimal cover som input. Den lager én tabell per FD i F_c og garanterer da dependency preservation. Uten minimering ville man fått overflødige tabeller.

Algoritmens trinn: (1) splitt høyresider, (2) fjern overflødige LHS-attributter, (3) fjern redundante FD-er. Rekkefølgen betyr noe — annen rekkefølge kan gi en annen, men ekvivalent, minimal cover.

Pensum: Kap. 4C — Dekomponering

Alle attributter i hver rad inneholder atomære (udelelige) verdier — ingen lister, sett eller nestede strukturer.

Eksempel på 1NF-brudd: en kolonne telefoner = "12345, 67890" (kommaseparert liste) eller kompetanse = ['SQL', 'Python'] (array). Hvert datum må stå i egen rad eller egen kolonne med atomær verdi.

I praksis: hvis du må parse innholdet i en celle for å få ut den faktiske verdien, er du ikke i 1NF.

1NF er fundamentet — alle høyere normalformer forutsetter 1NF. Relasjonsmodellen som sådan bygger på 1NF; multiset-kolonner finnes ikke i den.

Pensum: Kap. 4C — Normalstigen

2NF: 1NF + ingen partiell avhengighet av et ikke-prime attributt på en del av en sammensatt kandidatnøkkel.

Konkret: hvis kandidatnøkkelen er sammensatt (f.eks. {A, B}) og det finnes en FD A → C der C er ikke-prime, så er C partielt avhengig av nøkkelen — det bryter 2NF.

Problem som 2NF løser: hvis (StudentID, EmneKode) er nøkkel og StudentNavn avhenger bare av StudentID, gjentas StudentNavn for hver emneregistrering — redundans og oppdateringsanomali.

Spesialtilfelle: hvis alle kandidatnøkler er enkle (én attributt), er skjemaet automatisk i 2NF — det finnes ingen "del av nøkkelen" å være partiell mot.

I praksis: vi går oftest direkte fra 1NF til 3NF/BCNF. 2NF er en pedagogisk mellomstasjon.

Pensum: Kap. 4C — Normalstigen

For hver ikke-triviell FD X → A i F gjelder minst ett av:

1. X er en supernøkkel, ELLER
2. A er medlem av en kandidatnøkkel (et "prime attribute").

3NF stopper det 2NF ikke fanger: transitive avhengigheter mellom ikke-nøkkel-attributter, selv når kandidatnøkkelen er enkel.

Eksempel: Ansatt(fnr, navn, avd_id, avd_navn) med FD-er fnr → avd_id, avd_id → avd_navn. avd_id er ikke-supernøkkel og avd_navn er ikke-prime — så fnr → avd_navn er transitiv via avd_id, og det bryter 3NF (selv om kandidatnøkkelen {fnr} er enkel og 2NF er oppfylt).

Løsning: dele i Ansatt(fnr, navn, avd_id) + Avdeling(avd_id, navn).

Pensum: Kap. 4C — Normalstigen

For hver ikke-triviell FD X → Y som holder, må X være en supernøkkel. Det er den eneste regelen — uten 3NFs unntak for prime-attributter.

Forskjellen: 3NF tillater X → A der A er en del av en kandidatnøkkel, selv om X ikke er supernøkkel. BCNF tillater det ikke.

Klassisk eksempel: R(student, emne, lærer) med FD-er {(student, emne) → lærer; lærer → emne}. Kandidatnøkler: {student, emne} og {student, lærer}. lærer → emne bryter BCNF (lærer er ikke supernøkkel) men oppfyller 3NF (emne er prime).

Konsekvens: BCNF eliminerer mer redundans enn 3NF, men kan tape dependency preservation ved dekomponering.

Pensum: Kap. 4C — BCNF

Riktig: C — 3NF, men ikke BCNF.

Sjekk hver FD:

• AB → C: AB er supernøkkel ✓ (BCNF OK)
• AB → D: AB er supernøkkel ✓ (BCNF OK)
• C → A: {C}⁺ = {C, A}, ikke = R. C er ikke supernøkkel → BCNF-brudd. For 3NF: A er prime (medlem av {A,B}) → 3NF tilfredsstilt.

Skjemaet er altså i 3NF (alle FD-er har enten supernøkkel-LHS eller prime-RHS) men ikke BCNF (C → A bryter). Dette er nettopp det klassiske 3NF/BCNF-gapet.

A: 1NF brytes ikke (alle attributter er atomære). B: krever ikke-prime LHS som er del av sammensatt nøkkel — ikke aktuelt her. D: feil pga C→A.

Pensum: Kap. 4C — BCNF

Riktig: A.

Kandidatnøkkel: {student, emne}. {student, emne}⁺ = {student, emne, lærer, lærer_kontor}. FD lærer → lærer_kontor: lærer er ikke supernøkkel for R → BCNF-brudd.

Dekomp på lærer→lærer_kontor: skill ut R₂(lærer, lærer_kontor). Igjen i R₁(student, emne, lærer): (student, emne) → lærer holder, og (student, emne) er supernøkkel for R₁. R₁ er BCNF.

Lossless: R₁ ∩ R₂ = {lærer}; {lærer}⁺ = {lærer, lærer_kontor} = R₂ → supernøkkel for R₂ ✓

B: dropper lærer fra R₁ — taper FD (student, emne)→lærer; ikke lossless. C: blander attributter feil — lærer mangler i R₁. D: feil, lærer→lærer_kontor bryter BCNF.

Pensum: Kap. 4C — Dekomponering

Dekomponeringen er lossless hvis FD-mengden inneholder minst én av:

• (R₁ ∩ R₂) → (R₁ \ R₂), eller
• (R₁ ∩ R₂) → (R₂ \ R₁)

Med ord: skjæringen mellom de to skjemaene må være supernøkkel for minst ett av dem.

Test:
1. Beregn R₁ ∩ R₂ = mengden felles attributter.
2. Beregn lukningen (R₁ ∩ R₂)⁺ over hele FD-mengden.
3. Hvis lukningen dekker R₁ eller R₂, er joinen lossless.

Hvorfor: hvis X = R₁ ∩ R₂ er supernøkkel for f.eks. R₂, så har hver rad i R₂ en unik X-verdi, og join på X kan rekonstruere R uten "spurious tuples" (falske rekombinasjoner).

For 3+ delskjemaer brukes chase-algoritmen.

Pensum: Kap. 4C — Dekomponering

Riktig: B — Ja, lossless.

Test: R₁ ∩ R₂ = {C}. Beregn {C}⁺ = {C, D, E} = R₂. C er supernøkkel for R₂ → lossless-vilkåret oppfylt.

Du trenger ikke at skjæringen er supernøkkel for begge — bare for én. Her er C ikke supernøkkel for R₁ (mangler A og B), men det spiller ingen rolle.

A: A→B er irrelevant for lossless-testen — kun skjæringen teller. C: korrekt at A→B ikke er relevant, men det medfører ikke nei. D: ingen attributter mistes; alle A,B,C,D,E finnes i R₁ ∪ R₂.

Pensum: Kap. 4C — Lossless join

En dekomponering bevarer FD-er hvis hver FD i den opprinnelige FD-mengden kan håndheves lokalt på ett av delskjemaene — uten å joine tilbake til full R.

Formelt: F₁ ∪ F₂ ∪ … ≡ F (lukningene er ekvivalente), der F_i = projeksjonen av F på R_i.

Hvorfor BCNF kan tape: når du dekomponerer for å fjerne et FD-brudd, kan du måtte splitte attributtene i en FD over to delskjemaer. Da kan FD-en ikke håndheves uten å rekonstruere R, og en INSERT på ett delskjema kan bryte den uten at noen tabell ser bruddet.

Klassisk eksempel: Klasse(student, emne, lærer) med F = {(student, emne) → lærer; lærer → emne}. BCNF-dekomp tvinger oss til å splitte slik at FD (student, emne) → lærer mistes som lokalt bevarbar.

3NF-syntese garanterer alltid både lossless OG dependency preservation. BCNF garanterer lossless, ikke alltid dependency preservation. Det er den klassiske trade-off-en.

Pensum: Kap. 4C — Trade-off

Algoritme:

1. Beregn en minimal cover F_c av F.
2. For hver FD X → A i F_c, lag en tabell {X, A}. Slå sammen FD-er med samme venstreside i samme tabell.
3. Hvis ingen tabell inneholder en kandidatnøkkel for R, legg til en tabell bestående av en kandidatnøkkel.
4. (Valgfritt) Fjern tabeller som er strikte delmengder av andre.

Garantier:

• Alle delskjemaer er i 3NF.
• Lossless join.
• Dependency preserving — alle FD-er i F kan håndheves lokalt.

Forskjellen fra BCNF-dekomp (som er en analyse-algoritme): 3NF-syntese gir alltid dependency preservation; BCNF gjør det ikke nødvendigvis.

Pensum: Kap. 4C — Dekomponering

Hvis et skjema er i 3NF men ikke BCNF, og BCNF-dekomp ville tape dependency preservation, så er valget:

Beholde 3NF: akseptere noe potensiell redundans for å sikre at alle FD-er kan håndheves lokalt (med f.eks. CHECK-constraints eller triggere). Bra hvis FD-en bryter ofte uten dekomp og du ikke vil bruke triggere som ser flere tabeller.

Gå til BCNF: eliminere redundans, men nå må FD-en som tapes håndheves med komplekse triggere som spenner over tabeller — ofte upraktisk og dyrt.

Læreboka anbefaler ofte BCNF i den grad SQL likevel ikke håndhever generelle FD-er effektivt — så «tapt dependency preservation» er mer en teoretisk ulempe enn en praktisk i mange tilfeller. Resultatet: BCNF-dekomp foretrekkes ofte i praksis.

3NF-syntese er likevel et trygt fallback når BCNF-bruddet er kostbart eller du har store triggerbyrder.

Pensum: Kap. 4C — 3NF vs BCNF

1. List opp alle attributter i R og FD-er i F. Skriv FD-er på enkleste form (én attributt på høyre side om mulig).

2. Finn kandidatnøkler. Attributter som aldri står på høyre side må være med i hver kandidatnøkkel. Beregn lukninger og finn minimale supernøkler.

3. Identifiser prime-attributter (attributter som er medlem av minst én kandidatnøkkel).

4. Sjekk hver ikke-triviell FD X → A:

• Er X en supernøkkel? → tilfredsstiller BCNF (og dermed alt under).
• Hvis ikke, er A prime? → tilfredsstiller 3NF, men ikke BCNF.
• Hvis A ikke er prime, sjekk om X ⊊ K for en kandidatnøkkel K → 2NF-brudd. Ellers er det 3NF-brudd via transitiv avhengighet.

5. 1NF antas med mindre du ser tydelige multi-set-kolonner.

Konklusjonen er den laveste normalformen alle FD-er tilfredsstiller.

Pensum: Kap. 4C — Normalstigen

Lossless join: garanterer at vi kan rekonstruere det opprinnelige skjemaet ved å joine delskjemaene — ingen rader oppfinnes, ingen tapes. Uten denne er dekomponeringen i praksis verdiløs: spørringer som krysser delskjemaer gir falske resultater.

Dependency preserving: garanterer at hver opprinnelig FD kan håndheves uten å joine. Uten denne kan en INSERT i ett delskjema bryte en FD som spenner over flere delskjemaer, og databasen blir inkonsistent uten at SQL ser det.

Lossless er obligatorisk. Dependency preservation er ønskelig, men kan ofres for BCNF.

3NF-syntese garanterer begge. BCNF-analyse garanterer lossless, ikke alltid dependency preservation.

Pensum: Kap. 4C — Trade-off

Supernøkkel: enhver attributtmengde som unikt identifiserer rader. Ikke nødvendigvis minimal.

Kandidatnøkkel: minimal supernøkkel. Hver tabell kan ha flere.

Primærnøkkel: den valgte kandidatnøkkelen. SQL-konstrukt: PRIMARY KEY (én per tabell). Markerer NOT NULL og UNIQUE.

Fremmednøkkel (FK): en attributtmengde i tabell A som refererer til primærnøkkelen i tabell B. Sikrer referansiell integritet — verdien må enten være null eller matche en eksisterende rad i B.

Forhold: PK ⊆ kandidatnøkler ⊆ supernøkler. FK er ikke en nøkkel for sin egen tabell — den er en peker.

I ER → relasjon uttrykker FK relasjonen mellom entiteter.

Pensum: Kap. 4A — Nøkler

Vurderingskriterier (i synkende viktighet):

1. Stabilitet: Endrer verdien seg sjelden? Epost kan endres → dårlig kandidat. fnr og brukerid endres aldri → bedre.

2. Kortsthet: En 4-byte heltallsnøkkel indekserer raskere enn en e-poststreng. Mindre cascade-trykk på FK-er.

3. Personvern: fnr er sensitivt — å bruke det som FK i mange tabeller sprer det. Et generert brukerid er ofte tryggere.

4. Garantert tilstedeværelse: PK må være NOT NULL. Hvis attributten kan være ukjent ved innsetting, kan den ikke være PK.

I praksis: ofte velges en surrogat-nøkkel (auto-økende heltall) som PK, og naturlige nøkler (fnr, epost) merkes som UNIQUE NOT NULL. Da har du fleksibilitet uten å miste integriteten.

Pensum: Kap. 4A — Nøkler

Automatisk (fra ER-strukturen):

• Primærnøkkelen til hver entitet bestemmer alle attributter på den entiteten.
• I et 1:N-relasjonsskjema (FK på N-siden) bestemmer N-sidens PK relasjonens attributter.

Modellører må oppgi (utenfor ER):

• FD-er mellom ikke-nøkkel-attributter — f.eks. postnr → by. ER-diagrammet sier ingenting om dette.
• FD-er som spenner over flere entiteter modellert som én tabell.
• Implisitte regler i domenet: "samme prosjekt har én leder", "samme avdeling har ett budsjett".

Disse «ekstra» FD-ene driver normaliseringsanalysen i 4C. Skriver du dem ikke ned, vil 3NF/BCNF-sjekken si "alt OK" — selv om skjemaet har redundans.

Lærdom: ER + FD-er sammen er det fullstendige bildet. ER alene er ikke nok.

Pensum: Kap. 4C — FD-er

Riktig: A — 1NF, men ikke 2NF.

Kandidatnøkkel: {prosjekt, ansatt}. {prosjekt, ansatt}⁺ = R.

Sjekk FD-en prosjekt → prosjektleder: prosjekt er en del av kandidatnøkkelen {prosjekt, ansatt}, og prosjektleder er ikke-prime. Dette er en partiell avhengighet — bryter 2NF.

Konsekvens: prosjektleder gjentas for hver ansatt på samme prosjekt → oppdateringsanomali.

Løsning (3NF/BCNF-dekomp): R₁(prosjekt, ansatt, timer) + R₂(prosjekt, prosjektleder).

B/C/D: alle krever 2NF, som ikke er oppfylt.

Pensum: Kap. 4C — Normalstigen

Riktig: B — {A, B}.

Beregn {A,B}⁺: start {A,B} → AB→C gir C → {A,B,C} → C→D gir D → {A,B,C,D} → D→E gir E → {A,B,C,D,E} = R. Supernøkkel ✓.

Minimalitet: {A}⁺ = {A} (ingen FD med kun A på venstre side); {B}⁺ = {B}. Ingen kan fjernes → {A,B} er minimal → kandidatnøkkel.

A: {A} alene er ikke supernøkkel. C: {A,B,C} er supernøkkel, men ikke minimal — C kan fjernes. D: {C,D}⁺ = {C,D,E}, mangler A og B, så ikke supernøkkel.

Triks: A og B står aldri på høyresiden av en FD — så de må være med i enhver kandidatnøkkel. Da er {A,B} det minste som har sjanse til å være supernøkkel.

Pensum: Kap. 4C — Supernøkler og kandidatnøkler

1. Virkelighet → ER-diagram (4A, lærebok 6.1–6.6). Tegn entiteter, attributter, relasjoner, kardinalitet, deltakelse, svake entiteter. Kommunikasjon med stakeholder.

2. ER-diagram → relasjonsskjema (4B, 6.7+6.9). Mekaniske regler: én tabell per sterk entitet; FK-er for 1:1 og 1:N; mellomtabell for M:N; eierens PK + diskriminator for svake. Komposite "flatpakkes", flerverdi blir egne tabeller.

3. Skjema + FD-mengde → FD-analyse (4C, 7.1–7.2). List FD-er som holder i domenet. Beregn lukninger, finn kandidatnøkler. Identifiser prime/ikke-prime attributter.

4. FD-analyse → normalisert skjema (4C, 7.3+7.6). Sjekk 1NF/2NF/3NF/BCNF. Dekomponer der det finnes brudd — pass på lossless og dependency preservation.

Hvert hopp er mekanisk. Fallgruver kommer av å hoppe over et trinn.

Pensum: Kap. 4 — Designreisen