Wat is de Tweede Normaalvorm (2NF)?

Wanneer je met databases werkt, is het gebruikelijk om problemen tegen te komen zoals redundante data en inconsistente updates. De tweede normale vorm is een database-normalisatie stap die voortbouwt op de eerste normale vorm (1NF) om schonere en efficiëntere tabellen te creëren.

Het begrijpen van 2NF is cruciaal voor iedereen die werkt in databaseontwerp of databeheer, en het legt de basis voor hogere normalisatievormen zoals de derde normale vorm (3NF). In dit artikel zullen we verkennen hoe 2NF werkt en hoe tabellen kunnen worden getransformeerd om te voldoen aan de vereisten van 2NF, met praktische voorbeelden. We zullen ook de voordelen en nadelen van 2NF bespreken, en de gebruiksgevallen waarvoor het het beste geschikt is.

Begrijpen van de Tweede Normale Vorm

De tweede normale vorm is een database-normalisatiestap die gericht is op het elimineren van partiële afhankelijkheden. Het werd geïntroduceerd door Edgar F. Codd, de pionier van relationele databases, als onderdeel van zijn werk aan normalisatie.

Voordat een tabel in 2NF kan zijn, moet deze voldoen aan de regels van de eerste normale vorm:

• Atomiciteit: Elke cel moet een enkele waarde bevatten (geen herhalende groepen of arrays).
• Unieke rijen: De tabel moet een duidelijke primaire sleutel hebben.

2NF gaat een stap verder met een aanvullende regel: elimineer partiële afhankelijkheden.

Een partiële afhankelijkheid doet zich voor wanneer een niet-primaire attribuut (kolom die geen deel uitmaakt van een kandidaat-sleutel) alleen op een deel van een samengestelde sleutel vertrouwt in plaats van op de hele sleutel. De 2NF-regel zorgt ervoor dat alle niet-primaire attributen afhankelijk zijn van de gehele primaire sleutel, niet slechts een deel ervan. Het achterlaten van partiële afhankelijkheden in een tabel betekent dat er redundante gegevens in de database kunnen sluipen, wat leidt tot inefficiëntie en mogelijke inconsistenties tijdens updates of verwijderingen.

De theorie alleen kan een beetje droog zijn, laten we daarom kijken naar een praktisch voorbeeld.

Hieronder is een Cursusinschrijving tabel van Datacamp-studenten.

Hier is de primaire sleutel de samengestelde sleutel van Student ID en Course ID. Echter, de niet-prime attributen Course Name en Course Fee zijn alleen afhankelijk van Course ID, niet de gehele sleutel. Dit schendt de 2NF.

Stappen voor het ontbinden van tabellen om 2NF te bereiken

Om ervoor te zorgen dat een tabel voldoet aan de regels van 2NF, moet je:

1. Identificeer alle kandidaatsleutels: Bepaal de minimale sets van attributen die rijen in de tabel uniek identificeren. Dit zijn je kandidaatsleutels.
2. Bepaal functionele afhankelijkheden: Identificeer alle functionele afhankelijkheden in de tabel. Zoek specifiek naar afhankelijkheden waar niet-sleutelattributen (die geen deel uitmaken van een kandidaatsleutel) alleen afhankelijk zijn van een deel van een samengestelde sleutel.
3. Elimineer Partiële Afhankelijkheden: Voor elke partiële afhankelijkheid:
• Verplaats de afhankelijke attributen naar een nieuwe tabel samen met het deel van de sleutel waar ze van afhankelijk zijn.
• Zorg ervoor dat de nieuwe tabel een unieke primaire sleutel heeft.
4. Herhaal Totdat Er Geen Partiële Afhankelijkheden Meer Zijn: Bevestig dat elk niet-primaire attribuut in alle tabellen volledig afhankelijk is van zijn respectievelijke primaire sleutel.

Voorbeelden van Tweede Normaalvorm in de Praktijk

Laten we nu kijken naar twee voorbeelden.

Voorbeeld 1: Cursus inschrijvingstabel

Eerder zagen we de volgende tabel met cursusinschrijvingen:

Laten we de stappen volgen die we hebben beschreven in de vorige sectie.

1. Identificeer onze kandidaatsleutel.

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

Cursusnaam en Instructeursnaam zijn afhankelijk van Cursus-ID, niet de volledige samengestelde sleutel (Student-ID, Cursus-ID). Dit is een gedeeltelijke afhankelijkheid omdat deze attributen alleen afhankelijk zijn van een deel van de samengestelde sleutel.

3. Elimineer gedeeltelijke afhankelijkheden

We moeten de attributen verplaatsen die afhankelijk zijn van slechts een deel van de sleutel (Cursusnaam en Instructeursnaam) naar een nieuwe tabel die alleen is gebaseerd op Cursus-ID.

Na decompositie zien onze nieuwe tabellen er als volgt uit:

Cursus inschrijvingstabel

Cursusdetails tabel

Voorbeeld 2: Orders tabel

We beginnen met deze Orders-tabel. Probeer de stappen te volgen die we hierboven hebben geschetst en ontbind deze tabel zelf!

1. Identificeer onze kandidaatsleutel

De Bestel-ID en Product-ID combinatie identificeert elke rij uniek, waardoor (Bestel-ID, Product-ID) een samengestelde kandidaatsleutel is. Geen enkele kolom kan rijen uniek identificeren omdat:

• Bestel-ID is alleen niet uniek, aangezien meerdere producten deel kunnen uitmaken van dezelfde bestelling.
• Product-ID is alleen niet uniek, aangezien hetzelfde product in verschillende bestellingen kan voorkomen.

Dit betekent dat (Bestel-ID, Product-ID) ook onze primaire sleutel is.

2. Bepaal onze functionele afhankelijkheden

Bestel Datum hangt af van Bestel ID (niet op de volledige samengestelde sleutel). Dit is een partiële afhankelijkheid.

Productnaam en Leveranciernaam zijn afhankelijk van Product-ID (niet van de volledige samengestelde sleutel). Dit zijn ook partiële afhankelijkheden.

3. Verwijder partiële afhankelijkheden

We moeten de tabel splitsen in kleinere tabellen, die elk één logische afhankelijkheid adresseren.

Eerst maken we een tabel voor orderinformatie, die specifieke informatie bevat over Order ID.

Orders Tabel

Vervolgens maken we een tabel die specifieke informatie bevat over Product ID.

Bestellingen Tabel

Nu is onze database in 2NF omdat 1) alle partiële afhankelijkheden zijn geëlimineerd, en 2) non-prime attributen volledig afhankelijk zijn van hun respectieve primaire sleutels.

Wanneer Tweede Normale Vorm te Implementeren

Dus waarom zou je je database refactoren naar 2NF? Is het op zichzelf voldoende of moet je nog een stap verder gaan en streven naar 3NF?

Voordelen en beperkingen van de tweede normaalvorm

De tweede normaalvorm biedt verschillende voordelen, waardoor het een nuttige stap is in het normalisatieproces van de database:

• Verbeterde gegevensintegriteit: Door gedeeltelijke afhankelijkheden te elimineren, minimaliseert 2NF invoeg-, update- en verwijderingsanomalieën, wat leidt tot een betrouwbaardere database.
• Vermindering van redundantie: 2NF vermindert gegevensherhaling, optimaliseert opslaggebruik en vereenvoudigt gegevensonderhoud.
• Verbeterde gegevensstructuur: Het legt de basis voor verdere normalisatie, zoals de overgang naar de derde normaalvorm, door het creëren van een schonere en efficiëntere databaseontwerp.

Maar het heeft wel enkele beperkingen:

• Toegenomen complexiteit: Het ontleden van tabellen om aan 2NF te voldoen kan het ontwerpproces ingewikkelder maken, vooral bij het omgaan met samengestelde sleutels en afhankelijkheden.
• Extra joins: Het splitsen van tabellen kan leiden tot meer joins in queries, wat mogelijk invloed heeft op de prestaties in systemen met grote datasets of complexe queries – meer informatie hierover hieronder.
• Residuale redundantie: Hoewel 2NF gedeeltelijke afhankelijkheden vermindert, behandelt het geen transitieve afhankelijkheden, waardoor er nog wat redundantie overblijft totdat dit wordt aangepakt in 3NF.

Prestatieoverwegingen met de tweede normaalvorm

Het ontbinden van tabellen om gedeeltelijke afhankelijkheden te elimineren kan directe invloed hebben op de prestaties van de database. Enerzijds vermindert het bereiken van 2NF redundantie van gegevens en verbetert het de consistentie, wat leidt tot minder anomalieën tijdens invoeg-, bijwerk- of verwijderbewerkingen. Anderzijds kan normalisatie het aantal tabellen verhogen, wat betekent dat er extra joins nodig zijn bij het ophalen van gerelateerde gegevens. Dit kan de queryprestaties beïnvloeden bij grote datasets.

Om ervoor te zorgen dat uw genormaliseerde database prestatie blijft behouden, is het belangrijk dat u deze best practices volgt:

• Indexering: Gebruik indexen om joins tussen ontbonden tabellen te versnellen.
• Query-optimalisatie: Optimaliseer query’s om de kosten van extra joins te minimaliseren.
• Hybride benadering: Combineer normalisatie met denormalisatie op gebieden waar prestaties belangrijk zijn, zoals rapportagetabellen.
• Regelmatige monitoring: Evalueer continu de prestaties van uw database met profileringshulpmiddelen om eventuele mogelijke problemen op te sporen.

Is 2NF slechts een overgangsstap om de derde normaalvorm te bereiken?

In de meeste gevallen streven databaseontwerpers ernaar om de derde normaalvorm te bereiken vanwege het vermogen om verdere redundantie te verminderen en de algehele gegevensintegriteit te verbeteren. Het bereiken van 3NF vereist echter vaak extra werk, zoals het maken van meer tabellen en relaties, wat complexiteit en prestatieafwegingen in query-uitvoering kan introduceren.

Er zijn gevallen waarin het gebruik van de tweede normaalvorm op zichzelf voldoende kan zijn. Als eenvoud en snelle implementatie prioriteit hebben, zoals bij kleinschalige projecten, prototyping, of situaties waarin gegevensredundantie minimaal is, kan 2NF volstaan. Bijvoorbeeld, in systemen waar alle attributen al volledig afhankelijk zijn van een eenvoudige primaire sleutel, zou het bereiken van 2NF het primaire doel van het verminderen van gedeeltelijke afhankelijkheid kunnen vervullen, zonder de noodzaak van verdere normalisatie.

Verder gaan dan de tweede normaalvorm: naar de derde normaalvorm

Als je je database verder wilt normaliseren, kun je je tabellen blijven herstructureren om de derde normaalvorm te bereiken.

3NF bouwt voort op 2NF door transitieve afhankelijkheden aan te pakken – situaties waarbij niet-sleutelattributen afhankelijk zijn van andere niet-sleutelattributen in plaats van de primaire sleutel. Deze vooruitgang 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 de studentennaam volledig afhankelijk zijn van hun respectievelijke primaire sleutels (bijv., Student ID en Course ID). Hiermee worden gedeeltelijke afhankelijkheden geëlimineerd, waarbij niet-sleutelattributen alleen afhankelijk zijn van een deel van de samengestelde sleutel.
• 3NF: Zorgt ervoor dat attributen zoals docentgegevens of afdelingsinformatie in aparte tabellen worden opgeslagen, waardoor transitieve afhankelijkheden worden geëlimineerd.

3NF is ideaal voor complexere systemen waar gegevensintegriteit en efficiëntie cruciaal zijn, vooral naarmate het datavolume toeneemt. Bekijk ons Wat is de derde normale vorm? artikel als je meer wilt leren over 3NF en de meer restrictieve vorm, BCNF.

Conclusie

De tweede normale vorm is een essentiële stap in database-normalisatie, 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 gegevens. Hoewel het enige complexiteit kan toevoegen, maken de voordelen van verbeterde gegevensintegriteit en vereenvoudigd onderhoud het een cruciaal onderdeel van effectief databaseontwerp.

Als je klaar bent om je vaardigheden verder te ontwikkelen, verken dan onze cursus Database Ontwerp om je begrip van normalisatietechnieken en hun praktische toepassingen te verdiepen. Je kunt ook je SQL- en databasebeheervaardigheden valideren en je expertise aan potentiële werkgevers demonstreren met onze SQL Associate Certificering!

Ten slotte wil ik zeggen, als je een beslisser bent in een bedrijf en je weet dat je werk moet verzetten om schonere, efficiëntere databases te creëren, overweeg dan om eenDataCamp voor Bedrijven demo aan te vragen. We kunnen helpen om de vaardigheden van je team te transformeren, zodat je schaalbare databasesystemen kunt creëren die de efficiëntie en innovatie van het bedrijf bevorderen. We kunnen zelfs op maat gemaakte leerpaden en aangepaste trajecten maken.