Cursus database ontwerpen

De tweede normaalvorm (2NF)

De tweede normaalvorm: het verwijderen van redundante gegevens

• De database voldoet aan alle regels van de eerste normaalvorm.
• Zo min mogelijk gegevens worden dubbel opgeslagen in de database.
• De velden die geen primaire sleutel zijn, zijn afhankelijk van de primaire sleutel.

Je moet bij de tweede normaalvorm je tabellen goed inspecteren op gegevens die dubbel opgeslagen worden in een kolom. Gegevens die dubbel opgeslagen worden komen in aanmerking voor afsplitsing in een aparte tabel. Een mooi voorbeeld hiervan is het com_type veld in de contactmomententabel. In die kolom worden de waardes 'telefoon', 'email' en 'brief' telkens herhaald. Daar worden gegevens dus dubbel opgeslagen (redundancy) Afsplitsen is hetr devies. We maken een nieuwe tabel voor 'communicatietypes'.

Aan elk contactmoment is een communicatietype gekoppeld door het com_type veld. Dit veld is een vreemde sleutel. Het verwijst naar de primaire sleutel (com_type_id) van de communicatietypentabel.

Op deze manier hoeft een wijziging van de waarde 'telefoon' naar 'telefonisch' maar op 1 plek te gebeuren.

Voor de inkomend_uitgaand kolom geldt ook dat gegevens dubbel opgeslagen worden. Hierin worden 'inkomend' en 'uitgaand' steeds herhaald. Wat is echter de kans dat er ooit een waarde bijkomt? 0. Want met 'inkomend' en 'uitgaand' zijn alle mogelijkheden gedekt. Wat is de kans dat je de waardes 'inkomend' en 'uitgaand' in de toekomst wil wijzigen? Klein. Vandaar dat we de herhaling van waardes in de inkomend_uitgaand kolom toestaan.

Merk overigens op dat er altijd wel een beetje herhaling van gegevens is. Het klantnummer (vreemde sleutel) in de contactmomententabel wordt steeds dubbel opgeslagen, maar dat is herhaling die niet te voorkomen is. We willen immers wel dat elk contactmoment aan een klant gekoppeld is.

1. 1  
2. 2  
3. 3  
4. 4  
5. 5  
6. 6  
7. 7  
8. 8  
9. 9  
10. 10  
11. 11  
12. 12 
13. 13  
14. 14  
15. 15  
16. 16