Databas normalisering - Database normalization

Databasnormalisering är processen att strukturera en databas , vanligtvis en relationsdatabas , i enlighet med en serie så kallade normala former för att minska dataredundans och förbättra dataintegritet . Det föreslogs först av Edgar F. Codd som en del av hans relationsmodell .

Normalisering innebär att man organiserar kolumnerna (attribut) och tabeller (relationer) i en databas för att säkerställa att deras beroenden verkställs korrekt av databasintegritetsbegränsningar. Det uppnås genom att tillämpa några formella regler antingen genom en syntesprocess (skapa en ny databasdesign) eller sönderdelning (förbättra en befintlig databasdesign).

Mål

Ett grundläggande mål med den första normala formen som definierades av Codd 1970 var att tillåta data att efterfrågas och manipuleras med hjälp av ett "universellt datasubspråk" baserat på första ordningens logik . ( SQL är ett exempel på ett sådant datasubspråk, om än ett som Codd ansåg vara allvarligt bristfälligt.)

Målen för normalisering utöver 1NF (första normala form) uppgavs enligt följande av Codd:

1. För att frigöra samlingen av relationer från oönskad infogning, uppdatering och borttagning av beroenden.
2. För att minska behovet av omstrukturering av samlingen av relationer, när nya typer av data introduceras, och därmed öka livslängden för applikationsprogram.
3. För att göra relationsmodellen mer informativ för användarna.
4. För att göra samlingen av relationer neutral för frågestatistiken, där denna statistik kan komma att ändras när tiden går.

-  EF Codd, "Ytterligare normalisering av datamaskinens relationella modell"

En uppdateringsanomali . Medarbetare 519 visas med olika adresser på olika poster.

En insättningsanomali . Innan den nya fakultetsmedlemmen, Dr. Newsome, får i uppdrag att undervisa minst en kurs, kan deras uppgifter inte registreras.

En borttagningsanomali . 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 ändra (uppdatera, infoga eller ta bort från) en relation kan följande oönskade biverkningar uppstå i relationer som inte har normaliserats tillräckligt:

• 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 kompetens" -relation innehålla ett medarbetar -ID, anställds adress och kompetens; Därför kan en adressändring för en viss anställd behöva tillämpas på flera poster (en för varje skicklighet). Om uppdateringen endast delvis lyckas - den anställdes adress uppdateras på vissa poster men inte andra - så lämnas relationen i ett inkonsekvent tillstånd. Specifikt ger relationen motstridiga svar på frågan om vad den här medarbetarens adress är. Detta fenomen är känt som en uppdateringsanomali.
• Insättningsanomali. Det finns omständigheter där vissa fakta inte alls kan registreras. Till exempel kan varje post i en "Fakultet och deras kurser" -relation innehålla ett fakultets -ID, fakultetsnamn, fakultetshyrningsdatum och kurskod. Därför kan detaljer om alla fakultetsmedlemmar som undervisar minst en kurs spelas in, men en nyanställd fakultetsmedlem som ännu inte har fått i uppdrag att undervisa några kurser kan inte spelas in, förutom genom att ställa in kurskoden till null . Detta fenomen är känt som en insättningsanomali.
• Radering anomali. Under vissa omständigheter kräver radering av data som representerar vissa fakta radering av data som representerar helt andra fakta. "Fakulteten och deras kurser" -relationen 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 fakultetsmedlem visas på raderas, effektivt raderar också fakultetsmedlemmen, om inte fältet Kurskod är inställt på null. Detta fenomen är känt som en deletionsanomali.

Minimera omdesign när databasstrukturen utökas

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 förhållanden.

Normala former

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

Informellt beskrivs en relationsdatabasrelation ofta som "normaliserad" om den uppfyller tredje normala form. De flesta 3NF -relationer är fria från infogning, uppdatering och borttagningsavvikelser.

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

	UNF (1970)	1NF (1970)	2NF (1971)	3NF (1971)	EKNF (1982)	BCNF (1974)	4NF (1977)	ETNF (2012)	5NF (1979)	DKNF (1981)	6NF (2003)
Primärnyckel (inga dubbletter tupler )
Atomkolumner (celler kan inte ha tabeller som värden)
Varje icke-trivialt funktionsberoende börjar antingen inte med en korrekt delmängd av en kandidatnyckel eller slutar med ett primattribut (inga partiella funktionella beroende av icke-prime-attribut på kandidatnycklar)
Varje icke-trivialt funktionsberoende börjar antingen med en supernyckel eller slutar med ett primattribut (inga transitiva funktionella beroenden för icke-prime-attribut på kandidatnycklar)
Varje icke-trivialt funktionsberoende börjar antingen med en supernyckel eller slutar med ett elementärt primattribut											Ej tillgängligt
Varje icke-trivialt funktionellt beroende börjar med en supernyckel											Ej tillgängligt
Varje icke-trivialt beroende med flera värderingar börjar med en supernyckel											Ej tillgängligt
Varje anslutningsberoende har en supernyckelkomponent											Ej tillgängligt
Varje anslutningsberoende har bara supernyckelkomponenter											Ej tillgängligt
Varje begränsning är en följd av domänbegränsningar och nyckelbegränsningar
Varje anslutningsberoende är trivialt

Exempel på en normalisering steg för steg

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 normaliseringsnivån, skulle det första steget vara att säkerställa att den första normala formen följs , det andra steget skulle vara att se till att den andra normala formen uppfylls, och så vidare i den ordning som nämns ovan tills data överensstämmer med sjätte normala formen .

Det är dock värt att notera att normala former bortom 4NF huvudsakligen är av akademiskt intresse, eftersom de problem de finns att lösa sällan förekommer i praktiken.

Observera att uppgifterna i följande exempel var avsiktligt utformade för att motsäga de flesta vanliga 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 motsäger den givna normala formen. Det förekommer också vanligt att åtgärdande av en kränkning av en normal form också åtgärdar en kränkning av en högre normal form 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 normala formen.

Initial data

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

För detta exempel antas att varje bok bara 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 -nummer identifierar en bok unikt, så den kan användas som huvudnyckel:

Tillfredsställande 1NF

För att uppfylla den första normala formen måste varje kolumn i en tabell ha ett enda värde. Kolumner som innehåller uppsättningar av värden eller kapslade poster är inte tillåtna.

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

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

En främmande nyckel kolumn till Ämne -table tillsättes, som hänvisar till den primära nyckeln av raden från vilket ämnet extraherades. Samma information är därför representerad 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

Den Book Bordet har en kandidatnyckel (som är därför den primärnyckel ), den sammansatta nyckeln {Titel, Format} . Tänk på följande tabellfragment:

Alla attribut som inte ingår i 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-nyckelattribut bero på hela kandidatnyckeln, inte bara en del av den.

För att normalisera den här tabellen gör du {Title} till en (enkel) kandidatnyckel (primärnyckeln) så att alla attribut som inte är kandidatnycklar beror på hela kandidatnyckeln och tar bort Price i en separat tabell så att dess beroende av Format kan vara bevarad:

Nu Book överensstämmer tabellen 2NF .

Tillfredsställande 3NF

Den bok tabellen fortfarande har en transitiv funktionellt beroende ({Författare nationalitet} är beroende {Författare}, som är beroende av {Title}). En liknande överträdelse finns för genre ({Genre Name} är beroende av {Genre ID}, som är beroende av {Title}). Därför är boken är tabellen inte i 3NF. För att göra det i 3NF, låt oss använda följande tabellstruktur och därigenom eliminera de transitiva funktionella beroenden genom att placera {Author Nationality} och {Genre Name} i sina egna respektive tabeller:

Tillfredsställande EKNF

Elementary key normal form (EKNF) faller strikt mellan 3NF och BCNF och diskuteras inte mycket i litteraturen. Den är avsedd att "fånga de framträdande egenskaperna hos både 3NF och BCNF" samtidigt som man undviker båda problemen (nämligen att 3NF är "för förlåtande" och BCNF är "benägen för beräkningskomplexitet"). Eftersom det sällan nämns i litteratur ingår det inte i detta exempel.

Tillfredsställande 4NF

Antag att databasen ägs av en bokhandlarfranchise 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 data om böckernas tillgänglighet på olika platser:

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

Det betyder att för att uppfylla den fjärde normala formen måste denna tabell också sönderdelas:

Nu identifieras varje rekord entydigt av en supernyckel , därför är 4NF nöjd.

Tillfredsställande ETNF

Antag att franchisetagarna också kan beställa böcker från olika leverantörer. Låt förhållandet också omfattas av följande begränsningar:

• Om en viss leverantör levererar en viss titel
• och titeln levereras till franchisetagaren
• och franchisetagaren levereras av leverantören,
• sedan levererar leverantören titeln till franchisetagaren .

Denna tabell är i 4NF , men leverantörs -ID är lika med sammanfogningen av dess prognoser: {{Supplier ID, Book}, {Book, Franchisee ID}, {Franchisee ID, Supplier ID}}. Ingen komponent i det anslutningsberoendet är en supernyckel (den enda supernyckeln är hela rubriken), så tabellen uppfyller inte ETNF och kan sönderdelas ytterligare:

Nedbrytningen ger ETNF -överensstämmelse.

Tillfredsställande 5NF

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

Nedbrytning av denna tabell minskar uppsägningar, vilket resulterar i följande två tabeller:

Frågan som går med i dessa tabeller skulle returnera följande data:

JOIN returnerar tre rader mer än det borde; lägga till ytterligare en tabell för att klargöra relationsresultaten i tre separata tabeller:

Vad kommer JOIN tillbaka 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 DKNF

Låt oss ta en titt på boken bord från tidigare exempel och se om det uppfyller Domain-key normalform :

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

Denna konvention är tekniskt sett en begränsning men den är varken en domänbegränsning eller en nyckelbegränsning; Därför kan vi inte förlita oss på domänbegränsningar och nyckelbegränsningar för att behålla dataintegriteten.

Med andra ord - ingenting hindrar oss från att lägga till exempel "Tjockt" för en bok med bara 50 sidor - och det gör att bordet bryter mot DKNF .

För att lösa detta skapas en tabell med en uppräkning som definierar tjockleken och kolumnen tas bort från den ursprungliga tabellen:

På så sätt har domänintegritetsöverträdelsen eliminerats och tabellen finns 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 primärnyckeln och högst ett annat attribut" .

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

måste brytas ner ytterligare 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 kräver N -tabeller för att representera samma information i 6NF; uppdateringar av flera fält till en enda konceptuell post kommer att kräva uppdateringar av flera tabeller; och inlägg och borttagningar kommer på samma sätt att kräva operationer över flera tabeller. Av denna anledning, i databaser som är avsedda att tjäna Online Transaction Processing behov 6NF bör inte användas.

Men i datalager , som inte tillåter interaktiva uppdateringar och som är specialiserade på snabba förfrågningar om stora datavolymer, använder vissa DBMS en intern 6NF -representation - känd som en kolumnerad datalagring . I situationer där antalet unika värden för en kolumn är mycket mindre än antalet rader i tabellen, tillåter kolumnorienterad lagring betydande platsbesparingar genom datakomprimering. Kolumnlagring tillåter 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 behöver dock databasdesignern inte utföra 6NF -normalisering manuellt genom att skapa separata tabeller. Vissa DBMS som är specialiserade för lagring, till exempel Sybase IQ , använder kolumnlagring som standard, men designern ser fortfarande bara en enda tabell med flera kolumner. Andra DBMS, till exempel Microsoft SQL Server 2012 och senare, låter dig ange ett "columnstore index" för en viss tabell.

Se även

• Denormalisering
• Renovering av databas

• Förlustlös sammanfogning

Anteckningar och referenser

Vidare läsning

• Date, CJ (1999), An Introduction to Database Systems (8: e upplagan). Addison-Wesley Longman. ISBN  0-321-19784-4 .
• Kent, W. (1983) A Simple Guide to Five Normal Forms in Relational Database Theory , Communications of the ACM, vol. 26, s. 120–125
• H.-J. Schek, P. Pistor Datastrukturer för ett integrerat databashanterings- och informationshämtningssystem

externa länkar

• Kent, William (februari 1983). "En enkel guide till fem normala former i relationell databassteori" . Kommunikation av ACM . 26 (2): 120–125. doi : 10.1145/358024.358054 . S2CID  9195704 .
• Database Normalization Basics av Mike Chapple (About.com)
• Intro för normalisering av databas , del 2
• En introduktion till databasnormalisering av Mike Hillyer.
• En handledning om de tre första normala formerna av Fred Coulson
• Beskrivning av grunderna för normalisering av databasen av Microsoft
• Normalisering i DBMS av Chaitanya (beginnersbook.com)
• En steg-för-steg-guide till databasnormalisering
• ETNF - Essential tuple normal form