database normalization tutorial
In deze tutorial wordt uitgelegd wat databasenormalisatie is en verschillende normale vormen zoals 1NF 2NF 3NF en BCNF met SQL-codevoorbeelden:
Database-normalisatie is een bekende techniek die wordt gebruikt voor het ontwerpen van databaseschema's.
Het belangrijkste doel van het toepassen van de normalisatietechniek is om de redundantie en afhankelijkheid van gegevens te verminderen. Normalisatie helpt ons grote tabellen op te splitsen in meerdere kleine tabellen door een logische relatie tussen die tabellen te definiëren.
Wat je leert:
- Wat is databasenormalisatie?
- Gevolgtrekking
Wat is databasenormalisatie?
Database-normalisatie of SQL-normalisatie helpt ons om gerelateerde gegevens in één enkele tabel te groeperen. Alle attributieve gegevens of indirect gerelateerde gegevens worden in verschillende tabellen geplaatst en deze tabellen zijn verbonden met een logische relatie tussen bovenliggende en onderliggende tabellen.
In 1970 bedacht Edgar F. Codd het concept van normalisatie. Hij deelde een paper met de naam 'A Relational Model of Data for Large Shared Banks' waarin hij 'First Normal Form (1NF)' voorstelde.
Voordelen van DBMS-normalisatie
Database normalisatie biedt de volgende basisvoordelen:
- Normalisatie verhoogt de gegevensconsistentie omdat het de dupliciteit van gegevens vermijdt door de gegevens slechts op één plaats op te slaan.
- Normalisatie helpt bij het groeperen van soortgelijke of gerelateerde gegevens onder hetzelfde schema, wat resulteert in een betere groepering van gegevens.
- Normalisatie verbetert het zoeken sneller omdat indexen sneller kunnen worden gemaakt. Daarom wordt de genormaliseerde database of tabel gebruikt voor OLTP (Online Transaction Processing).
Nadelen van databasenormalisatie
DBMS-normalisatie heeft de volgende nadelen:
- We kunnen de bijbehorende gegevens van bijvoorbeeld een product of medewerker niet op één plek vinden en we moeten aan meer dan één tafel aanschuiven. Dit veroorzaakt een vertraging bij het ophalen van de gegevens.
- Normalisatie is dus geen goede optie bij OLAP-transacties (Online Analytical Processing).
Laten we, voordat we verder gaan, de volgende termen begrijpen:
- Entiteit: Entiteit is een realistisch object, waarbij de gegevens die aan een dergelijk object zijn gekoppeld, in de tabel worden opgeslagen. Het voorbeeld van dergelijke objecten zijn medewerkers, afdelingen, studenten, etc.
- Attributen: Attributen zijn de kenmerken van de entiteit, die enige informatie over de entiteit geven. Bijvoorbeeld, als tabellen entiteiten zijn, dan zijn de kolommen hun attributen.
Soorten normale vormen
# 1) 1NF (eerste normale vorm)
Per definitie kan een entiteit die geen herhalende kolommen of gegevensgroepen heeft, worden aangeduid als de eerste normale vorm. In de eerste normale vorm is elke kolom uniek.
Hieronder ziet u hoe onze tabel met medewerkers en afdelingen eruit zou hebben gezien in de eerste normale vorm (1NF):
empNum | achternaam | Voornaam | afd.Naam | afdeling Stad | departement Land |
---|---|---|---|---|---|
1001 | Andrews | Jack | Accounts | New York | Verenigde Staten |
1002 | Schwatz | Mike | Technologie | New York | Verenigde Staten |
1009 | Beker | Harry | HR | Berlijn | Duitsland |
1007 | Harvey | Parker | beheerder | Londen | Verenigd Koningkrijk |
1007 | Harvey | Parker | HR | Londen | Verenigd Koningkrijk |
Hier zijn alle kolommen van zowel de Werknemers- als de Afdelings-tabellen samengevoegd en is het niet nodig om kolommen te verbinden, zoals afdNum, aangezien alle gegevens op één plaats beschikbaar zijn.
Maar een tabel als deze met alle vereiste kolommen erin, zou niet alleen moeilijk te beheren zijn, maar ook moeilijk om bewerkingen uit te voeren en ook inefficiënt vanuit het oogpunt van opslag.
# 2) 2NF (tweede normale vorm)
Per definitie wordt een entiteit die 1NF is en een van zijn attributen gedefinieerd als de primaire sleutel en de overige attributen zijn afhankelijk van de primaire sleutel.
Hieronder volgt een voorbeeld van hoe de tafel voor medewerkers en afdeling eruit zou zien:
Werknemerslijst:
empNum | achternaam | Voornaam |
---|---|---|
1001 | Andrews | Jack |
1002 | Schwatz | Mike |
1009 | Beker | Harry |
1007 | Harvey | Parker |
1007 | Harvey | Parker |
Afdelingstabel:
afdelingNum | afd.Naam | afdeling Stad | departement Land |
---|---|---|---|
1 | Accounts | New York | Verenigde Staten |
twee | Technologie | New York | Verenigde Staten |
3 | HR | Berlijn | Duitsland |
4 | beheerder | Londen | Verenigd Koningkrijk |
EmpDept-tafel:
empDeptID | empNum | afdelingNum |
---|---|---|
1 | 1001 | 1 |
twee | 1002 | twee |
3 | 1009 | 3 |
4 | 1007 | 4 |
5 | 1007 | 3 |
Hier kunnen we zien dat we de tabel in 1NF-vorm hebben opgesplitst in drie verschillende tabellen. De tabel Werknemers is een entiteit over alle werknemers van een bedrijf en de attributen ervan beschrijven de eigenschappen van elke werknemer. De primaire sleutel voor deze tabel is empNum.
Evenzo is de tabel Afdelingen een entiteit over alle afdelingen in een bedrijf en de attributen ervan beschrijven de eigenschappen van elke afdeling. De primaire sleutel voor deze tabel is het deptNum.
In de derde tabel hebben we de primaire sleutels van beide tabellen gecombineerd. De primaire sleutels van de tabellen Werknemers en Afdelingen worden in deze derde tabel Vreemde sleutels genoemd.
Als de gebruiker een output wil die lijkt op de output die we hadden in 1NF, dan moet de gebruiker aan alle drie de tafels deelnemen met behulp van de primaire sleutels.
Een voorbeeldquery zou er als volgt uitzien:
# 3) 3NF (derde normale vorm)
Per definitie wordt een tabel als derde normaal beschouwd als de tabel / entiteit zich al in de tweede normaalvorm bevindt en de kolommen van de tabel / entiteit niet-transitief afhankelijk zijn van de primaire sleutel.
Laten we de niet-transitieve afhankelijkheid begrijpen met behulp van het volgende voorbeeld.
Stel dat een tabel met de naam Klant heeft de onderstaande kolommen:
Klanten ID - Primaire sleutel die een unieke klant identificeert
CustomerZIP - Postcode van de plaats waar de klant woont
KlantCity - Stad waar de klant woont
In het bovenstaande geval is de kolom CustomerCity afhankelijk van de kolom CustomerZIP en is de kolom CustomerZIP afhankelijk van CustomerID.
Het bovenstaande scenario wordt de transitieve afhankelijkheid van de CustomerCity-kolom op de CustomerID, d.w.z. de primaire sleutel, genoemd. Laten we nu, nadat we de transitieve afhankelijkheid hebben begrepen, het probleem met deze afhankelijkheid bespreken.
Er zou een mogelijk scenario kunnen zijn waarbij een ongewenste update van de tabel wordt uitgevoerd om de CustomerZIP bij te werken naar een postcode van een andere stad zonder de CustomerCity bij te werken, waardoor de database in een inconsistente staat blijft.
Om dit probleem op te lossen, moeten we de transitieve afhankelijkheid verwijderen die zou kunnen worden gedaan door een andere tabel te maken, bijvoorbeeld een CustZIP-tabel die twee kolommen bevat, namelijk CustomerZIP (als primaire sleutel) en CustomerCity.
De kolom CustomerZIP in de tabel Customer is een externe sleutel voor de CustomerZIP in de tabel CustZIP. Deze relatie zorgt ervoor dat er geen anomalie is in de updates waarbij een CustomerZIP wordt bijgewerkt zonder wijzigingen aan te brengen in de CustomerCity.
# 4) Boyce-Codd normale vorm (3,5 normale vorm)
Per definitie wordt de tabel beschouwd als Boyce-Codd Normal Form, als het al in de Third Normal Form is en voor elke functionele afhankelijkheid tussen A en B, zou A een supersleutel moeten zijn.
Deze definitie klinkt een beetje ingewikkeld. Laten we proberen het te doorbreken om het beter te begrijpen.
- Functionele afhankelijkheid: Er wordt gezegd dat de attributen of kolommen van een tabel functioneel afhankelijk zijn wanneer een attribuut of kolom van een tabel op unieke wijze een ander attribuut (en) of kolom (men) van dezelfde tabel identificeert.
Bijvoorbeeld, de kolom empNum of Werknemersnummer identificeert op unieke wijze de andere kolommen, zoals Naam werknemer, Salaris werknemer, enz. in de tabel Werknemer. - Super sleutel: Een enkele sleutel of een groep van meerdere sleutels die op unieke wijze een enkele rij in een tabel kunnen identificeren, kan worden aangeduid als Super Key. In algemene termen kennen we sleutels als Composite Keys.
Laten we het volgende scenario eens bekijken om te begrijpen wanneer er een probleem is met Third Normal Form en hoe Boyce-Codd Normal Form te hulp komt.
empNum | Voornaam | empCity | afd.Naam | afd. hoofd |
---|---|---|---|---|
1001 | Jack | New York | Accounts | Raymond |
1001 | Jack | New York | Technologie | Donald |
1002 | Harry | Berlijn | Accounts | Samara |
1007 | Parker | Londen | HR | Elizabeth |
1007 | Parker | Londen | Infrastructuur | Tom |
In het bovenstaande voorbeeld werken medewerkers met empNum 1001 en 1007 op twee verschillende afdelingen. Elke afdeling heeft een afdelingshoofd. Per afdeling kunnen er meerdere afdelingshoofden zijn. Net als bij de afdeling Accounts zijn Raymond en Samara de twee afdelingshoofden.
In dit geval zijn empNum en deptName supersleutels, wat impliceert dat deptName een primair kenmerk is. Op basis van deze twee kolommen kunnen we elke rij uniek identificeren.
Ook is de deptName afhankelijk van deptHead, wat inhoudt dat deptHead een niet-primair kenmerk is. Dit criterium diskwalificeert de tafel om deel uit te maken van BCNF.
Om dit op te lossen zullen we de tabel opsplitsen in drie verschillende tabellen, zoals hieronder vermeld:
Werknemerslijst:
empNum | Voornaam | empCity | afdelingNum |
---|---|---|---|
1001 | Jack | New York | D1 |
1001 | Jack | New York | D2 |
1002 | Harry | Berlijn | D1 |
1007 | Parker | Londen | D3 |
1007 | Parker | Londen | D4 |
Afdelingslijst:
afdelingNum | afd.Naam | afd. hoofd |
---|---|---|
D1 | Accounts | Raymond |
D2 | Technologie | Donald |
D1 | Accounts | Samara |
D3 | HR | Elizabeth |
D4 | Infrastructuur | Tom |
# 5) Vierde normale vorm (4 normale vorm)
Een tabel heeft per definitie de vierde normaalvorm, als er geen twee of meer onafhankelijke gegevens zijn die de relevante entiteit beschrijven.
# 6) Vijfde normale vorm (5 normale vorm)
Een tabel kan alleen in vijfde normale vorm worden beschouwd als deze voldoet aan de voorwaarden voor vierde normale vorm en kan worden opgesplitst in meerdere tabellen zonder verlies van gegevens.
Veelgestelde vragen en antwoorden
V # 1) Wat is normalisatie in een database?
Antwoord: Database normalisatie is een ontwerptechniek. Hiermee kunnen we schema's in de database ontwerpen of opnieuw ontwerpen om overtollige gegevens en de afhankelijkheid van gegevens te verminderen door de gegevens op te splitsen in kleinere en relevantere tabellen.
Vraag 2) Wat zijn de verschillende soorten normalisatie?
toevoegen aan einde van array java
Antwoord: Hieronder volgen de verschillende soorten normalisatietechnieken die kunnen worden gebruikt om databaseschema's te ontwerpen:
- Eerste normale vorm (1NF)
- Tweede normale vorm (2NF)
- Derde normale vorm (3NF)
- Boyce-Codd normale vorm (3.5NF)
- Vierde normale vorm (4NF)
- Vijfde normale vorm (5NF)
V # 3) Wat is het doel van normalisatie?
Antwoord: Het primaire doel van de normalisatie is om de gegevensredundantie te verminderen, d.w.z. de gegevens mogen maar één keer worden opgeslagen. Dit is om gegevensanomalieën te voorkomen die zouden kunnen optreden wanneer we proberen dezelfde gegevens in twee verschillende tabellen op te slaan, maar wijzigingen worden alleen op de ene en niet op de andere toegepast.
V # 4) Wat is denormalisatie?
Antwoord: Denormalisatie is een techniek om de prestaties van de database te verbeteren. Deze techniek voegt redundante gegevens toe aan de database, in tegenstelling tot de genormaliseerde database die de redundantie van de gegevens verwijdert.
Dit wordt gedaan in enorme databases waar het uitvoeren van een JOIN om gegevens uit meerdere tabellen te krijgen een dure aangelegenheid is. Overbodige gegevens worden dus in meerdere tabellen opgeslagen om JOIN-bewerkingen te voorkomen.
Gevolgtrekking
Tot dusver hebben we allemaal drie formulieren voor databasenormalisatie doorlopen.
Theoretisch zijn er hogere vormen van database-normalisaties zoals Boyce-Codd Normal Form, 4NF, 5NF. 3NF is echter het veelgebruikte normalisatievorm in de productiedatabases.
Veel leesplezier !!
Aanbevolen literatuur
- Database testen met JMeter
- MongoDB Maak een databaseback-up
- MongoDB Create Database-zelfstudie
- Top 10 tools voor databaseontwerp om complexe datamodellen te bouwen
- MongoDB-prestaties: vergrendelingsprestaties, paginafouten en databaseprofilering
- Altibase Open Source relationele databasebeoordeling
- MongoDB Database Profiler voor het bewaken van query's en prestaties
- Oracle Database testen