Normalisering er en database design teknik, der bruges til at designe en relationsdatabase tabel op til højere normal form. Processen er progressiv, og et højere niveau af database normalisering kan ikke opnås, medmindre de tidligere niveauer er opfyldt.
Det betyder, at have data i unormaliseret form (den mindst normaliserede) og sigter mod at opnå den højeste normaliseringsniveau, ville det første trin være at sikre overholdelse af den første normale form, det andet trin ville være at sikre, at den anden normale form blev opfyldt og så videre i den ovennævnte rækkefølge, indtil dataene stemmer overens med den sjette normale form.
Det er dog værd at bemærke, at normale former ud over 4NF hovedsagelig er af akademisk interesse, da de problemer, de findes at løse, sjældent forekommer i praksis.
Bemærk, at dataene i det følgende eksempel var bevidst designet til at modsige de fleste normale former. I det virkelige liv er det meget muligt at være i stand til at springe nogle af normaliseringstrinene over, fordi tabellen ikke indeholder noget, der modsiger den givne normale form. Det forekommer ofte, at fastsættelse af en overtrædelse af en normal form også løser en overtrædelse af en højere normal form i processen. Der er også valgt en tabel til normalisering ved hvert trin, hvilket betyder, at der i slutningen af denne eksempelproces stadig kan være nogle tabeller, der ikke opfylder den højeste normale form.
Initial dataEdit
Lad en databasetabel med følgende struktur:
| Titel | Forfatter | Forfatter Nationalitet | Format | Pris | Emne | Sider | Tykkelse | Udgiver | Udgiverland | Publikationstype | Genre-id | Genrenavn |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Begyndende MySQL-database design og optimering | Chad Russell | Amerikansk | Hardcover | 49,99 | MySQL,
Database, Design |
520 | Tykt | Apress | USA | E-bog | 1 | Vejledning |
Vi antager i dette eksempel, at hver bog kun har en forfatter.
Tilfredsstillende 1NFEdit
For at tilfredsstille 1NF skal værdierne i hver kolonne i en tabel være atomare. I den indledende tabel indeholder emne et sæt emneværdier, hvilket betyder, at det ikke overholder.
En måde at opnå 1NF på ville være at adskille duplikaterne i flere kolonner ved hjælp af gentagne grupper Emne:
| Titel | Format | Forfatter | Forfatter Nationalitet | Pris | Emne 1 | Emne 2 | Emne 3 | Sider | Tykkelse | Udgiver | Udgiverland | Genre-ID | Genrenavn |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Start af MySQL-databasedesign og optimering | Hardcover | Chad Russell | Amerikansk | 49,99 | MySQL | Database | Design | 520 | Tykt | Apress | USA | 1 | Vejledning |
Selvom tabellen nu formelt overholder 1NF (er atom), er problemet med denne løsning indlysende – hvis en bog har mere end tre emner, den kan ikke føjes til databasen uden at ændre dens struktur.
For at løse problemet på en mere elegant måde er det nødvendigt at identificere enheder repræsenteret i tabellen og adskille dem ind i deres respektive respektive tabeller. I dette tilfælde ville det resultere i bog-, emne- og udgivertabeller:
| Titel | Format | Forfatter | Forfatter Nationalitet | Pris | Sider | Tykkelse | Genre-ID | Genrenavn | Udgiver-id |
|---|---|---|---|---|---|---|---|---|---|
| Start MySQL Databasedesign og optimering | Hardcover | Chad Russell | Amerikansk | 49.99 | 520 | Tykt | 1 | Vejledning | 1 |
|
|
At blot adskille de oprindelige data i flere tabeller vil bryde forbindelsen mellem dataene. Det betyder, at forholdet mellem de nyligt introducerede tabeller skal bestemmes. Bemærk, at kolonnen Publisher ID i bogens tabel er en fremmed nøgle, der realiserer mange-til-en-relation mellem en bog og en udgiver.
En bog kan passe mange emner, så godt som et emne svarer til mange bøger. Det betyder også, at der skal defineres et mange-til-mange forhold, opnået ved at oprette en linktabel:
|
I stedet for en tabel i unormaliseret form er der nu 4 tabeller, der svarer til 1NF.
Tilfredsstillende 2NFEdit
Bogtabellen har en kandidatnøgle (som derfor er den primære nøgle), den sammensatte nøgle {Titel, Format}. Overvej følgende tabelfragment:
| Titel | Format | Forfatter | Forfatter Nationalitet | Pris | Sider | Tykkelse | Genre-ID | Genrenavn | Publisher ID |
|---|---|---|---|---|---|---|---|---|---|
| Begyndelse af MySQL-databasedesign og optimering | Hardcover | Chad Russell | Amerikansk | 49,99 | 520 | Tykt | 1 | Vejledning | 1 |
| Start MySQL-database design og optimering | E-bog | Chad Russell | Amerikansk | 22.34 | 520 | Tykt | 1 | Vejledning | 1 |
| Relationsmodellen til databasestyring: Version 2 | E-bog | EFCodd | Britisk | 13,88 | 538 | Tykt | 2 | Populærvidenskab | 2 |
| Relationsmodellen til database Ma administration: Version 2 | Paperback | EFCodd | Britisk | 39.99 | 538 | Tykt | 2 | Populærvidenskab | 2 |
Alle attributter, der ikke er en del af kandidatnøglen, afhænger af titel, men kun Pris afhænger også af format. For at overholde 2NF og fjerne duplikater skal enhver attribut, der ikke er kandidat-nøgle, afhænge af hele kandidatnøglen, ikke kun en del af den.
For at normalisere denne tabel skal du gøre {Titel} til en (enkel) kandidatnøgle (den primære nøgle), så alle attributter, der ikke er kandidatnøgle, afhænger af hele kandidatnøglen, og fjern Price i en separat tabel, så dens afhængighed af format kan bevares:
|
|
Nu, Bogtabellen er i overensstemmelse med 2NF.
Tilfredsstillende 3NFEdit
Bogtabellen har stadig en midlertidig funktionel afhængighed ({Author Nationality} er afhængig af {Author}, som er afhængig af {Title) }). Der findes en lignende overtrædelse for genre ({Genre Name} er afhængig af {Genre ID}, som er afhængig af {Title}). Derfor er bogtabellen ikke i 3NF. For at gøre det i 3NF, lad os bruge følgende tabelstruktur og derved eliminere de transitive funktionelle afhængigheder ved at placere {Author Nationality} og {Genre Name} i deres egne respektive tabeller:
| Titel | Forfatter | Sider | Tykkelse | Genre-ID | Publisher ID |
|---|---|---|---|---|---|
| Begyndende MySQL-databasedesign og Optimering | Chad Russell | 520 | Tykt | 1 | 1 |
| Relationsmodellen til databasestyring: Version 2 | EFCodd | 538 | Tykk | 2 | 2 |
|
| Forfatter | Forfatter Nationalitet |
|---|---|
| Chad Russell | Amerikansk |
| EFCodd | Britisk |
| Gen re ID | Genrenavn |
|---|---|
| 1 | Tutorial |
| 2 | Populærvidenskab |
Tilfredsstillende EKNFEdit
Elementær nøgle normal form (EKNF) falder strengt mellem 3NF og BCNF og diskuteres ikke meget i litteraturen. Det er meningen “at indfange de fremtrædende kvaliteter af både 3NF og BCNF” og samtidig undgå begge problemer (nemlig at 3NF er “for tilgivende” og BCNF er “tilbøjelig til beregningskompleksitet”). Da det sjældent nævnes i litteraturen, det er ikke inkluderet i dette eksempel.
Tilfredsstillende 4NFEdit
Antag, at databasen ejes af en bogforhandler-franchise, der har flere franchisetagere, der ejer butikker forskellige steder.Og derfor besluttede forhandleren at tilføje en tabel, der indeholder data om tilgængeligheden af bøgerne på forskellige steder:
| Franchisetagers ID | Titel | Placering |
|---|---|---|
| 1 | Begyndelse af MySQL-databasedesign og optimering | Californien |
| 1 | Start af MySQL-databasedesign og optimering | Florida |
| 1 | Start MySQL-databasedesign og optimering | Texas |
| 1 | Relationsmodellen til databasestyring: Version 2 | Californien |
| 1 | Relationsmodellen til databasestyring: Version 2 | Florida |
| 1 | Relationsmodellen til databasestyring: Version 2 | Texas |
| 2 | Begyndende MySQL-databasedesign og optimering | Californien |
| 2 | Start af MySQL-databasedesign og optimering | Florida |
| 2 | Begyndelse af MySQL-databasedesign og optimering | Texas |
| 2 | Relationsmodellen til databasestyring: Version 2 | Californien |
| 2 | Relationsmodellen til databasestyring: Version 2 | Florida |
| 2 | Relationsmodellen til databasestyring: Version 2 | Texas |
| 3 | Start af MySQL-databasedesign og -optimering | Texas |
Da denne tabelstruktur består af en sammensat primærnøgle, indeholder den ikke nogen ikke-nøgleattributter, og den er allerede i BCNF (og opfylder derfor også alle de tidligere normale former). Men hvis vi antager, at alle tilgængelige bøger tilbydes i hvert område, bemærker vi muligvis, at titlen ikke entydigt er bundet til en bestemt placering, og derfor opfylder tabellen ikke 4NF.
Det betyder, at for at tilfredsstille den fjerde normale form skal denne tabel også nedbrydes:
|
|
||||||||||||
| Franchisetagers ID | Placering | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Californien | ||||||||||||
| 1 | Florida | ||||||||||||
| 1 | Texas | ||||||||||||
| 2 | Californien | ||||||||||||
| 2 | Florida | ||||||||||||
| 2 | Texas | ||||||||||||
| 3 | Texas |
Nu identificeres hver post entydigt af en supernøgle, derfor er 4NF tilfreds.
Tilfredsstillende ETNFEdit
Antag at franchisetagere også kan bestille bøger fra forskellige leverandører. Lad forholdet også være underlagt følgende begrænsning:
- Hvis en bestemt leverandør leverer en bestemt titel
- og titlen leveres til franchisetageren
- og franchisetageren leveres af leverandøren,
- så leverer leverandøren franchisetageren titlen.
| Leverandør-id | Titel | Franchisetagers ID |
|---|---|---|
| 1 | Begyndende MySQL-databasedesign og optimering | 1 |
| 2 | Relationsmodellen til databasestyring: Version 2 | 2 |
| 3 | Learning SQL | 3 |
Denne tabel er i 4NF, men leverandør-id’et er lig med sammenføjningen af dets fremskrivninger: {{leverandør-id, bog}, {bog, franchisetagers-id}, {franchisetagers-id, leverandør ID}}.Ingen komponent i denne sammenhængsafhængighed er en supernøgle (den eneste supernøgle er hele overskriften), så tabellen opfylder ikke ETNF og kan yderligere nedbrydes:
|
|
|
Nedbrydningen frembringer ETNF-overholdelse.
Tilfredsstillende 5NFEdit
For at få øje på en tabel, der ikke opfylder 5NF, er det er normalt nødvendigt for at undersøge dataene grundigt. Antag tabellen fra 4NF-eksemplet med en lille ændring i data, og lad os undersøge, om den opfylder 5NF:
| Franchisetagers ID | Titel | Placering |
|---|---|---|
| 1 | Start af MySQL-database design og optimering | Californien |
| 1 | Learning SQL | Californien |
| 1 | Relationsmodellen til databasestyring: Version 2 | Texas |
| 2 | Relationsmodellen til databasestyring: Version 2 | Californien |
Hvis vi nedbryder denne tabel, sænker vi afskedigelser og får følgende to tabeller:
|
|
Hvad sker der, hvis vi forsøger at deltage i disse tabeller? Forespørgslen ville returnere følgende data:
| Franchisetagers ID | Titel | Placering |
|---|---|---|
| 1 | Begyndende MySQL-databasedesign og Optimering | Californien |
| 1 | Læring SQL | Californien |
| 1 | Relationsmodellen til databasestyring: Version 2 | Californien |
| 1 | Relationsmodellen til databasestyring: Version 2 | Texas |
| 1 | Learning SQL | Texas |
| 1 | Begyndende MySQL-database design og optimering | Texas |
| 2 | Relationsmodellen til databasestyring: Version 2 | Californien |
JOIN returnerer tilsyneladende tre rækker mere end det burde – lad os prøve at tilføje ano Deres tabel for at afklare forholdet.Vi ender med tre separate tabeller:
|
|
|
Hvad vil JOIN returnere nu? Det er faktisk ikke muligt at deltage i disse tre tabeller. Det betyder, at det ikke var muligt at nedbryde franchisetageren – bogplacering uden tab af data, derfor opfylder tabellen allerede 5NF.
CJ Date har hævdet, at kun en database i 5NF virkelig er “normaliseret”.
Tilfredsstillende DKNFEdit
Lad os se på bogtabellen fra tidligere eksempler og se om den opfylder domænenøglens normale form:
| Titel | Sider | Tykkelse | Genre-ID | Publisher ID | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Start MySQL Database Design and Optimization | 520 | Tykt | 1 | 1 | ||||||||||||||||||||||||||
| Relationsmodellen til databasestyring: Version 2 | 538 | Tykt | 2 | 2 | ||||||||||||||||||||||||||
| Læring SQL | 338 | Slim | 1 | 3 | ||||||||||||||||||||||||||
| SQL-kogebog | 636 | Tykt | 1 | 3 |
|
|
På den måde er domæneintegritetsovertrædelsen elimineret, og tabellen er i DKNF.
Tilfredsstillende 6NFEdit
En enkel og intuitiv definition af den sjette normale form er, at “en tabel er i 6NF, når rækken indeholder den primære nøgle og højst en anden attribut”.
Det betyder for eksempel Publisher-tabellen designet, mens du opretter 1NF
| Publisher_ID | Name | Country |
|---|---|---|
| 1 | Apress | USA |
skal være længere nedbrudt i to tabeller:
|
|
Den åbenlyse ulempe ved 6NF er spredning af tabeller, der kræves for at repræsentere oplysningerne om en enkelt enhed. Hvis en tabel i 5NF har en primær nøglekolonne og N-attributter, der repræsenterer den samme information i 6NF, kræves N-tabeller; multi-felt opdateringer til en enkelt konceptuel post vil kræve opdateringer til flere tabeller; og indsatser og sletninger vil ligeledes kræve operationer på tværs af flere tabeller. Af denne grund bør 6NF ikke bruges i databaser, der er beregnet til at imødekomme behov for behandling af onlinetransaktioner.
Imidlertid i datalager, der ikke tillader interaktive opdateringer, og som er specialiseret til hurtig forespørgsel om store datamængder , bestemte DBMS’er bruger en intern 6NF-repræsentation – kendt som et Columnar-datalager. I situationer, hvor antallet af unikke værdier i en kolonne er langt mindre end antallet af rækker i tabellen, tillader kolonneorienteret lagring betydelige besparelser i plads gennem datakomprimering. Søjleopbevaring tillader også hurtig udførelse af rækkeforespørgsler (f.eks. Viser alle poster, hvor en bestemt kolonne er mellem X og Y eller mindre end X.)
I alle disse tilfælde gør databasedesigneren dog ikke skal udføre 6NF normalisering manuelt ved at oprette separate tabeller. Nogle DBMS’er, der er specialiserede til opbevaring, såsom Sybase IQ, bruger som standard kolonnelagring, men designeren ser stadig kun en enkelt tabel med flere kolonner. Andre DBMS’er, såsom Microsoft SQL Server 2012 og nyere, giver dig mulighed for at angive et “kolonnelagerindeks” for en bestemt tabel.
