Databasnormalisering

Databasnormalisering eller databasnormalisering (se stavningsskillnader ) är processen att strukturera en relationsdatabas i enlighet med en serie så kallade normala former för att minska dataredundans och förbättra dataintegriteten . Det föreslogs först av den brittiske datavetaren Edgar F. Codd som en del av hans relationsmodell .

Normalisering innebär att organisera kolumner (attribut) och tabeller (relationer) i en databas för att säkerställa att deras beroenden upprätthålls korrekt av databasintegritetsbegränsningar. Det åstadkoms genom att tillämpa några formella regler antingen genom en syntesprocess ( skapa en ny databasdesign) eller nedbrytning (förbättra en befintlig databasdesign).

Mål

Ett grundläggande syfte med den första normala formen som definierades av Codd 1970 var att tillåta att data efterfrågas och manipuleras med ett "universellt dataunderspråk" grundat i första ordningens logik . Ett exempel på ett sådant språk är SQL , även om det är ett som Codd betraktade som allvarligt felaktigt.

Målen för normalisering bortom 1NF (första normala formen) angavs av Codd som:

  1. För att befria insamlingen av relationer från oönskade insättnings-, uppdaterings- och raderingsberoenden.
  2. För att minska behovet av omstrukturering av insamlingen av relationer, när nya typer av data introduceras, och därmed öka livslängden för applikationsprogram.
  3. Att göra relationsmodellen mer informativ för användarna.
  4. Att göra insamlingen av relationer neutral till frågestatistiken, där denna statistik kan komma att förändras med tiden.
— EF Codd, "Ytterligare normalisering av databasens relationsmodell"
En insättningsavvikelse . Tills den nya fakultetsmedlemmen, Dr. Newsome, har fått i uppdrag att undervisa i minst en kurs, kan deras uppgifter inte registreras.
En uppdateringsavvikelse . Anställd 519 visas ha olika adresser på olika poster.
En raderingsanomali . All information om Dr Giddens går förlorad om de tillfälligt upphör att tilldelas några kurser.

När ett försök görs att modifiera (uppdatera, infoga i eller ta bort från) en relation kan följande oönskade biverkningar uppstå i relationer som inte har normaliserats tillräckligt:

  • Insättningsavvikelse. Det finns omständigheter under vilka vissa fakta inte alls kan registreras. Till exempel kan varje post i en "Fakultet och deras kurser"-relation innehålla ett fakultets-ID, fakultetsnamn, fakultetsanställningsdatum och kurskod. Därför kan uppgifterna om en fakultetsmedlem som undervisar i minst en kurs registreras, men en nyanställd fakultetsmedlem som ännu inte har fått i uppdrag att undervisa i några kurser kan inte registreras, förutom genom att sätta kurskoden på null .
  • Uppdatera anomali. Samma information kan uttryckas på flera rader; Därför kan uppdateringar av relationen leda till logiska inkonsekvenser. Till exempel kan varje post i en "Anställdas färdigheter"-relation innehålla ett anställd-ID, anställds adress och kompetens; Således kan en adressändring för en viss anställd behöva tillämpas på flera poster (en för varje färdighet). Om uppdateringen endast delvis lyckas – den anställdes adress uppdateras på vissa poster men inte i andra – lämnas relationen i ett inkonsekvent tillstånd. Specifikt ger relationen motstridiga svar på frågan om vad just denna anställdes adress är.
  • Borttagningsavvikelse. Under vissa omständigheter kräver radering av uppgifter som representerar vissa fakta radering av uppgifter som representerar helt andra fakta. Relationen "Fakulteten och deras kurser" som beskrivs i det föregående exemplet lider av denna typ av anomali, för om en fakultetsmedlem tillfälligt upphör att tilldelas några kurser, måste den sista av de poster som den fakultetsmedlemmen förekommer på raderas, i praktiken tar också bort fakultetsmedlemmen, såvida inte fältet Kurskod är satt till null.

Minimera omdesign när du utökar databasstrukturen

En helt normaliserad databas gör att dess struktur kan utökas för att rymma nya typer av data utan att ändra befintlig struktur för mycket. Som ett resultat påverkas applikationer som interagerar med databasen minimalt.

Normaliserade relationer, och förhållandet mellan en normaliserad relation och en annan, speglar verkliga begrepp och deras inbördes relationer.

Normala former

Codd introducerade begreppet normalisering och vad som nu är känt som den första normala formen (1NF) 1970. Codd fortsatte med att definiera den andra normala formen (2NF) och tredje normalformen (3NF) 1971, och Codd och Raymond F. Boyce definierade Boyce-Codd normalformen (BCNF) 1974.

Informellt beskrivs en relationsdatabasrelation ofta som "normaliserad" om den uppfyller tredje normalformen. De flesta 3NF-relationer är fria från insättnings-, uppdaterings- och raderingsavvikelser.

De normala formerna (från minst normaliserade till mest normaliserade) är:


Begränsning (informell beskrivning inom parentes)
UNF (1970)
1NF (1970)
2NF (1971)
3NF (1971)
EKNF (1982)
BCNF (1974)
4NF (1977)
ETNF (2012)
5NF (1979)
DKNF (1981)
6NF (2003)
Unika rader (inga dubbletter av poster) Maybe Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Skalära kolumner (kolumner kan inte innehålla relationer eller sammansatta värden) No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Varje icke-primärt attribut har ett fullt funktionellt beroende av en kandidatnyckel (attribut beror på den fullständiga primärnyckeln) No No Yes Yes Yes Yes Yes Yes Yes Yes Yes
Varje icke-trivialt funktionellt beroende börjar antingen med en supernyckel eller slutar med ett primärt attribut (attribut beror bara på primärnyckeln) No No No Yes Yes Yes Yes Yes Yes Yes Yes
Varje icke-trivialt funktionellt beroende börjar antingen med en supernyckel eller slutar med ett elementärt primattribut (en strängare form av 3NF) No No No No Yes Yes Yes Yes Yes Yes —
Varje icke-trivialt funktionellt beroende börjar med en supernyckel (en strängare form av 3NF) No No No No No Yes Yes Yes Yes Yes —
Varje icke-trivialt flervärdigt beroende börjar med en supernyckel No No No No No No Yes Yes Yes Yes —
Varje anslutningsberoende har en supernyckelkomponent No No No No No No No Yes Yes Yes —
Varje anslutningsberoende har bara supernyckelkomponenter No No No No No No No No Yes Yes —
Varje begränsning är en konsekvens av domänbegränsningar och nyckelbegränsningar No No No No No No No No No Yes No
Varje kopplingsberoende är trivialt No No No No No No No No No No Yes

Exempel på en steg för steg normalisering

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 de tidigare nivåerna har uppfyllts.

Det betyder att, med data i onormaliserad form (den minst normaliserade) och som syftar till att uppnå den högsta nivån av normalisering, 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 normalformen .

Det är dock värt att notera att normala former utöver 4NF främst är av akademiskt intresse, eftersom de problem de finns för att lösa sällan dyker upp i praktiken.

Data i följande exempel var avsiktligt utformade för att motsäga de flesta normala formerna. I det verkliga livet är det fullt möjligt att kunna hoppa över några av normaliseringsstegen eftersom tabellen inte innehåller något som motsäger den givna normalformen. Det är också vanligt att fixa ett brott av en normalform också fixar ett brott av en högre normalform i processen. En tabell har också valts för normalisering vid varje steg, vilket innebär att i slutet av denna exempelprocess kan det fortfarande finnas några tabeller som inte uppfyller den högsta normalformen.

Inledande data

Låt en databastabell existera med följande struktur:

Titel Författare Författarens nationalitet Formatera Pris Ämne Sidor Tjocklek Utgivare Utgivarland Publikationstyp Genre ID Genrens namn
Börjar design och optimering av MySQL-databas Chad Russell amerikansk Hårt omslag 49,99
MySQL
-
databasdesign
520 Tjock Apress USA E-bok 1 Handledning

För detta exempel antas det att varje bok endast har en författare.

Som en förutsättning för att överensstämma med relationsmodellen måste en tabell ha en primärnyckel , som unikt identifierar en rad. Två böcker kan ha samma titel, men ett ISBN identifierar en bok unikt, så det kan användas som primärnyckel:

ISBN Titel Författare Författarens nationalitet Formatera Pris Ämne Sidor Tjocklek Utgivare Utgivarland Publikationstyp Genre ID Genrens namn
1590593324 Börjar design och optimering av MySQL-databas Chad Russell amerikansk Hårt omslag 49,99
MySQL
-
databasdesign
520 Tjock Apress USA E-bok 1 Handledning

Tillfredsställande 1NF

För att uppfylla First normal form måste varje kolumn i en tabell ha ett enda värde. Kolumner som innehåller uppsättningar värden eller kapslade poster är inte tillåtna.

I den inledande tabellen innehåller Ämne en uppsättning ämnesvärden, vilket betyder att den inte överensstämmer.

För att lösa problemet extraheras ämnena i en separat Ämnestabell :

bok
ISBN Titel Formatera Författare Författarens nationalitet Pris Sidor Tjocklek Utgivare Utgivarland Genre ID Genrens namn
1590593324 Börjar design och optimering av MySQL-databas Hårt omslag Chad Russell amerikansk 49,99 520 Tjock Apress USA 1 Handledning
Ämne
ISBN Ämnesnamn
1590593324 MySQL
1590593324 Databas
1590593324 Design

En främmande nyckelkolumn läggs till i Subject -tabellen, som hänvisar till primärnyckeln på raden från vilken ämnet extraherades. Samma information representeras därför men utan användning av icke-enkla domäner.

Istället för en tabell i onormaliserad form finns det nu två tabeller som överensstämmer med 1NF.

Tillfredsställande 2NF


Om en tabell har en primärnyckel med en kolumn, uppfyller den automatiskt 2NF, men om en tabell har en flerkolumn eller sammansatt nyckel kanske den inte uppfyller 2NF. Boktabellen nedan har en sammansatt nyckel av {Title, Format} (anges av understrykningen), så den kanske inte uppfyller 2NF . Vid denna tidpunkt i vår design är nyckeln inte slutgiltig som primärnyckel , så den kallas en kandidatnyckel . Tänk på följande tabell:

bok
Titel Formatera Författare Författarens nationalitet Pris Sidor Tjocklek Genre ID Genrens namn Utgivar-ID
Börjar design och optimering av MySQL-databas Hårt omslag Chad Russell amerikansk 49,99 520 Tjock 1 Handledning 1
Börjar design och optimering av MySQL-databas 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är vetenskap 2
Relationsmodellen för databashantering: Version 2 Pocketbok EFCodd brittisk 39,99 538 Tjock 2 Populär vetenskap 2

Alla attribut som inte är en del av kandidatnyckeln beror på Titel , men endast Pris beror också på Format . För att överensstämma med 2NF och ta bort dubbletter måste varje icke-kandidat-nyckel-attribut bero på hela kandidatnyckeln, inte bara en del av den.

För att normalisera denna tabell, gör {Title} till en (enkel) kandidatnyckel (primärnyckeln) så att alla icke-kandidatnyckelattribut beror på hela kandidatnyckeln, och ta bort Price till en separat tabell så att dess beroende av Format kan bevaras:

bok
Titel Författare Författarens nationalitet Sidor Tjocklek Genre ID Genrens namn Utgivar-ID
Börjar design och optimering av MySQL-databas Chad Russell amerikansk 520 Tjock 1 Handledning 1
Relationsmodellen för databashantering: Version 2 EFCodd brittisk 538 Tjock 2 Populär vetenskap 2
Format - Pris
Titel Formatera Pris
Börjar design och optimering av MySQL-databas Hårt omslag 49,99
Börjar design och optimering av MySQL-databas E-bok 22.34
Relationsmodellen för databashantering: Version 2 E-bok 13,88
Relationsmodellen för databashantering: Version 2 Pocketbok 39,99
Utgivare
Utgivar-ID namn Land
1 Apress USA
2 Addison-Wesley USA

Nu överensstämmer boktabellen med 2NF .

Tillfredsställande 3NF

Boktabellen har fortfarande ett transitivt funktionellt beroende ({Author Nationality} är beroende av {Author}, vilket är beroende av {Title}) . En liknande överträdelse finns för genren ({Genre Name} är beroende av {Genre ID}, som är beroende av {Title}). Därför boktabellen i 3NF. För att göra det i 3NF, låt oss använda följande tabellstruktur, och därmed eliminera de transitiva funktionella beroenden genom att placera {Author Nationality} och {Genre Name} i sina respektive tabeller:

bok
Titel Författare Sidor Tjocklek Genre ID Utgivar-ID
Börjar design och optimering av MySQL-databas Chad Russell 520 Tjock 1 1
Relationsmodellen för databashantering: Version 2 EFCodd 538 Tjock 2 2
Pris
Titel Formatera Pris
Börjar design och optimering av MySQL-databas Hårt omslag 49,99
Börjar design och optimering av MySQL-databas E-bok 22.34
Relationsmodellen för databashantering: Version 2 E-bok 13,88
Relationsmodellen för databashantering: Version 2 Pocketbok 39,99
Författare
Författare Författarens nationalitet
Chad Russell amerikansk
EFCodd brittisk
Genre
Genre ID Genrens namn
1 Handledning
2 Populär vetenskap

Tillfredsställande EKNF

Huvudartikel: Elementär nyckel normalform

Den elementära nyckelnormalformen (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 med båda (nämligen att 3NF är "för förlåtande" och BCNF är "benägen till beräkningskomplexitet"). Eftersom det sällan nämns i litteraturen ingår det inte i detta exempel.

Tillfredsställande 4NF

Anta att databasen ägs av en bokhandelsfranchise som har flera franchisetagare som äger butiker på olika platser. Och därför bestämde sig återförsäljaren för att lägga till en tabell som innehåller information om tillgängligheten för böckerna på olika platser:

Franchisetagare - Boka - Plats
Franchisetagarens ID Titel Plats
1 Börjar design och optimering av MySQL-databas Kalifornien
1 Börjar design och optimering av MySQL-databas Florida
1 Börjar design och optimering av MySQL-databas 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 design och optimering av MySQL-databas Kalifornien
2 Börjar design och optimering av MySQL-databas Florida
2 Börjar design och optimering av MySQL-databas 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 design och optimering av MySQL-databas Texas

Eftersom den här tabellstrukturen består av en sammansatt primärnyckel innehåller den inga icke-nyckelattribut och den finns redan i BCNF (och uppfyller därför även alla tidigare normala former ). Men förutsatt att alla tillgängliga böcker erbjuds i varje område, titeln inte entydigt bunden till en viss plats och därför uppfyller tabellen inte 4NF .

Det betyder att, för att tillfredsställa den fjärde normalformen , måste denna tabell också delas upp:

Franchisetagare - Bok
Franchisetagarens ID Titel
1 Börjar design och optimering av MySQL-databas
1 Relationsmodellen för databashantering: Version 2
2 Börjar design och optimering av MySQL-databas
2 Relationsmodellen för databashantering: Version 2
3 Börjar design och optimering av MySQL-databas
Franchisetagare - Plats
Franchisetagarens 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 uppfylld.

Tillfredsställande ETNF

Anta att franchisetagarna också kan beställa böcker från olika leverantörer. Låt relationen också vara föremål för följande begränsning:

  • Om en viss leverantör tillhandahåller en viss titel
  • och titeln levereras till franchisetagaren
  • och franchisetagaren levereras av leverantören,
  • sedan tillhandahåller leverantören titeln till franchisetagaren .
Leverantör - Boka - Franchisetagare
Leverantörs-ID Titel Franchisetagarens ID
1 Börjar design och optimering av MySQL-databas 1
2 Relationsmodellen för databashantering: Version 2 2
3 Att lära sig SQL 3

Den här tabellen är i 4NF , men leverantörs-ID är lika med sammanfogningen av dess projektioner: {{Leverantörs-ID, Titel}, {Titel, Franchisetagare-ID}, {Franchisetagare-ID, Leverantörs-ID}}. Ingen komponent i det anslutningsberoendet är en supernyckel (den enda supernyckeln är hela rubriken), så tabellen uppfyller inte ETNF och kan dekomponeras ytterligare:

Leverantör - Bok
Leverantörs-ID Titel
1 Börjar design och optimering av MySQL-databas
2 Relationsmodellen för databashantering: Version 2
3 Att lära sig SQL
Boka - Franchisetagare
Titel Franchisetagarens ID
Börjar design och optimering av MySQL-databas 1
Relationsmodellen för databashantering: Version 2 2
Att lära sig SQL 3
Franchisetagare - Leverantör
Leverantörs-ID Franchisetagarens ID
1 1
2 2
3 3

Nedbrytningen ger ETNF-efterlevnad.

Tillfredsställande 5NF

För att upptäcka en tabell som inte uppfyller 5NF är det vanligtvis nödvändigt att undersöka uppgifterna noggrant. Antag att tabellen från 4NF-exemplet med en liten modifiering av data och låt oss undersöka om den uppfyller 5NF :

Franchisetagare - Boka - Plats
Franchisetagarens ID Titel Plats
1 Börjar design och optimering av MySQL-databas Kalifornien
1 Att lära sig SQL Kalifornien
1 Relationsmodellen för databashantering: Version 2 Texas
2 Relationsmodellen för databashantering: Version 2 Kalifornien

Att sönderdela denna tabell minskar redundanserna, vilket resulterar i följande två tabeller:

Franchisetagare - Bok
Franchisetagarens ID Titel
1 Börjar design och optimering av MySQL-databas
1 Att lära sig SQL
1 Relationsmodellen för databashantering: Version 2
2 Relationsmodellen för databashantering: Version 2
Franchisetagare - Plats
Franchisetagarens ID Plats
1 Kalifornien
1 Texas
2 Kalifornien

Frågan som förenar dessa tabeller skulle returnera följande data:

Franchisetagare - Boka - Plats GÄLLDE MED
Franchisetagarens ID Titel Plats
1 Börjar design och optimering av MySQL-databas Kalifornien
1 Att lära sig SQL Kalifornien
1 Relationsmodellen för databashantering: Version 2 Kalifornien
1 Relationsmodellen för databashantering: Version 2 Texas
1 Att lära sig SQL Texas
1 Börjar design och optimering av MySQL-databas Texas
2 Relationsmodellen för databashantering: Version 2 Kalifornien

JOIN returnerar tre fler rader än den borde; lägga till ytterligare en tabell för att förtydliga relationen resulterar i tre separata tabeller:

Franchisetagare - Bok
Franchisetagarens ID Titel
1 Börjar design och optimering av MySQL-databas
1 Att lära sig SQL
1 Relationsmodellen för databashantering: Version 2
2 Relationsmodellen för databashantering: Version 2
Franchisetagare - Plats
Franchisetagarens ID Plats
1 Kalifornien
1 Texas
2 Kalifornien
Plats - Boka
Plats Titel
Kalifornien Börjar design och optimering av MySQL-databas
Kalifornien Att lära sig SQL
Kalifornien Relationsmodellen för databashantering: Version 2
Texas Relationsmodellen för databashantering: Version 2

Vad kommer JOIN att returnera nu? Det är faktiskt inte möjligt att sammanfoga dessa tre bord. Det betyder att det inte var möjligt att dekomponera Franchisetagaren - Boka - Plats 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 DKNF

Låt oss ta en titt på boktabellen från tidigare exempel och se om den uppfyller domännyckelns normala form :

bok
Titel Sidor Tjocklek Genre ID Utgivar-ID
Börjar design och optimering av MySQL-databas 520 Tjock 1 1
Relationsmodellen för databashantering: Version 2 538 Tjock 2 2
Att lära sig SQL 338 Smal 1 3
SQL kokbok 636 Tjock 1 3

Logiskt sett bestäms tjockleken av antalet sidor. Det betyder att det beror på sidor som inte är en nyckel. Låt oss ge ett exempel som säger att en bok på upp till 350 sidor anses vara "tunn" och en bok över 350 sidor anses vara "tjock".

Denna konvention är tekniskt sett en restriktion men den är varken en domänrestriktion eller en nyckelrestriktion; Därför kan vi inte lita på domänbegränsningar och nyckelbegränsningar för att behålla dataintegriteten.

Med andra ord – ingenting hindrar oss från att sätta till exempel "Tjock" för en bok på bara 50 sidor – och det gör att tabellen strider mot DKNF .

skapas en tabell med en uppräkning som definierar tjockleken, och den kolumnen tas bort från den ursprungliga tabellen:

Tjocklek Enum
Tjocklek Minsta sidor Max sidor
Smal 1 350
Tjock 351 999 999 999 999
Bok - Sidor - Genre - Förlag
Titel Sidor Genre ID Utgivar-ID
Börjar design och optimering av MySQL-databas 520 1 1
Relationsmodellen för databashantering: Version 2 538 2 2
Att lära sig SQL 338 1 3
SQL kokbok 636 1 3

På så sätt har domänintegritetsintrånget eliminerats och tabellen är i DKNF .

Tillfredsställande 6NF

En enkel och intuitiv definition av den sjätte normalformen är att "en tabell är i 6NF när raden innehåller den primära nyckeln och högst ett annat attribut" .

Det betyder, till exempel, Publisher -tabellen som designades när 1NF skapades

Utgivare
Utgivar-ID namn Land
1 Apress USA

måste delas upp ytterligare i två tabeller:

Utgivare
Utgivar-ID namn
1 Apress
Utgivarland
Utgivar-ID Land
1 USA

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, kommer att representera samma information i 6NF att kräva N tabeller; flerfältsuppdateringar till en enda konceptuell post kommer att kräva uppdateringar av flera tabeller; och infogning och borttagning kommer på liknande sätt att kräva operationer över flera tabeller. bör 6NF inte användas i databaser som är avsedda att tjäna onlinetransaktionsbehandlingsbehov .

Men i datalager , som inte tillåter interaktiva uppdateringar och som är specialiserade för snabba frågor om stora datavolymer, använder vissa DBMS en intern 6NF-representation – känd som ett kolumnärt datalager . I situationer där antalet unika värden i en kolumn är mycket mindre än antalet rader i tabellen tillåter kolumnorienterad lagring avsevärda besparingar i utrymme genom datakomprimering. Kolumnlagring tillåter också snabb exekvering av intervallfrågor (visa t.ex. alla poster där en viss kolumn är mellan X och Y, eller mindre än X.)

I alla dessa fall behöver dock inte databasdesignern utföra 6NF-normalisering manuellt genom att skapa separata tabeller. Vissa DBMS som är specialiserade för lagerhållning, som Sybase IQ , använder kolumnlagring som standard, men designern ser fortfarande bara en enda flerkolumntabell. Andra DBMS, som Microsoft SQL Server 2012 och senare, låter dig ange ett "kolumnlagerindex" för en viss tabell.

Se även

Anteckningar och referenser

Vidare läsning

externa länkar

Hämtad från " https://sv.wikipedia.org/w/index.php?title=Database_normalization&oldid=1136998975 "