Difference between revisions of "6238 Databaser Agenda/Normalisering"
(→Unormaliseret tabel) |
(→1. Normalform) |
||
| Line 37: | Line 37: | ||
Nr: 12 | Nr: 12 | ||
| − | |||
===2. Normalform=== | ===2. Normalform=== | ||
Revision as of 16:13, 2 November 2015
Contents
Normalisering
Normalisering er et regelsæt til at kontrollerer at vores database tabeller har en fornuftig struktur.
Oprindelig blev defineret 5 normalformer nummereret fra 1 til 5. Senere kom dog også Boyce-Codd normalformen (BCNF) der i praksis placeres mellem 3. og 4. uden dog at være direkte afhængig af disse.
Her vil vi dog kun tale om de første 3.
Unormaliseret tabel
Her under er vis en unormaliseret tabel som indeholder nogle oplagt fejl. I det efterfølgende vil vi vha. normaliserings reglerne omdanne dette til tabeller der overholder 3. normalform.
1. Normalform
En relation, som er defineret over domæner, hvis elementer er atomare, dvs. udelelige, siges at være normaliseret. En relation er på første normalform, hvis ingen af dens domæner har elementer,der i sig selv er mængder.
I eksemplet herover er Ordrelinier er en mængde i sig selv, og samtidig repeterende, og skal derfor i egen tabel
Et par eksempler på ikke atomare attributter kan være
Navn: Jens Jensen
Adresse: Bygade 12
I stedet anvendes
Fornavn: Jens
Efternavn: Jensen
Gade: Bygade
Nr: 12
2. Normalform
En relation R er på anden normalform, hvis den er på første normalform, og hvisenhver ikke-nøgle-attribut er fuldt funktionelt afhængig af enhver kandidatnøgle i R.
I eksemplet er kundeoplysninger kun afhængig af en del af nøglen, nemlig Knr, ikke hele nøglen. Derfor skal kunde i en tabel for sig.
3. Normalform
En relation R er på tredje normalform, hvis den er på anden normalform og detgælder, at ingen ikke-nøgle-attribut er transitivt afhængig af nogen kandidatnøgle i R.
Selv om By ikke der direkte afhængig af Knr, er by afhængig af Postnr som er afhængig af Knr. Derfor er By transitiv afhængig af Knr og skal i egen tabel.
