Øvelse i normalisering / funksjonell avhengighet

Oppgave:

Vi tar utgangspunkt i tabellen Student under. (den burde kanskje heller hatt navnet StudentKurs eller liknande?)
I) Finn determineringar (funksjonelle avhengigheter) i tabellen.
II) Kva normalformer er brotne her?
III) Normaliser databasen ihht 3NF.

Forkortingar: Regno = Registreringsnummer, Fdato = fødselsdato, KID = Kurs-id, Knavn = Kursnavn, Ins = Instruktør.

Løysingsforslag:

I Determineringar:

1) Regno → Navn
– Navn er unikt definert av regno. Med andre ord, for eit gitt Regno, så fins det ett og bare ett navn.
2) Regno → Fdato
-         For kvart registreringsnummer er det nøyaktig ein verdi for Fdato.
3) Regno → Tlf
4) Regno → Kjønn

Dette kan vi oppsummera som:
Regno → Navn, Fdato, Tlf, Kjønn

5) KID → Knavn
?  Knavn → KID
-      Med dei gitte dataene, ser dette ut til å stemma. Men det kan tenkjast at databasekurset DBMS kanskje vil bli gitt i ulike studieprogram, og dermed får ulike kursid.
6) Ins_ID → Ins_Navn, Ins_Kontor (to determineringar). Det kan sjå ut som at vi også har determinering frå Ins_Navn til Ins_Kontor, men det er ikkje utenkjelig at vi kan ha to instruktørar med same navn, men som har forskjellig kontor.

7) Regno + KID → Navn, Fdato, Tlf, Kjønn, Knavn
-  Regno og KID saman, dvs. ein gitt kombinasjon av disse to verdiane, identifiserer unikt verdiane i Navn, Fdato, Tlf, Kjønn og Knavn.
8) Regno + KID + Ins_ID → Navn, Fdato, Tlf, Kjønn, Knavn, Ins_Navn, Ins_Kontor
- Kombinasjonen of Regno, Kid og Ins_id identifiserer altså alle dei andre attributtane i tabellen.
Dette betyr at kombinasjonen (Regno, KID, Ins_ID) er (den samansette) nøkkelen i tabellen Student.

Eksempel på funksjonelle avhengigheter som IKKJE  fins i Student:
TLF → Regno
- Det fins to studentar (med Regno 14B01 og 14B03) som har telefonnummer 23456, så dette stemmer ikkje.
KID → Ins_ID
-  Kurset med KID "C1" blir undervist av både lærar I1 (Kesav) og I2 (Ragav). Det betyr at dette ikkje stemmer.
Fdato→ Regno, Name, TLF, Gender
- Tabellen vår inneheld ingen eksempel på studentar med same fødselsdata, men det kan sjølsagt ikkje utelukkast. Derfor kan det ikkje finnast determinering frå Fdato til disse Regno eller noken annan attributt som er avhengig av Regno.

II Brot på normalformer

1NF: Det ser ikkje ut til at vi har hverken repeterande attributter eller attributter som ikkje er atomiske. Det betyr at tabellen allerede er på 1NF*.
* Men det som kompliserer denne analysen, er at det kan virka som om både Kesav og Ragav underviser kurset C1. I såfall skulle det antagelig stått "Kesav, Ragav" i kolonnen Ins_Navn for alle radene for dette kurset. Og dermed har vi repeterande attributt! Og dette ville sjølsagt også gjelda for kolonnene Ins_ID og Ins_Kontor. Uansett: det vi kan slå fast er at tabellen ikkje dekkjer behovet for datalagring på ein konsistent og effektiv måte.

2NF: Når vi no kjenner nøkkelen, kan vi sjå etter om vi har determineringar frå deler av nøkkelen til ikkje-nøkkelfelt. Og det har vi jo i mange av. Alle determineringane frå Regno åleine (1 - 4), KID åleine (5), Ins_ID åleine (6)  eller kombinasjonar av to av disse (7), er brot på 2NF.
Men merk at 8) ikkje er det, fordi her er det determinering frå heile nøkkelen. Og det både må og skal det vera. Hvis ikkje var det jo ikkje ein nøkkel!
3NF: Slik det ser ut, har vi ingen determineringar frå eit ikkje-nøkkelfelt til andre felt. Men sidan vi har brot på 2NF, så har vi per def. også brot på 3NF.

III Normalisering.

Her er det egentlig lettare å normalisera enn å finna alle brot på normalformene. Opplagt treng vi å dela denne inn i tre tabellar: Student, Kurs og Instruktør.
Student: (Regno, Navn, Fdato, Tlf, Kjønn)
Kurs: (KID, Knavn)
Instruktør: (Ins_ID, Ins_Navn, Ins_Kontor).

I tillegg treng vi to koblingstabellar, fordi både relasjonen mellom Student og Kurs, og mellom Kurs og Instruktør er mange-til-mange. No er vi kvitt determineringane 6 og 7. Vi har igjen 1 - 6, men alle disse er no OK fordi Regno, KID of Ins_ID no er nøklar i kvar sin tabell.

Då blir datamodellen ca. slik: