En database er grundlæggende en samling data der er organiseret i rækker og kolonner. I rækkerne (kaldes også en post) har vi de enkelte opslag og i kolonnerne de kategorier opslaget skal indeholde. Herunder er et skema over mentorfordelingen på en mindre skole.
| Mentor | Klasse 1 | Klasse 2 | Klasse 3 |
|---|---|---|---|
| Thomas Jensen (tj) | 1a (17 elever) | 2a (22 elever) | 3a (21 elever) |
| Bent Andersen (ba) | 1b (16 elever) | 2b (24 elever) | 3b (22 elever) |
| Christina Carlsen (cc) | 1x (28 elever) | 2x (31 elever) | - |
Skemaet ovenfor er let at læse for os, men det for at gøre det til effektiv til en database skal vi anvende normalisering. Normaliseringsprocessen sikrer at data ikke bliver gentaget flere steder og data er entydig. Det man vil undgå er redundans (gentagelser) og inkonsistens (mangel på sammenhæng).
For at undgå redundans og inkonsistens gennemløber man i databasens designfase disse tre trin:
Her kan du finde en (relativ) let gennemgang af normaliseringsprocessen.
- Tabellen har et nøglefelt (behøver ikke at være unikt)
- Der må kun være en værdi af samme type i hver post
- Alle poster skal være lige lange dvs. have samme antal felter
Lige nu er skemaet menneskelæseligt, men for at få tabellen til at opfylde NF1 skal vi have ændret på nogle ting.
Resultatet herunder opfylder de 3 krav til NF1:
| Tabel 1 - Mentorer, klasser og elever | |||
|---|---|---|---|
| Initialer | Mentor | Klasse | Antal elever |
| tj | Thomas Jensen | 1a | 17 |
| tj | Thomas Jensen | 2a | 22 |
| tj | Thomas Jensen | 3a | 21 |
| ba | Bent Andersen | 1b | 16 |
| ba | Bent Andersen | 2b | 24 |
| ba | Bent Andersen | 3b | 22 |
| cc | Christina Carlsen | 1x | 28 |
| cc | Christina Carlsen | 2x | 31 |
- Tabellen opfylder NF1
- Der skal være en nøgle i hver tabel, der entydigt bestemmer indholdet. Kaldes en unik nøgle.
For at opfylde NF2 skal tabellen først opfylde NF1, men derudover skal tabellen have en unik nøgle. Lærerens initialer og navn er ikke unik da samme lærer kan have flere klasser. Herunder vælger vi at klassenavnet skal være den unikke nøgle
| Tabel 1 - Klasser, mentorer og elever | |||
|---|---|---|---|
| Klasse (Nøgle) | Mentor | Navn | Antal elever |
| 1a | tj | Thomas Jensen | 17 |
| 2a | tj | Thomas Jensen | 22 |
| 3a | tj | Thomas Jensen | 21 |
| 1b | ba | Bent Andersen | 16 |
| 2b | ba | Bent Andersen | 24 |
| 3b | ba | Bent Andersen | 22 |
| 1x | cc | Christina Carlsen | 28 |
| 2x | cc | Christina Carlsen | 31 |
- Tabellen opfylder NF2
- Hvis der er mere end et felt der kan sættes som nøgle for andre felter skal tabellen opdeles i flere.
NF 2 sikrer, at vi kan tilgå tabellen igennem en unik nøgle og at den er sammenhængende. Men den bliver hurtig uoverskuelig. Derfor vælger vi at analysere tabellen for om den kan splittes op i mindre tabeller, hvor felter der afhænger af andre får deres egne tabeller.
Her vælger vi at opdele tabellen i 3:
| Tabel 1 - Klasser og mentorer | |||
|---|---|---|---|
| Klasse (Primær nøgle) | Mentor | ||
| 1a | tj | ||
| 2a | tj | ||
| 3a | tj | ||
| 1b | ba | ||
| 2b | ba | ||
| 3b | ba | ||
| 1x | cc | ||
| 2x | cc | ||
og
| Tabel 2 - Mentorer | |||
|---|---|---|---|
| Mentor (Primær nøgle) | Navn | ||
| tj | Thomas Jensen | ||
| ba | Bent Andersen | ||
| cc | Christina Carlsen | ||
og
| Tabel 3 - Klasser og elever | |||
|---|---|---|---|
| Klasse (Primær nøgle) | Antal elever | ||
| 1a | 17 | ||
| 2a | 22 | ||
| 3a | 21 | ||
| 1b | 16 | ||
| 2b | 24 | ||
| 3b | 22 | ||
| 1x | 28 | ||
| 2x | 31 | ||
Fordelen ved at gøre dette er, at vi nu kan tilføje data til tabellerne uden at bryde sammenhængen mellem dem. Vi kan f.eks. udvide tabel 2 og 3 med flere informationer om mentorerne.
| Tabel 2 (udvidet) - Mentorer | ||||
|---|---|---|---|---|
| Mentor (Primær nøgle) | Navn | Lokale | Mobil | |
| tj | Thomas Jensen | 17 | 23344517 | tj@fakemail.dk |
| ba | Bent Andersen | 18 | 23344518 | ba@fakemail.dk |
| cc | Christina Carlsen | 19 | 23344519 | cc@fakemail.dk |
| Tabel 3 (udvidet)- Klasser og elever | |||||
|---|---|---|---|---|---|
| Klasse (Primær nøgle) | Antal elever | Piger | Drenge | Startår | |
| 1a | 17 | 9 | 8 | 2016 | |
| 2a | 22 | 10 | 12 | 2015 | |
| 3a | 21 | 8 | 13 | 2014 | |
| 1b | 16 | 8 | 8 | 2016 | |
| 2b | 24 | 13 | 11 | 2015 | |
| 3b | 22 | 9 | 13 | 2014 | |
| 1x | 28 | 13 | 15 | 2016 | |
| 2x | 31 | 17 | 14 | 2015 | |
Ved at anvende normalisering på vores database får vi en opbygning der sikrer at vi ikke har redundans (gentagelser) og inkonsistens (mangel på sammenhæng) i de enkelte tabeller. Det sikrer også, at tabellen bliver nemmere at vedligeholde og udvide med flere informationer.
Hver eneste gang man udvider sin database bør man sikre sig at databasen overholder de tre normaliseringskrav.