Als je met databases werkt, kom je vaak problemen tegen zoals dubbele data en inconsistente updates. De tweede normaalvorm is een stap in databasnormalisatie die voortbouwt op de eerste normaalvorm (1NF) om schonere en efficiëntere tabellen te maken.
2NF begrijpen is cruciaal voor iedereen die aan databaseontwerp of datamanagement werkt, en het legt de basis voor hogere normaalvormen zoals de derde normaalvorm (3NF). In dit artikel bekijken we hoe 2NF werkt en hoe je tabellen kunt omvormen om aan de 2NF-eisen te voldoen, met praktische voorbeelden. We bespreken ook de voordelen en nadelen van 2NF en voor welke use cases het het beste geschikt is.
De tweede normaalvorm uitgelegd
De tweede normaalvorm is een stap in databasnormalisatie die zich richt op het elimineren van partiële afhankelijkheden. Ze werd geïntroduceerd door Edgar F. Codd, de pionier van relationele databases, als onderdeel van zijn werk rond normalisatie.
Voordat een tabel in 2NF kan zijn, moet deze voldoen aan de regels van de eerste normaalvorm:
- Atomiciteit: Elke cel bevat één enkele waarde (geen herhalende groepen of arrays).
- Unieke rijen: De tabel heeft een duidelijke primaire sleutel.
2NF gaat nog een stap verder met een extra regel: elimineer partiële afhankelijkheden.
Een partiële afhankelijkheid treedt op wanneer een niet-prime attribuut (kolom die geen deel uitmaakt van een kandidaat-sleutel) afhankelijk is van slechts een deel van een samengestelde sleutel in plaats van de hele sleutel. De 2NF-regel zorgt ervoor dat alle niet-prime attributen afhankelijk zijn van de volledige primaire sleutel, niet slechts van een deel ervan. Als je partiële afhankelijkheden in een tabel laat staan, kan er redundante data in de database sluipen, wat leidt tot inefficiëntie en mogelijke inconsistenties tijdens updates of verwijderingen.
Alleen de theorie kan wat droog zijn, dus laten we naar een praktisch voorbeeld kijken.
Hieronder staat een tabel Cursusinschrijvingen van Datacamp-studenten.
Hier is de primaire sleutel de combinatie van Student ID en Course ID. De niet-prime attributen Course Name en Course Fee zijn echter alleen afhankelijk van Course ID, niet van de volledige sleutel. Dit schendt 2NF.
Stappen om tabellen te ontbinden tot 2NF
Om ervoor te zorgen dat een tabel voldoet aan de regels van 2NF, moet je:
- Alle kandidaat-sleutels identificeren: Bepaal de minimale sets attributen die rijen in de tabel uniek identificeren. Dit zijn je kandidaat-sleutels.
- Functionele afhankelijkheden bepalen: Identificeer alle functionele afhankelijkheden in de tabel. Let specifiek op afhankelijkheden waarbij niet-prime attributen (die niet tot een kandidaat-sleutel behoren) slechts van een deel van een samengestelde sleutel afhangen.
- Partiële afhankelijkheden elimineren: Voor elke partiële afhankelijkheid:
- Verplaats de afhankelijke attributen naar een nieuwe tabel, samen met het deel van de sleutel waarvan ze afhankelijk zijn.
- Zorg ervoor dat de nieuwe tabel een unieke primaire sleutel heeft.
- Herhaal totdat er geen partiële afhankelijkheden meer zijn: Bevestig dat elk niet-prime attribuut in alle tabellen volledig afhankelijk is van de respectieve primaire sleutel.
Voorbeelden van de tweede normaalvorm in de praktijk
Laten we nu twee voorbeelden bekijken.
Voorbeeld 1: tabel cursusinschrijvingen
Eerder zagen we de volgende tabel met cursusinschrijvingen:
Laten we de stappen volgen die we in de vorige sectie hebben beschreven.
1. Bepaal onze kandidaat-sleutel.
In dit geval is de kandidaat-sleutel een samengestelde sleutel van Student ID en Course ID. Deze unieke combinatie identificeert elke rij in de tabel.
2. Bepaal onze functionele afhankelijkheden
Course Name en Instructor Name zijn afhankelijk van Course ID, niet van de volledige samengestelde sleutel (Student ID, Course ID). Dit is een partiële afhankelijkheid omdat deze attributen slechts van een deel van de samengestelde sleutel afhangen.
3. Elimineer partiële afhankelijkheden
We moeten de attributen die slechts van een deel van de sleutel afhangen (Course Name en Instructor Name) verplaatsen naar een nieuwe tabel die uitsluitend is gebaseerd op Course ID.
Na ontbinding zien onze nieuwe tabellen er zo uit:
Tabel cursusinschrijvingen
| Student ID | Course ID |
|---|
| 1001 | 201 |
| 1002 | 202 |
| 1001 | 202 |
Tabel cursusdetails
Wil je praktisch aan de slag en je eigen databases maken? Bekijk dan onze cursus PostgresQL. Ben je al wat verder, probeer dan eens Introduction to Data Modeling in Snowflake, waarin onderwerpen aan bod komen zoals entiteit-relatiemodellen en dimensioneel modelleren.
Voorbeeld 2: tabel Orders
We beginnen met deze tabel Orders. Probeer de stappen die we hierboven schetsten te volgen en deze tabel zelf te ontbinden!
| Order ID | Product ID | Order Date | Product Name | Supplier Name |
|---|
| 1 | 201 | 2024-11-01 | Laptop | TechSupply |
| 1 | 202 | 2024-11-01 | Mouse | TechSupply |
| 2 | 201 | 2024-11-02 | Laptop | TechSupply |
| 3 | 203 | 2024-11-03 | Keyboard | KeyMasters |
1. Bepaal onze kandidaat-sleutel
De combinatie van Order ID en Product ID identificeert elke rij uniek, waardoor (Order ID, Product ID) een samengestelde kandidaat-sleutel is. Geen enkele kolom kan rijen uniek identificeren, omdat:
- Order ID op zichzelf niet uniek is, omdat meerdere producten onderdeel kunnen zijn van dezelfde order.
- Product ID op zichzelf niet uniek is, omdat hetzelfde product in verschillende orders kan voorkomen.
Dit betekent dat (Order ID, Product ID) ook onze primaire sleutel is.
2. Bepaal onze functionele afhankelijkheden
Order Date is afhankelijk van Order ID (niet van de volledige samengestelde sleutel). Dit is een partiële afhankelijkheid.
Product Name en Supplier Name zijn afhankelijk van Product ID (niet van de volledige samengestelde sleutel). Dit zijn ook partiële afhankelijkheden.
3. Elimineer partiële afhankelijkheden
We moeten de tabel opsplitsen in kleinere tabellen, die elk één logische afhankelijkheid afhandelen.
Eerst maken we een tabel met orderinformatie, die informatie bevat die specifiek is voor Order ID.
Tabel Orders
| Order ID | Order Date |
|---|
| 1 | 2024-11-01 |
| 2 | 2024-11-02 |
| 3 | 2024-11-03 |
Daarna maken we een tabel die informatie bevat die specifiek is voor Product ID.
Tabel Orders
| Product ID | Product Name | Supplier Name |
|---|
| 201 | Laptop | TechSupply |
| 202 | Mouse | TechSupply |
| 203 | Keyboard | KeyMasters |
De oorspronkelijke tabel is nu gereduceerd tot alleen de samengestelde sleutel en de relaties tussen orders en producten.
| Order ID | Product ID |
|---|
| 1 | 201 |
| 1 | 202 |
| 2 | 201 |
| 3 | 203 |
Onze database is nu in 2NF omdat 1) alle partiële afhankelijkheden zijn geëlimineerd, en 2) niet-prime attributen volledig afhankelijk zijn van hun respectieve primaire sleutels.
Wanneer de tweede normaalvorm toepassen
Waarom zou je je database refactoren naar 2NF? Is het op zichzelf voldoende of ga je beter nog een stap verder naar 3NF?
Voordelen en beperkingen van de tweede normaalvorm
De tweede normaalvorm biedt verschillende voordelen en is daardoor een nuttige stap in het normalisatieproces van databases:
- Betere dataintegriteit: Door partiële afhankelijkheden te elimineren, minimaliseert 2NF invoeg-, update- en verwijderingsanomalieën, wat leidt tot een betrouwbaardere database.
- Minder redundantie: 2NF vermindert herhaling van data, optimaliseert opslag en vereenvoudigt databeheer.
- Verbeterde datastructuur: Het legt de basis voor verdere normalisatie, zoals doorgroeien naar de derde normaalvorm, door een schoner en efficiënter databaseontwerp te creëren.
Maar er zijn ook beperkingen:
- Meer complexiteit: Tabellen ontbinden om aan 2NF te voldoen kan het ontwerpcomplexer maken, vooral bij samengestelde sleutels en afhankelijkheden.
- Extra joins: Het splitsen van tabellen kan meer joins in queries vereisen, wat de prestaties kan beïnvloeden in systemen met grote datasets of complexe queries — daarover hieronder meer.
- Restantredundantie: Hoewel 2NF partiële afhankelijkheden vermindert, pakt het geen transitieve afhankelijkheden aan; daarvoor moet je naar 3NF gaan.
Prestatie-overwegingen bij de tweede normaalvorm
Tabellen ontbinden om partiële afhankelijkheden te elimineren kan direct invloed hebben op de databaseprestaties. Aan de ene kant vermindert 2NF dataduplicatie en verbetert het de consistentie, wat leidt tot minder anomalieën bij insert-, update- of delete-operaties. Aan de andere kant kan normalisatie het aantal tabellen vergroten, waardoor extra joins nodig zijn bij het ophalen van gerelateerde data. Dit kan de queryprestaties beïnvloeden bij grote datasets.
Om ervoor te zorgen dat je genormaliseerde database performant blijft, volg je deze best practices:
- Indexering: Gebruik indexen om joins tussen ontbonden tabellen te versnellen.
- Query-optimalisatie: Optimaliseer queries om de kosten van extra joins te minimaliseren.
- Hybride aanpak: Combineer normalisatie met denormalisatie in gebieden waar performance belangrijk is, zoals rapportagetabellen.
- Regelmatige monitoring: Evalueer continu je databaseprestaties met profilingtools om potentiële problemen tijdig te signaleren.
Is 2NF slechts een tussenstap naar de derde normaalvorm?
In de meeste gevallen streven databaseontwerpers naar de derde normaalvorm omdat die redundantie verder vermindert en de algehele dataintegriteit verbetert. Het bereiken van 3NF vergt echter vaak extra werk, zoals het creëren van meer tabellen en relaties, wat complexiteit en performance-trade-offs in queryuitvoering kan introduceren.
Er zijn situaties waarin de tweede normaalvorm op zichzelf voldoende kan zijn. Als eenvoud en snelle implementatie prioriteit hebben, zoals bij kleinschalige projecten, prototyping of wanneer dataduplicatie minimaal is, kan 2NF volstaan. In systemen waarin alle attributen al volledig afhankelijk zijn van een eenvoudige primaire sleutel, kan 2NF bijvoorbeeld het primaire doel — het verminderen van partiële afhankelijkheid — bereiken zonder verdere normalisatie.
Verder dan de tweede normaalvorm: op weg naar de derde normaalvorm
Als je je database verder wilt normaliseren, kun je je tabellen blijven refactoren tot je de derde normaalvorm bereikt.
3NF bouwt voort op 2NF door transitieve afhankelijkheden aan te pakken — situaties waarin niet-sleutelattributen afhankelijk zijn van andere niet-sleutelattributen in plaats van de primaire sleutel. Deze vervolgstap zorgt ervoor dat elk attribuut direct afhankelijk is van de primaire sleutel en niets anders.
Bijvoorbeeld, in een tabel die cursusinschrijvingen bijhoudt:
- 2NF: Zorgt ervoor dat attributen zoals de cursusnaam en studentnaam volledig afhankelijk zijn van hun respectieve primaire sleutels (bijv. Student ID en Course ID). Dit elimineert partiële afhankelijkheden, waarbij niet-sleutelattributen slechts van een deel van de samengestelde sleutel afhangen.
- 3NF: Zorgt ervoor dat attributen zoals instructeursgegevens of afdelingsinformatie in aparte tabellen worden opgeslagen, waardoor transitieve afhankelijkheden worden geëlimineerd.
3NF is ideaal voor complexere systemen waar dataintegriteit en efficiëntie cruciaal zijn, zeker naarmate het datavolume groeit. Bekijk ons artikel Wat is de derde normaalvorm? als je meer wilt leren over 3NF en de strengere variant, BCNF.
Conclusie
De tweede normaalvorm is een essentiële stap in databasnormalisatie, die de kloof overbrugt tussen 1NF en hogere vormen zoals 3NF. Door partiële afhankelijkheden te verwijderen, vermindert 2NF redundantie en verbetert het de betrouwbaarheid van je data. Hoewel het wat extra complexiteit kan toevoegen, maken de voordelen van betere dataintegriteit en eenvoudiger onderhoud het tot een cruciaal onderdeel van effectief databaseontwerp.
Klaar om je skills verder te ontwikkelen? Verken onze cursus Database Design om je begrip van normalisatietechnieken en hun praktische toepassingen te verdiepen. Je kunt je SQL- en databasemanagementvaardigheden ook valideren en je expertise aantonen aan potentiële werkgevers met onze SQL Associate Certification!
Tot slot: als je beslisser bent binnen een bedrijf en je weet dat er werk aan de winkel is om schonere, efficiëntere databases te creëren, overweeg dan een demo-aanvraag voor DataCamp for Business. We kunnen de capaciteiten van je team versterken zodat jullie schaalbare databasesystemen kunnen bouwen die operationele efficiëntie en innovatie stimuleren. We kunnen zelfs op maat gemaakte leerpaden en custom tracks creëren.
%22%3E%3Cpath%20d%3D%22m-369%200h408v79h-408z%22%20fill%3D%22%237933ff%22%2F%3E%3Cpath%20d%3D%22m-148%200h306v45h-306z%22%20fill%3D%22%23974dff%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
%22%2F%3E%3C%2FclipPath%3E%3Cg%20clip-path%3D%22url(%23a)%22%3E%3Cpath%20d%3D%22m76%200h484v36h-484z%22%20fill%3D%22%23974dff%22%2F%3E%3Cpath%20d%3D%22m0%200h384v24h-384z%22%20fill%3D%22%2306bdfc%22%20transform%3D%22matrix(1%200%200%20-1%200%2060)%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
Als je met databases werkt, kom je vaak problemen tegen zoals dubbele data en inconsistente updates. De tweede normaalvorm is een stap in databasnormalisatie die voortbouwt op de eerste normaalvorm (1NF) om schonere en efficiëntere tabellen te maken.
2NF begrijpen is cruciaal voor iedereen die aan databaseontwerp of datamanagement werkt, en het legt de basis voor hogere normaalvormen zoals de derde normaalvorm (3NF). In dit artikel bekijken we hoe 2NF werkt en hoe je tabellen kunt omvormen om aan de 2NF-eisen te voldoen, met praktische voorbeelden. We bespreken ook de voordelen en nadelen van 2NF en voor welke use cases het het beste geschikt is.
De tweede normaalvorm uitgelegd
De tweede normaalvorm is een stap in databasnormalisatie die zich richt op het elimineren van partiële afhankelijkheden. Ze werd geïntroduceerd door Edgar F. Codd, de pionier van relationele databases, als onderdeel van zijn werk rond normalisatie.
Voordat een tabel in 2NF kan zijn, moet deze voldoen aan de regels van de eerste normaalvorm:
2NF gaat nog een stap verder met een extra regel: elimineer partiële afhankelijkheden.
Een partiële afhankelijkheid treedt op wanneer een niet-prime attribuut (kolom die geen deel uitmaakt van een kandidaat-sleutel) afhankelijk is van slechts een deel van een samengestelde sleutel in plaats van de hele sleutel. De 2NF-regel zorgt ervoor dat alle niet-prime attributen afhankelijk zijn van de volledige primaire sleutel, niet slechts van een deel ervan. Als je partiële afhankelijkheden in een tabel laat staan, kan er redundante data in de database sluipen, wat leidt tot inefficiëntie en mogelijke inconsistenties tijdens updates of verwijderingen.
Alleen de theorie kan wat droog zijn, dus laten we naar een praktisch voorbeeld kijken.
Hieronder staat een tabel Cursusinschrijvingen van Datacamp-studenten.
Hier is de primaire sleutel de combinatie van Student ID en Course ID. De niet-prime attributen Course Name en Course Fee zijn echter alleen afhankelijk van Course ID, niet van de volledige sleutel. Dit schendt 2NF.
Stappen om tabellen te ontbinden tot 2NF
Om ervoor te zorgen dat een tabel voldoet aan de regels van 2NF, moet je:
Voorbeelden van de tweede normaalvorm in de praktijk
Laten we nu twee voorbeelden bekijken.
Voorbeeld 1: tabel cursusinschrijvingen
Eerder zagen we de volgende tabel met cursusinschrijvingen:
Laten we de stappen volgen die we in de vorige sectie hebben beschreven.
1. Bepaal onze kandidaat-sleutel.
In dit geval is de kandidaat-sleutel een samengestelde sleutel van Student ID en Course ID. Deze unieke combinatie identificeert elke rij in de tabel.
2. Bepaal onze functionele afhankelijkheden
Course Name en Instructor Name zijn afhankelijk van Course ID, niet van de volledige samengestelde sleutel (Student ID, Course ID). Dit is een partiële afhankelijkheid omdat deze attributen slechts van een deel van de samengestelde sleutel afhangen.
3. Elimineer partiële afhankelijkheden
We moeten de attributen die slechts van een deel van de sleutel afhangen (Course Name en Instructor Name) verplaatsen naar een nieuwe tabel die uitsluitend is gebaseerd op Course ID.
Na ontbinding zien onze nieuwe tabellen er zo uit:
Tabel cursusinschrijvingen
Tabel cursusdetails
Wil je praktisch aan de slag en je eigen databases maken? Bekijk dan onze cursus PostgresQL. Ben je al wat verder, probeer dan eens Introduction to Data Modeling in Snowflake, waarin onderwerpen aan bod komen zoals entiteit-relatiemodellen en dimensioneel modelleren.
Voorbeeld 2: tabel Orders
We beginnen met deze tabel Orders. Probeer de stappen die we hierboven schetsten te volgen en deze tabel zelf te ontbinden!
1. Bepaal onze kandidaat-sleutel
De combinatie van Order ID en Product ID identificeert elke rij uniek, waardoor (Order ID, Product ID) een samengestelde kandidaat-sleutel is. Geen enkele kolom kan rijen uniek identificeren, omdat:
Dit betekent dat (Order ID, Product ID) ook onze primaire sleutel is.
2. Bepaal onze functionele afhankelijkheden
Order Date is afhankelijk van Order ID (niet van de volledige samengestelde sleutel). Dit is een partiële afhankelijkheid.
Product Name en Supplier Name zijn afhankelijk van Product ID (niet van de volledige samengestelde sleutel). Dit zijn ook partiële afhankelijkheden.
3. Elimineer partiële afhankelijkheden
We moeten de tabel opsplitsen in kleinere tabellen, die elk één logische afhankelijkheid afhandelen.
Eerst maken we een tabel met orderinformatie, die informatie bevat die specifiek is voor Order ID.
Tabel Orders
Daarna maken we een tabel die informatie bevat die specifiek is voor Product ID.
Tabel Orders
De oorspronkelijke tabel is nu gereduceerd tot alleen de samengestelde sleutel en de relaties tussen orders en producten.
Onze database is nu in 2NF omdat 1) alle partiële afhankelijkheden zijn geëlimineerd, en 2) niet-prime attributen volledig afhankelijk zijn van hun respectieve primaire sleutels.
Wanneer de tweede normaalvorm toepassen
Waarom zou je je database refactoren naar 2NF? Is het op zichzelf voldoende of ga je beter nog een stap verder naar 3NF?
Voordelen en beperkingen van de tweede normaalvorm
De tweede normaalvorm biedt verschillende voordelen en is daardoor een nuttige stap in het normalisatieproces van databases:
Maar er zijn ook beperkingen:
Prestatie-overwegingen bij de tweede normaalvorm
Tabellen ontbinden om partiële afhankelijkheden te elimineren kan direct invloed hebben op de databaseprestaties. Aan de ene kant vermindert 2NF dataduplicatie en verbetert het de consistentie, wat leidt tot minder anomalieën bij insert-, update- of delete-operaties. Aan de andere kant kan normalisatie het aantal tabellen vergroten, waardoor extra joins nodig zijn bij het ophalen van gerelateerde data. Dit kan de queryprestaties beïnvloeden bij grote datasets.
Om ervoor te zorgen dat je genormaliseerde database performant blijft, volg je deze best practices:
Is 2NF slechts een tussenstap naar de derde normaalvorm?
In de meeste gevallen streven databaseontwerpers naar de derde normaalvorm omdat die redundantie verder vermindert en de algehele dataintegriteit verbetert. Het bereiken van 3NF vergt echter vaak extra werk, zoals het creëren van meer tabellen en relaties, wat complexiteit en performance-trade-offs in queryuitvoering kan introduceren.
Er zijn situaties waarin de tweede normaalvorm op zichzelf voldoende kan zijn. Als eenvoud en snelle implementatie prioriteit hebben, zoals bij kleinschalige projecten, prototyping of wanneer dataduplicatie minimaal is, kan 2NF volstaan. In systemen waarin alle attributen al volledig afhankelijk zijn van een eenvoudige primaire sleutel, kan 2NF bijvoorbeeld het primaire doel — het verminderen van partiële afhankelijkheid — bereiken zonder verdere normalisatie.
Verder dan de tweede normaalvorm: op weg naar de derde normaalvorm
Als je je database verder wilt normaliseren, kun je je tabellen blijven refactoren tot je de derde normaalvorm bereikt.
3NF bouwt voort op 2NF door transitieve afhankelijkheden aan te pakken — situaties waarin niet-sleutelattributen afhankelijk zijn van andere niet-sleutelattributen in plaats van de primaire sleutel. Deze vervolgstap zorgt ervoor dat elk attribuut direct afhankelijk is van de primaire sleutel en niets anders.
Bijvoorbeeld, in een tabel die cursusinschrijvingen bijhoudt:
3NF is ideaal voor complexere systemen waar dataintegriteit en efficiëntie cruciaal zijn, zeker naarmate het datavolume groeit. Bekijk ons artikel Wat is de derde normaalvorm? als je meer wilt leren over 3NF en de strengere variant, BCNF.
Conclusie
De tweede normaalvorm is een essentiële stap in databasnormalisatie, die de kloof overbrugt tussen 1NF en hogere vormen zoals 3NF. Door partiële afhankelijkheden te verwijderen, vermindert 2NF redundantie en verbetert het de betrouwbaarheid van je data. Hoewel het wat extra complexiteit kan toevoegen, maken de voordelen van betere dataintegriteit en eenvoudiger onderhoud het tot een cruciaal onderdeel van effectief databaseontwerp.
Klaar om je skills verder te ontwikkelen? Verken onze cursus Database Design om je begrip van normalisatietechnieken en hun praktische toepassingen te verdiepen. Je kunt je SQL- en databasemanagementvaardigheden ook valideren en je expertise aantonen aan potentiële werkgevers met onze SQL Associate Certification!
Tot slot: als je beslisser bent binnen een bedrijf en je weet dat er werk aan de winkel is om schonere, efficiëntere databases te creëren, overweeg dan een demo-aanvraag voor DataCamp for Business. We kunnen de capaciteiten van je team versterken zodat jullie schaalbare databasesystemen kunnen bouwen die operationele efficiëntie en innovatie stimuleren. We kunnen zelfs op maat gemaakte leerpaden en custom tracks creëren.