Normalisering är en databasdesignteknik som används för att designa en relationsdatabastabell upp till högre normalform. Processen är progressiv och en högre nivå av databasnormalisering kan inte uppnås om inte tidigare nivåer har uppfyllts.
Det betyder att man har data i onormaliserad form (den minst normaliserade) och syftar till att uppnå det högsta normaliseringsnivå, skulle det första steget vara att säkerställa överensstämmelse med den första normala formen, det andra steget skulle vara att säkerställa att den andra normala formen är uppfylld, och så vidare i den ordning som nämns ovan, tills data överensstämmer med sjätte normalform. >
Det är dock värt att notera att normala former utöver 4NF huvudsakligen är av akademiskt intresse, eftersom problemen de finns att lösa sällan förekommer i praktiken.
Observera att uppgifterna i följande exempel var avsiktligt utformad för att motsäga de flesta normala former. I verkliga livet är det fullt möjligt att kunna hoppa över några av normaliseringsstegen eftersom tabellen inte innehåller något som strider mot den givna normala formen. Det inträffar också att fixning av en överträdelse av en normal form också fixar en överträdelse av en högre normal form i processen. Även en tabell har valts för normalisering vid varje steg, vilket innebär att det i slutet av denna exempelprocess fortfarande kan finnas några tabeller som inte uppfyller den högsta normala formen.
Initial dataEdit
Låt en databastabell med följande struktur:
| Titel | Författare | Författare Nationalitet | Format | Pris | Ämne | Sidor | Tjocklek | Utgivare | Utgivarland | Publikationstyp | Genre-ID | Genrenamn |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Börjar MySQL-databasdesign och optimering | Chad Russell | American | Inbunden | 49,99 | MySQL,
Databas, Design |
520 | Tjock | Apress | USA | E-bok | 1 | Handledning |
Vi antar i detta exempel att varje bok bara har en författare.
Tillfredsställande 1NFEdit
För att tillfredsställa 1NF måste värdena i varje kolumn i en tabell vara atomiska. I den ursprungliga tabellen innehåller ämnet en uppsättning ämnesvärden, vilket betyder att den inte överensstämmer.
Ett sätt att uppnå 1NF skulle vara att separera dubbletterna i flera kolumner med upprepande grupper Ämne:
| Titel | Format | Författare | Författare Nationalitet | Pris | Ämne 1 | Ämne 2 | Ämne 3 | Sidor | Tjocklek | Utgivare | Utgivarland | Genre-ID | Genrenamn |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Börjar MySQL-databasdesign och optimering | Inbunden | Chad Russell | Amerikansk | 49,99 | MySQL | Databas | Design | 520 | Tjock | Apress | USA | 1 | Handledning |
Även om tabellen nu formellt överensstämmer med 1NF (är atom), är problemet med denna lösning uppenbart – om en bok har mer än tre ämnen, den kan inte läggas till i databasen utan att ändra dess struktur.
För att lösa problemet på ett mer elegant sätt är det nödvändigt att identifiera enheter som representeras i tabellen och separera dem i sina egna respektive tabeller. I det här fallet skulle det resultera i bok-, ämnes- och utgivartabeller:
| Titel | Format | Författare | Författare Nationalitet | Pris | Sidor | Tjocklek | Genre-ID | Genrenamn | Utgivar-ID |
|---|---|---|---|---|---|---|---|---|---|
| Börjar MySQL Databasdesign och optimering | Inbunden | Chad Russell | Amerikansk | 49.99 | 520 | Tjock | 1 | Handledning | 1 |
|
|
Att bara separera initialdata i flera tabeller skulle bryta förbindelsen mellan data. Det betyder att förhållandet mellan de nyligen introducerade tabellerna måste bestämmas. Lägg märke till att kolumnen för utgivar-ID i bokens tabell är en främmande nyckel som realiserar många-till-en-relation mellan en bok och en utgivare.
En bok kan passa många ämnen, liksom ett ämne kan motsvarar många böcker. Det betyder också att många-till-många-förhållanden måste definieras, uppnås genom att skapa en länkstabell:
|
Istället för en tabell i onormaliserad form finns det nu fyra tabeller som överensstämmer med 1NF.
Tillfredsställande 2NFEdit
Boktabellen har en kandidatnyckel (som därför är den primära nyckeln), den sammansatta nyckeln {Titel, Format}. Tänk på följande tabellfragment:
| Titel | Format | Författare | Författare Nationalitet | Pris | Sidor | Tjocklek | Genre-ID | Genre Name | Publisher ID |
|---|---|---|---|---|---|---|---|---|---|
| Start MySQL Database Design and Optimization | Inbunden | Chad Russell | Amerikansk | 49,99 | 520 | Tjock | 1 | Självstudie | 1 |
| Börjar MySQL-databasdesign och optimering | E-bok | Chad Russell | Amerikansk | 22.34 | 520 | Tjock | 1 | Handledning | 1 |
| Relationsmodellen för databashantering: Version 2 | E-bok | EFCodd | Brittisk | 13,88 | 538 | Tjock | 2 | Populärvetenskap | 2 |
| Relationsmodellen för databas Ma förvaltning: Version 2 | Pocketbok | EFCodd | Brittisk | 39.99 | 538 | Tjock | 2 | Populärvetenskap | 2 |
Alla attribut som inte ingår i kandidatnyckeln beror på titel, men bara Pris beror också på format. För att överensstämma med 2NF och ta bort dubbletter måste varje attribut utan kandidatnyckel bero på hela kandidatnyckeln, inte bara en del av den.
För att normalisera denna tabell, gör {Titel} till en (enkel) kandidatnyckel (den primära nyckeln) så att varje icke-kandidat-nyckelattribut beror på hela kandidatnyckeln, och ta bort Pris i en separat tabell så att dess beroende av Format kan bevaras:
|
|
Nu, Boktabellen överensstämmer med 2NF.
Tillfredsställande 3NFEdit
Boktabellen har fortfarande ett övergående funktionellt beroende ({Author Nationality} är beroende av {Author}, vilket är beroende av {Title) }). Det finns en liknande överträdelse för genre ({Genre Name} är beroende av {Genre ID}, vilket är beroende av {Title}). Därför är boktabellen inte i 3NF. För att göra det i 3NF, låt oss använda följande tabellstruktur, vilket eliminerar de transitiva funktionella beroenden genom att placera {Author Nationality} och {Genre Name} i sina respektive tabeller:
| Titel | Författare | Sidor | Tjocklek | Genre-ID | Utgivar-ID |
|---|---|---|---|---|---|
| Börjar MySQL-databasdesign och Optimering | Chad Russell | 520 | Tjock | 1 | 1 |
| Relationsmodellen för databashantering: Version 2 | EFCodd | 538 | Tjock | 2 | 2 |
|
| Författare | Författare Nationalitet |
|---|---|
| Chad Russell | Amerikansk |
| EFCodd | Brittisk |
| Gen re ID | Genre Name |
|---|---|
| 1 | Tutorial |
| 2 | Populärvetenskap |
Tillfredsställande EKNFEdit
Elementär nyckel normal form (EKNF) faller strikt mellan 3NF och BCNF och diskuteras inte mycket i litteraturen. Det är avsett ”att fånga de framträdande egenskaperna hos både 3NF och BCNF” samtidigt som man undviker problemen för båda (nämligen att 3NF är ”för förlåtande” och BCNF är ”benägen att beräkna komplexiteten”). Eftersom det sällan nämns i litteraturen det ingår inte i detta exempel.
Tillfredsställande 4NFEdit
Antag att databasen ägs av en franchise för bokhandlare som har flera franchisetagare som äger butiker på olika platser.Och därför beslutade återförsäljaren att lägga till en tabell som innehåller information om tillgängligheten av böckerna på olika platser:
| Franchisetagar-ID | Titel | Plats |
|---|---|---|
| 1 | Början av MySQL-databasdesign och optimering | Kalifornien |
| 1 | Börjar MySQL-databasdesign och optimering | Florida |
| 1 | Börjar MySQL-databasdesign och optimering | Texas |
| 1 | Relationsmodellen för databashantering: version 2 | Kalifornien |
| 1 | Relationsmodellen för databashantering: version 2 | Florida |
| 1 | Relationsmodellen för databashantering: version 2 | Texas |
| 2 | Börjar MySQL-databasdesign och optimering | Kalifornien |
| 2 | MySQL-databasdesign och optimering börjar | Florida |
| 2 | Börjar MySQL-databasdesign och optimering | Texas |
| 2 | Relationsmodellen för databashantering: Version 2 | Kalifornien |
| 2 | Relationsmodellen för databashantering: Version 2 | Florida |
| 2 | Relationsmodellen för databashantering: Version 2 | Texas |
| 3 | Börjar MySQL-databasdesign och optimering | Texas |
Eftersom denna tabellstruktur består av en sammansatt primärnyckel, innehåller den inte några icke-nyckelattribut och den finns redan i BCNF (och uppfyller därför också alla tidigare normala former). Men om vi antar att alla tillgängliga böcker erbjuds inom varje område, kanske vi märker att titeln inte entydigt är bunden till en viss plats och därför uppfyller tabellen inte 4NF.
Det betyder att, för att tillfredsställa den fjärde normala formen måste denna tabell också sönderdelas:
|
|
||||||||||||
| Franchisetagar-ID | Plats | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Kalifornien | ||||||||||||
| 1 | Florida | ||||||||||||
| 1 | Texas | ||||||||||||
| 2 | Kalifornien | ||||||||||||
| 2 | Florida | ||||||||||||
| 2 | Texas | ||||||||||||
| 3 | Texas |
Nu identifieras varje post otvetydigt av en supernyckel, därför är 4NF nöjd.
Tillfredsställande ETNFEdit
Antag att franchisetagarna också kan beställa böcker från olika leverantörer. Låt förhållandet också vara föremål för följande begränsningar:
- Om en viss leverantör levererar en viss titel
- och titeln levereras till franchisetagaren
- och franchisetagaren levereras av leverantören,
- då levererar leverantören titeln till franchisetagaren.
| Leverantörs-ID | Titel | Franchisetagar-ID |
|---|---|---|
| 1 | Börjar MySQL-databasdesign och optimering | 1 |
| 2 | Relationsmodellen för databashantering: version 2 | 2 |
| 3 | Learning SQL | 3 |
Denna tabell finns i 4NF, men leverantörs-ID är lika med sammanfogningen av dess prognoser: {{leverantörs-ID, bok}, {bok, franchisetagar-ID}, {franchisetagar-ID, leverantör ID}}.Ingen komponent i detta anslutningsberoende är en supernyckel (den enda supernyckeln är hela rubriken), så tabellen uppfyller inte ETNF och kan sönderdelas ytterligare:
|
|
|
Sönderdelningen ger ETNF-överensstämmelse.
Tillfredsställande 5NFEdit
För att upptäcka en tabell som inte uppfyller 5NF, är det är vanligtvis nödvändigt för att undersöka uppgifterna noggrant. Antag att tabellen från 4NF-exemplet med lite modifiering av data och låt oss undersöka om den uppfyller 5NF:
| Franchisetagar-ID | Titel | Plats |
|---|---|---|
| 1 | Börjar MySQL-databasdesign och optimering | Kalifornien |
| 1 | Learning SQL | Kalifornien |
| 1 | Relationsmodellen för databashantering: Version 2 | Texas |
| 2 | Relationsmodellen för databashantering: version 2 | Kalifornien |
Om vi sönderdelar denna tabell minskar vi uppsägningar och får följande två tabeller:
|
|
Vad händer om vi försöker gå med i dessa tabeller? Frågan skulle returnera följande data:
| Franchisetagar-ID | Titel | Plats |
|---|---|---|
| 1 | Börjar MySQL-databasdesign och Optimering | Kalifornien |
| 1 | Lärande SQL | Kalifornien |
| 1 | Relationsmodellen för databashantering: Version 2 | Kalifornien |
| 1 | Relationsmodellen för databashantering: Version 2 | Texas |
| 1 | Learning SQL | Texas |
| 1 | MySQL-databasdesign och optimering börjar | Texas |
| 2 | Relationsmodellen för databashantering: version 2 | Kalifornien |
Tydligen returnerar JOIN tre rader till än det borde – låt oss försöka lägga till ano tabellen för att klargöra förhållandet.Vi slutar med tre separata tabeller:
|
|
|
Vad kommer JOIN att returnera nu? Det är faktiskt inte möjligt att gå med i dessa tre tabeller. Det betyder att det inte var möjligt att sönderdela franchisetagaren – bokplats utan dataförlust, därför uppfyller tabellen redan 5NF.
CJ Date har hävdat att endast en databas i 5NF verkligen är ”normaliserad”.
Tillfredsställande DKNFEdit
Låt oss titta på boktabellen från tidigare exempel och se om den uppfyller domännyckelns normala form:
| Titel | Sidor | Tjocklek | Genre-ID | Publisher ID | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Börjar MySQL-databasdesign och optimering | 520 | Tjock | 1 | 1 | ||||||||||||||||||||||||||
| Relationsmodellen för databashantering: Version 2 | 538 | Tjock | 2 | 2 | ||||||||||||||||||||||||||
| Lärande SQL | 338 | Slim | 1 | 3 | ||||||||||||||||||||||||||
| SQL Cookbook | 636 | Tjock | 1 | 3 |
|
|
På det sättet har domänintegritetsöverträdelsen eliminerats och tabellen finns i DKNF.
Tillfredsställande 6NFEdit
En enkel och intuitiv definition av den sjätte normala formen är att ”en tabell finns i 6NF när raden innehåller den primära nyckeln och högst ett annat attribut”.
Det betyder till exempel att tabellen Publisher är utformad när du skapar 1NF
| Publisher_ID | Namn | Land |
|---|---|---|
| 1 | Apress | USA |
måste vara längre sönderdelas i två tabeller:
|
|
Den uppenbara nackdelen med 6NF är spridningen av tabeller som krävs för att representera informationen om en enda enhet. Om en tabell i 5NF har en primär nyckelkolumn och N-attribut, som representerar samma information i 6NF kräver N-tabeller; Flera fältuppdateringar till en enda konceptuell post kräver uppdateringar till flera tabeller. och inlägg och raderingar kommer på samma sätt att kräva operationer över flera tabeller. Av denna anledning bör 6NF inte användas i databaser som är avsedda att tillgodose online-transaktionsbehandlingsbehov.
Men i datalager som inte tillåter interaktiva uppdateringar och som är specialiserade för snabba frågor om stora datamängder , vissa DBMS använder en intern 6NF-representation – känd som ett Columnar-datalager. I situationer där antalet unika värden i en kolumn är betydligt mindre än antalet rader i tabellen, möjliggör kolumnorienterad lagring betydande besparingar i utrymme genom datakomprimering. Kolumnlagring möjliggör också snabb körning av intervallfrågor (t.ex. visa alla poster där en viss kolumn är mellan X och Y, eller mindre än X.)
I alla dessa fall gör dock databasdesignern inte måste utföra 6NF-normalisering manuellt genom att skapa separata tabeller. Vissa DBMS som är specialiserade för lagerhållning, till exempel Sybase IQ, använder kolumnlagring som standard, men designern ser fortfarande bara en enda flerkolonnstabell. Med andra DBMS, till exempel Microsoft SQL Server 2012 och senare, kan du ange ett ”kolumnlagerindex” för en viss tabell.
