Stel je voor dat je werkt met een enorme, ongestructureerde database gevuld met herhaalde, overbodige informatie. Elke update of verwijdering kan een potentieel rampzalige situatie worden, met risico op fouten en inconsistenties. De derde normaalvorm (3NF) is een bewezen methode voor database normalisatie om deze chaos te vermijden. Door 3NF te implementeren, wordt je gegevensstructuur opgeschoond, waardoor deze efficiënt, georganiseerd en vrij van onnodige redundanties is.
In dit artikel zullen we verkennen hoe 3NF werkt, waarom het waardevol is, en hoe je het in de praktijk kunt brengen. We zullen ook 3NF vergelijken met andere vormen en leren wanneer je elk moet gebruiken. Iedereen kan profiteren van het leren over deze structuren, maar deze kennis is vooral waardevol als je een databaseontwerper of datawetenschapper bent, omdat het je werk aanzienlijk kan vereenvoudigen en je databases betrouwbaar kan houden. Als je geïnteresseerd bent in databaseontwerp als geheel, bekijk dan onze volledige Database Design cursus.
Definitie van de Derde Normaalvorm (3NF)
De derde normaalvorm is een sleutelconcept van database-normalisatie dat ongewenste afhankelijkheden verwijdert. 3NF bouwt voort op de eerste normaalvorm (1NF) en de tweede normaalvorm (2NF), wat betekent dat het hun regels overneemt: 1NF vereist atomaire (ondeelbare) waarden in elke cel, en 2NF verwijdert gedeeltelijke afhankelijkheden van een samengestelde primaire sleutel. 3NF gaat nog verder door transitieve afhankelijkheden te verwijderen, een situatie waarin niet-sleutelattributen indirect afhankelijk zijn van de primaire sleutel.
Door hierop te focussen, zorgt 3NF ervoor dat elke niet-sleutelkolom in een tabel rechtstreeks is verbonden met de primaire sleutel en niets anders. In meer praktische termen helpt 3NF bij het minimaliseren van redundantie en het vermijden van anomalieën bij het invoegen, bijwerken of verwijderen van gegevens.
In de jaren 1970 introduceerde Edgar F. Codd 3NF om de voorwaarden voor het bereiken van een volledig genormaliseerde databasestructuur te formaliseren. Een herformulering door Carlo Zaniolo enkele jaren later gaf een duidelijkere uitleg van het verschil tussen de “klassieke” 3NF en de meer beperkende Boyce-Codd normaalvorm (BCNF). Maak je nu nog niet te veel zorgen over BCNF, we zullen hier later op terugkomen.
Begrip van de Voorwaarden voor de Derde Normaalvorm
Dus, wat is er precies nodig om 3NF te bereiken? Om te voldoen, moet een tabel aan enkele voorwaarden voldoen:
- In 2NF zijn: Dit betekent dat het al atomair is, zonder herhalende groepen en geen partiële afhankelijkheden van enige samengestelde sleutels.
3NF omvat 2NF en 1NF. Afbeelding door Auteur
- Geen transitieve afhankelijkheden: Deze regel is essentieel. In een 3NF-tabel moet elke niet-primaire sleutelkolom uitsluitend afhankelijk zijn van de primaire sleutel, niet indirect via een andere niet-sleutelkolom.
Laten we eens kijken wat dat praktisch betekent.
Decomponeren van tabellen om 3NF te bereiken
Laten we het proces van het decomponeren van tabellen naar 3NF doorlopen. We zullen wat voorbeeldgegevens van DataCamp-cursussen gebruiken om elke stap te illustreren.
Stap 1: Identificeer transitieve afhankelijkheden
Om te beginnen zullen we op zoek gaan naar attributen in een tabel die indirect afhankelijk zijn van de primaire sleutel. Als vuistregel geldt: als een attribuut afhankelijk is van iets anders dan de primaire sleutel, duidt dit op een transitieve afhankelijkheid. Dat is een teken dat het misschien tijd is om je tabel op te splitsen.
Bekijk de drie onderstaande tabellen. Welke heeft een transitieve afhankelijkheid?
Tabel 1: Cursus
| Course ID | Course Name | Difficulty |
|---|---|---|
| 201 | SQL Fundamentals | Beginner |
| 202 | Introduction to Python | Beginner |
| 203 | Understanding Data Science | Intermediate |
Tabel 2: Instructeur
| Instructor ID | Instructor Name | Expertise |
|---|---|---|
| 1 | Sarah Johnson | Data Science |
| 2 | Tom Williams | Machine Learning |
| 3 | Emily Brown | Python |
Tabel 3: Inschrijvingen
| Enrollment ID | Student Name | Course ID | Course Name |
|---|---|---|---|
| 1001 | Alice Smith | 201 | SQL Fundamentals |
| 1002 | Bob Green | 202 | Introductie tot Python |
| 1003 | Charlie Blue | 201 | SQL Fundamentals |
Het antwoord is… Tabel 3!
In deze tabel, Cursusnaam hangt af van Cursus-ID, maar niet rechtstreeks van Inschrijvings-ID (de primaire sleutel). Deze indirecte afhankelijkheid maakt Cursusnaam een transitieve afhankelijkheid.
Stap 2: Gegevens scheiden in nieuwe tabellen
Om de transitieve afhankelijkheid aan te pakken, splitsen we Tabel 1 in twee tabellen. Elke tabel richt zich op direct afhankelijke gegevens.
Aangepaste inschrijvingen tabel
| Enrollment ID | Student Name | Course ID |
|---|---|---|
| 1001 | Alice Smith | 201 |
| 1002 | Bob Green | 202 |
| 1003 | Charlie Blue | 201 |
Cursustabel
| Course ID | Course Name |
|---|---|
| 201 | SQL Basisprincipes |
| 202 | Inleiding tot Python |
Nu bevat elke tabel alleen informatie die direct afhankelijk is van de primaire sleutel: Cursus ID is nu de primaire sleutel voor Cursusnaam in de Cursussen tabel, en Inschrijvings ID is de primaire sleutel in de Inschrijvingen tabel.
Met deze decompositie voldoen de tabellen nu aan de vereisten van de derde normaalvorm, waardoor redundantie wordt geëlimineerd en ervoor wordt gezorgd dat elke tabel alleen direct relevante informatie bevat.
Als je hands-on wilt gaan en je eigen databases wilt maken, kijk dan eens naar onze cursus Creating PostgreSQL Databases. Als je wat meer gevorderd bent, zou je Introduction to Data Modeling in Snowflake kunnen proberen, waar ideeën zoals entiteitsrelatie- en dimensioneel modelleren aan bod komen.
Voordelen en Beperkingen van het Gebruik van de Derde Normaalvorm
Dus, waarom al deze moeite doen om 3NF te bereiken? Hier zijn de belangrijkste voordelen:
- Verbeterde Gegevensintegriteit: Door transitieve afhankelijkheden te elimineren, helpt 3NF ervoor te zorgen dat updates en verwijderingen niet leiden tot tegenstrijdige of verouderde gegevens tussen tabellen.
- Verminderde Redundantie: Minder redundantie betekent dat je database gemakkelijker te onderhouden is, en het opslaggebruik wordt verminderd.
- Eenvoudigere Gegevensonderhoud: Het bewaren van vergelijkbare informatie in speciale tabellen maakt het gemakkelijker om records bij te werken zonder redundante invoeren te hoeven opsporen.
Hoewel 3NF-structuren gegevensnauwkeurigheid ondersteunen, kunnen ze ook leiden tot meer gesegmenteerde gegevens, waardoor complexe queries soms langzamer worden vanwege extra tabelkoppelingen. In gevallen waarin de behoefte aan snelheid belangrijker is dan de behoefte aan normalisatie, kunnen BCNF of 4NF praktischere opties zijn.
Vergelijking: Eerste, Tweede, Derde, en BC-normalisatieformulieren
Laten we eens kijken naar de verschillen in formulieren.
Vergelijkingstabel: eerste, tweede en derde normaalvormen
Hier is een vergelijkingstabel om u te helpen de vereisten van 1NF, 2NF en 3NF te begrijpen.
| Feature | 1NF | 2NF | 3NF |
|---|---|---|---|
| Atoomgegevens | ✅ | ✅ | ✅ |
| Geen gedeeltelijke afhankelijkheden | ❌ | ✅ | ✅ |
| Geen transitieve afhankelijkheden | ❌ | ❌ | ✅ |
Verschil tussen de derde normaalvorm en de Boyce-Codd normaalvorm (BCNF)
BCNF is een “strengere” vorm van 3NF die verdere anomalieën elimineert die ontstaan bij overlappende kandidaatsleutels. Het kan vooral nuttig zijn in complexe gevallen waar 3NF alleen niet alle afhankelijkheden elimineert. BCNF is van toepassing wanneer een niet-prime attribuut afhankelijk is van een attribuut dat deel uitmaakt van een samengestelde kandidaatsleutel. Ik weet dat dit ingewikkeld klinkt, dus laten we het verduidelijken met een voorbeeld.
Huidige structuur (in 3NF)
Na decompositie om 3NF te bereiken, hadden we deze twee tabellen:
Inschrijvingen tabel
| Enrollment ID | Student Name | Course ID |
|---|---|---|
| 1001 | Alice Smith | 201 |
| 1002 | Bob Green | 202 |
| 1003 | Charlie Blue | 201 |
Cursussen tabel
| Course ID | Course Name |
|---|---|
| 201 | SQL Fundamentals |
| 202 | Inleiding tot Python |
In deze structuur is elke tabel in 3NF zonder overgangsafhankelijkheden en zijn gegevens op passende wijze genormaliseerd.
Introductie van een nieuwe vereiste
Nu voegen we een nieuwe attribuut toe aan Cursussen: de Klaslokaal waarin elke cursus wordt gegeven. Dit nieuwe attribuut kan leiden tot een scenario dat BCNF vereist.
Bijgewerkte cursustabel (3NF)
| Course ID | Course Name | Classroom |
|---|---|---|
| 201 | SQL Fundamentals | Lokaal 101 |
| 202 | Introductie tot Python | Lokaal 102 |
| 203 | Begrip van Data Science | Lokaal 101 |
Hier is de Cursus-ID nog steeds de primaire sleutel, en alle andere attributen zijn er direct van afhankelijk. Maar laten we aannemen dat er een nieuwe regel is dat elke klas slechts één vak tegelijk kan hebben. Laten we ook aannemen dat de Cursusnaam “SQL Fundamentals” kan worden aangeboden onder verschillende Cursus-IDs (zoals 201, 204, enz.), als ze op verschillende tijdstippen worden gepland. In dat geval zou elk aanbod van “SQL Fundamentals” nog steeds plaatsvinden in “Kamer 101,” ongeacht de specifieke Cursus-ID. Als gevolg hiervan bepaalt de Cursusnaam ook uniek de Klaslokaal.
Dit betekent dat we nu twee kandidaatsleutels hebben:
- Cursus ID
- Cursusnaam
Met beide kandidaatsleutels hebben we nu een probleem dat niet wordt aangepakt door 3NF: Lokaal is afhankelijk van Cursusnaam in plaats van alleen Cursus-ID.
BCNF toepassen
Om dit afhankelijkheidsprobleem op te lossen, zullen we de Cursussen tabel verder moeten ontbinden in twee afzonderlijke tabellen die beter overeenkomen met BCNF:
- Een nieuwe Cursussen tabel, die alleen de Cursus ID en Cursusnaam bevat.
- Een CourseDetails tabel, die de Cursusnaam en Klaslokaal associatie opslaat.
Zo ziet dat eruit:
Gereviseerde cursustabel (BCNF)
| Course ID | Course Name |
|---|---|
| 201 | SQL Fundamenten |
| 202 | Introductie tot Python |
| 203 | Begrip van Data Science |
Cursusdetails tabel (BCNF)
| Course Name | Classroom |
|---|---|
| SQL Fundamenten | Kamer 101 |
| Introductie tot Python | Kamer 102 |
| Begrip van Data Science | Kamer 101 |
Met deze nieuwe structuur voldoet elke tabel aan de BCNF-voorwaarden:
- In de Cursussen tabel, Cursus ID is de primaire sleutel en alle attributen zijn er volledig van afhankelijk.
- In de CourseDetails tabel, Cursusnaam is de primaire sleutel, en Klaslokaal is alleen afhankelijk van Cursusnaam.
Deze opstelling verwijdert eventuele afhankelijkheidskwesties veroorzaakt door overlappende kandidaatsleutels, waardoor een strikt genormaliseerde structuur ontstaat.
Conclusie
De derde normaalvorm is een waardevol instrument voor databaseontwerpers die streven naar schone, consistente en vrij van problematische afhankelijkheden data. Met 3NF wordt gegevensintegriteit verbeterd, waardoor het beheer soepeler verloopt en redundantie wordt verminderd. Onthoud, hoewel 3NF goed werkt in de meeste situaties, kunnen meer complexe databases baat hebben bij aanvullende vormen zoals BCNF of 4NF.
Als je dit artikel nuttig vond, overweeg dan de volgende stap te zetten door onze SQL Associate Certification te behalen. Het is een geweldige manier om je SQL- en databasebeheervaardigheden te valideren en je expertise aan potentiële werkgevers te tonen!