We hebben gekeken naar verschillende aspecten van het normaliseren van een databasetabel. Eerst hebben we de basisprincipes van databasenormalisatie besproken. De vorige keer hebben we de basisvereisten besproken die zijn vastgelegd door de eerste normale vorm (1NF). Laten we nu onze reis voortzetten en de principes van de tweede normale vorm (2NF) bespreken.
De algemene vereisten van 2NF
- Verwijder subsets van gegevens die van toepassing zijn op meerdere rijen van een tabel en plaats ze in afzonderlijke tabellen.
- Maak relaties tussen deze nieuwe tabellen en hun voorgangers door het gebruik van externe sleutels.
Deze regels kunnen worden samengevat in een eenvoudige verklaring: 2NF probeert de hoeveelheid overtollige gegevens in een tabel te verminderen door deze uit te pakken, in nieuwe tabel (en) te plaatsen en relaties tussen die tabellen te maken.
Laten we een voorbeeld bekijken. Stel u een online winkel voor die klantinformatie in een database bijhoudt. Ze kunnen een enkele tabel hebben met de naam Klanten met de volgende elementen:
- CustNum
- Voornaam
- Achternaam
- Adres
- stad
- Staat
- ZIP
Een korte blik op deze tabel onthult een kleine hoeveelheid overtollige gegevens. We bewaren de items 'Sea Cliff, NY 11579' en 'Miami, FL 33157' twee keer per keer. Nu lijkt dat in ons eenvoudige voorbeeld misschien niet teveel toegevoegde opslagruimte, maar stel je de verspilde ruimte voor als we duizenden rijen in onze tabel hadden. Als de postcode voor Sea Cliff zou veranderen, zouden we die wijziging op veel plaatsen in de database moeten aanbrengen.
In een 2NF-conforme databasestructuur wordt deze overtollige informatie geëxtraheerd en opgeslagen in een aparte tabel. Onze nieuwe tabel (laten we het ZIP's noemen) kan de volgende velden hebben:
- ZIP
- stad
- Staat
Als we superefficiënt willen zijn, kunnen we deze tabel zelfs van te voren invullen - het postkantoor biedt een directory met alle geldige postcodes en hun relaties tussen stad en staat. Je bent toch een situatie tegengekomen waarbij dit type database werd gebruikt. Iemand die een bestelling neemt, heeft u misschien eerst om uw postcode gevraagd en wist toen de stad en staat van waaruit u gebeld hebt. Dit type opstelling vermindert operatorfouten en verhoogt de efficiëntie.
Nu we de dubbele gegevens uit de tabel Klanten hebben verwijderd, hebben we voldaan aan de eerste regel van het tweede normale formulier. We moeten nog steeds een externe sleutel gebruiken om de twee tafels aan elkaar te knopen. We gebruiken de postcode (de primaire sleutel uit de ZIP-tabel) om die relatie te creëren. Dit is onze nieuwe tabel Klanten:
- CustNum
- Voornaam
- Achternaam
- Adres
- ZIP
We hebben nu de hoeveelheid redundante informatie die in de database is opgeslagen geminimaliseerd en onze structuur bevindt zich in de tweede normale vorm.
