database normalization tutorial
Denne vejledning forklarer, hvad der er normalisering af databaser og forskellige normale former som 1NF 2NF 3NF og BCNF med eksempler på SQL-kode:
Database Normalization er en velkendt teknik, der bruges til at designe databaseskema.
Hovedformålet med anvendelse af normaliseringsteknikken er at reducere redundansen og afhængigheden af data. Normalisering hjælper os med at opdele store tabeller i flere små tabeller ved at definere et logisk forhold mellem disse tabeller.
Hvad du vil lære:
- Hvad er database normalisering?
- Konklusion
Hvad er database normalisering?
Database normalisering eller SQL normalisering hjælper os med at gruppere relaterede data i en enkelt tabel. Eventuelle attributdata eller indirekte relaterede data placeres i forskellige tabeller, og disse tabeller er forbundet med et logisk forhold mellem overordnede og underordnede tabeller.
I 1970 kom Edgar F. Codd med begrebet normalisering. Han delte en artikel med navnet 'En relationsmodel for data for store delte banker', hvori han foreslog 'First Normal Form (1NF)'.
Fordele ved DBMS-normalisering
Database Normalisering giver følgende grundlæggende fordele:
- Normalisering øger datakonsistensen, da det undgår dobbelt data ved kun at gemme dataene ét sted.
- Normalisering hjælper med at gruppere lignende eller relaterede data under det samme skema, hvilket resulterer i en bedre gruppering af data.
- Normalisering forbedrer søgningen hurtigere, da indekser kan oprettes hurtigere. Derfor bruges den normaliserede database eller tabel til OLTP (Online Transaction Processing).
Ulemper ved databasens normalisering
DBMS Normalisering har følgende ulemper:
- Vi kan ikke finde de tilknyttede data for f.eks. Et produkt eller en medarbejder et sted, og vi er nødt til at deltage i mere end en tabel. Dette medfører en forsinkelse i hentning af data.
- Normalisering er således ikke en god mulighed i OLAP-transaktioner (Online Analytical Processing).
Lad os forstå følgende vilkår, inden vi går videre:
- Enhed: Enhed er et virkeligt objekt, hvor de data, der er knyttet til et sådant objekt, er gemt i tabellen. Eksemplet på sådanne objekter er medarbejdere, afdelinger, studerende osv.
- Egenskaber: Attributter er enhedens egenskaber, der giver nogle oplysninger om Enheden. For eksempel, hvis tabeller er enheder, er kolonnerne deres attributter.
Typer af normale former
# 1) 1NF (første normale form)
Per definition kan en enhed, der ikke har nogen gentagne kolonner eller datagrupper, betegnes som den første normale form. I den første normale form er hver kolonne unik.
Følgende er, hvordan vores medarbejdere og afdelingstabel ville have set ud, hvis de var i den første normale form (1NF):
| empNum | efternavn | fornavn | afdelingsnavn | deptCity | deptCountry |
|---|---|---|---|---|---|
| 1001 | Andrews | Jack | Konti | New York | Forenede Stater |
| 1002 | Schwatz | Mike | Teknologi | New York | Forenede Stater |
| 1009 | Kop | Harry | HR | Berlin | Tyskland |
| 1007 | Harvey | Parker | Administrator | London | Det Forenede Kongerige |
| 1007 | Harvey | Parker | HR | London | Det Forenede Kongerige |
Her er alle kolonnerne i både medarbejdere og afdelingstabeller samlet i en, og der er ikke behov for at forbinde kolonner som deptNum, da alle data er tilgængelige ét sted.
Men en tabel som denne med alle de krævede kolonner i den ville ikke kun være vanskelig at styre, men også vanskelig at udføre operationer på og også ineffektiv fra lagersynspunktet.
# 2) 2NF (anden normal form)
Per definition er en enhed, der er 1NF, og en af dens attributter defineret som den primære nøgle, og de resterende attributter er afhængige af den primære nøgle.
Følgende er et eksempel på, hvordan medarbejderne og afdelingstabellen ser ud:
Medarbejdertabel:
| empNum | efternavn | fornavn |
|---|---|---|
| 1001 | Andrews | Jack |
| 1002 | Schwatz | Mike |
| 1009 | Kop | Harry |
| 1007 | Harvey | Parker |
| 1007 | Harvey | Parker |
Afdelingstabel:
| deptNum | afdelingsnavn | deptCity | deptCountry |
|---|---|---|---|
| 1 | Konti | New York | Forenede Stater |
| to | Teknologi | New York | Forenede Stater |
| 3 | HR | Berlin | Tyskland |
| 4 | Administrator | London | Det Forenede Kongerige |
EmpDept-tabel:
| empDeptID | empNum | deptNum |
|---|---|---|
| 1 | 1001 | 1 |
| to | 1002 | to |
| 3 | 1009 | 3 |
| 4 | 1007 | 4 |
| 5 | 1007 | 3 |
Her kan vi se, at vi har delt tabellen i 1NF-form i tre forskellige tabeller. tabellen medarbejdere er en enhed om alle medarbejdere i en virksomhed, og dens egenskaber beskriver egenskaberne for hver medarbejder. Den primære nøgle til denne tabel er empNum.
Tilsvarende er tabellen afdelinger en enhed om alle afdelinger i en virksomhed, og dens attributter beskriver egenskaberne for hver afdeling. Den primære nøgle til denne tabel er deptNum.
I den tredje tabel har vi kombineret de primære nøgler til begge tabeller. De primære nøgler i tabellerne medarbejdere og afdelinger kaldes udenlandske nøgler i denne tredje tabel.
Hvis brugeren ønsker en output svarende til den, vi havde i 1NF, skal brugeren slutte sig til alle de tre tabeller ved hjælp af de primære taster.
En prøveforespørgsel ser ud som vist nedenfor:
SELECT empNum, lastName, firstName, deptNum, deptName, deptCity, deptCountry FROM Employees A, Departments B, EmpDept C WHERE A.empNum = C.empNum AND B.deptNum = C.deptNum WITH UR; # 3) 3NF (tredje normale form)
Per definition betragtes en tabel som tredje normal, hvis tabellen / enheden allerede er i den anden normale form, og kolonnerne i tabellen / enheden ikke er transitivt afhængige af den primære nøgle.
Lad os forstå ikke-transitiv afhængighed ved hjælp af følgende eksempel.
Sig en tabel med navnet, Kunden har nedenstående kolonner:
Kunde ID - Primær nøgle, der identificerer en unik kunde
CustomerZIP - Postnummer for lokalitetskunden er bosat i
Kundeby - By, kunden bor i
software til download af videoer fra youtube
I ovenstående tilfælde er CustomerCity-kolonnen afhængig af CustomerZIP-kolonnen, og CustomerZIP-kolonnen er afhængig af CustomerID.
Ovenstående scenario kaldes transitiv afhængighed af CustomerCity-kolonnen på CustomerID, dvs. den primære nøgle. Efter at have forstået transitiv afhængighed, lad os nu diskutere problemet med denne afhængighed.
Der kan være et muligt scenarie, hvor der foretages en uønsket opdatering af tabellen til opdatering af CustomerZIP til et postnummer fra en anden by uden opdatering af CustomerCity, hvorved databasen efterlades i en inkonsekvent tilstand.
For at løse dette problem er vi nødt til at fjerne den transitive afhængighed, der kan gøres ved at oprette en anden tabel, f.eks.CustZIP-tabel, der indeholder to kolonner, dvs. CustomerZIP (som primær nøgle) og CustomerCity.
CustomerZIP-kolonnen i kundetabellen er en fremmed nøgle til CustomerZIP i CustZIP-tabellen. Dette forhold sikrer, at der ikke er nogen anomali i opdateringerne, hvor et CustomerZIP opdateres uden at foretage ændringer i CustomerCity.
# 4) Boyce-Codd Normal Form (3,5 Normal Form)
Per definition betragtes tabellen som Boyce-Codd normal form, hvis den allerede er i den tredje normale form, og for enhver funktionel afhængighed mellem A og B, bør A være en supernøgle.
Denne definition lyder lidt kompliceret. Lad os prøve at bryde det for at forstå det bedre.
- Funktionel afhængighed: Attributterne eller kolonnerne i en tabel siges at være funktionelt afhængige, når en attribut eller kolonne i en tabel entydigt identificerer en anden attribut (er) eller kolonne (r) i den samme tabel.
For eksempel, kolonnen empNum eller medarbejdernummer identificerer entydigt de andre kolonner som medarbejdernavn, medarbejderløn osv. i tabellen medarbejder. - Super nøgle: En enkelt nøgle eller gruppe af flere nøgler, der entydigt kunne identificere en enkelt række i en tabel, kan betegnes som Super Key. Generelt kender vi sådanne nøgler som Composite Keys.
Lad os overveje følgende scenarie for at forstå, hvornår der er et problem med tredje normale form, og hvordan kommer Boyce-Codd normal form til redning.
| empNum | fornavn | empCity | afdelingsnavn | deptHead |
|---|---|---|---|---|
| 1001 | Jack | New York | Konti | Raymond |
| 1001 | Jack | New York | Teknologi | Donald |
| 1002 | Harry | Berlin | Konti | Samara |
| 1007 | Parker | London | HR | Elizabeth |
| 1007 | Parker | London | Infrastruktur | Tom |
I ovenstående eksempel arbejder medarbejdere med empNum 1001 og 1007 i to forskellige afdelinger. Hver afdeling har en afdelingsleder. Der kan være flere afdelingsledere for hver afdeling. Ligesom for regnskabsafdelingen er Raymond og Samara de to afdelinger.
I dette tilfælde er empNum og deptName supernøgler, hvilket betyder, at deptName er en primær attribut. Baseret på disse to kolonner kan vi identificere hver enkelt række entydigt.
Desuden afhænger deptName af deptHead, hvilket betyder, at deptHead er en ikke-primær attribut. Dette kriterium diskvalificerer tabellen fra at være en del af BCNF.
For at løse dette deler vi tabellen i tre forskellige tabeller som nævnt nedenfor:
Medarbejdertabel:
| empNum | fornavn | empCity | deptNum |
|---|---|---|---|
| 1001 | Jack | New York | D1 |
| 1001 | Jack | New York | D2 |
| 1002 | Harry | Berlin | D1 |
| 1007 | Parker | London | D3 |
| 1007 | Parker | London | D4 |
Afdelingsbord:
| deptNum | afdelingsnavn | deptHead |
|---|---|---|
| D1 | Konti | Raymond |
| D2 | Teknologi | Donald |
| D1 | Konti | Samara |
| D3 | HR | Elizabeth |
| D4 | Infrastruktur | Tom |
# 5) Fjerde normal form (4 normal form)
Per definition er en tabel i fjerde normale form, hvis den ikke har to eller flere uafhængige data, der beskriver den relevante enhed.
# 6) Femte normal form (5 normal form)
En tabel kan kun overvejes i femte normalform, hvis den opfylder betingelserne for fjerde normalform og kan opdeles i flere tabeller uden tab af data.
Ofte stillede spørgsmål og svar
Q # 1) Hvad er normalisering i en database?
Svar: Database Normalisering er en designteknik. Ved hjælp af dette kan vi designe eller re-designe skemaer i databasen for at reducere overflødige data og afhængigheden af data ved at opdele dataene i mindre og mere relevante tabeller.
Q # 2) Hvad er de forskellige typer normalisering?
Svar: Følgende er de forskellige typer normaliseringsteknikker, der kan bruges til at designe databaseskemaer:
- Første normale form (1NF)
- Anden normal form (2NF)
- Tredje normale form (3NF)
- Boyce-Codd Normal Form (3.5NF)
- Fjerde normal form (4NF)
- Femte normale form (5NF)
Q # 3) Hvad er formålet med normalisering?
Svar: Det primære formål med normaliseringen er at reducere dataredundansen, dvs. dataene skal kun gemmes en gang. Dette er for at undgå dataafvigelser, der kan opstå, når vi forsøger at gemme de samme data i to forskellige tabeller, men ændringer gælder kun for den ene og ikke for den anden.
Spørgsmål nr. 4) Hvad er denormalisering?
Svar: Denormalisering er en teknik til at øge databasens ydeevne. Denne teknik tilføjer overflødige data til databasen i modsætning til den normaliserede database, der fjerner redundansen af dataene.
Dette gøres i store databaser, hvor det er en dyr affære at udføre en JOIN for at hente data fra flere tabeller. Således lagres overflødige data i flere tabeller for at undgå JOIN-operationer.
Konklusion
Indtil videre har vi alle gennemgået tre databasens normaliseringsformularer.
Teoretisk er der højere former for database normaliseringer som Boyce-Codd Normal Form, 4NF, 5NF. 3NF er imidlertid den udbredte normaliseringsform i produktionsdatabaser.
God læselyst!!
Anbefalet læsning
- Databasetestning med JMeter
- MongoDB Opret database backup
- MongoDB Opret databasevejledning
- Top 10 databasedesignværktøjer til at opbygge komplekse datamodeller
- MongoDB-ydeevne: Låseydelse, sidefejl og databaseprofilering
- Altibase Open Source Relational Database Review
- MongoDB Database Profiler til overvågning af forespørgsler og ydeevne
- Sådan testes Oracle Database