Beskrivning av grunderna för databasnormalisering

Den här artikeln beskriver databasnormaliseringsterminologi för nybörjare. En grundläggande förståelse av den här terminologin är användbar när du diskuterar utformningen av en relationsdatabas.

Beskrivning av normalisering

Normalisering är processen att organisera data i en databas. Den omfattar att skapa tabeller och upprätta relationer mellan dessa tabeller enligt regler som utformats både för att skydda data och för att göra databasen mer flexibel genom att eliminera redundans och inkonsekvent beroende.

Redundanta data slösar bort diskutrymme och skapar underhållsproblem. Om data som finns på mer än en plats måste ändras måste data ändras på exakt samma sätt på alla platser. En ändring av kundadresser är enklare att implementera om dessa data endast lagras i tabellen Kunder och ingen annanstans i databasen.

Vad är ett "inkonsekvent beroende"? Även om det är intuitivt för en användare att leta efter adressen till en viss kund i tabellen Kunder, kanske det inte är meningsfullt att leta där efter lönen för den medarbetare som anropar kunden. Medarbetarens lön är relaterad till eller beroende av den anställde och bör därför flyttas till tabellen Anställda. Inkonsekventa beroenden kan göra det svårt att komma åt data eftersom sökvägen för att hitta data kan saknas eller brytas.

Det finns några regler för databasnormalisering. Varje regel kallas för ett "normalt formulär". Om den första regeln observeras sägs databasen vara i "första normala form". Om de tre första reglerna följs anses databasen vara i "tredje normal form". Även om andra normaliseringsnivåer är möjliga anses den tredje normala formen vara den högsta nivån som krävs för de flesta program.

Precis som med många formella regler och specifikationer tillåter verkliga scenarier inte alltid perfekt efterlevnad. I allmänhet kräver normalisering ytterligare tabeller och vissa kunder tycker att detta är besvärligt. Om du bestämmer dig för att bryta mot någon av de tre första normaliseringsreglerna kontrollerar du att programmet förväntar sig eventuella problem som kan uppstå, till exempel redundanta data och inkonsekventa beroenden.

Följande beskrivningar innehåller exempel.

Första normala formen

• Eliminera upprepade grupper i enskilda tabeller.
• Skapa en separat tabell för varje uppsättning relaterade data.
• Identifiera varje uppsättning relaterade data med en primärnyckel.

Använd inte flera fält i en enda tabell för att lagra liknande data. Om du till exempel vill spåra en inventeringsartikel som kan komma från två möjliga källor kan en inventeringspost innehålla fält för Leverantörskod 1 och Leverantörskod 2.

Vad händer när du lägger till en tredje leverantör? Att lägga till ett fält är inte svaret. Det kräver program- och tabelländringar och rymmer inte ett dynamiskt antal leverantörer på ett smidigt sätt. Placera i stället all leverantörsinformation i en separat tabell med namnet Leverantörer och länka sedan inventeringen till leverantörer med en artikelnummernyckel eller leverantörer till inventeringen med en leverantörskodnyckel.

Andra normala formen

• Skapa separata tabeller för uppsättningar av värden som gäller för flera poster.
• Relatera dessa tabeller med en främmande nyckel.

Poster bör inte vara beroende av något annat än en tabells primärnyckel (en sammansatt nyckel om det behövs). Tänk till exempel på en kunds adress i ett redovisningssystem. Adressen krävs av tabellen Kunder, men även av tabellerna Beställningar, Leverans, Fakturor, Kundreskontra och Samlingar. I stället för att lagra kundens adress som en separat post i var och en av dessa tabeller lagrar du den på ett ställe, antingen i tabellen Kunder eller i en separat tabell med adresser.

Tredje normala formen

• Eliminera fält som inte är beroende av nyckeln.

Värden i en post som inte ingår i postens nyckel hör inte hemma i tabellen. När som helst som innehållet i en grupp med fält kan gälla för mer än en post i tabellen bör du överväga att placera dessa fält i en separat tabell.

I en rekryteringstabell för anställda kan till exempel en kandidats universitetsnamn och adress inkluderas. Men du behöver en fullständig lista över universitet för gruppmeddelanden. Om universitetsinformation lagras i tabellen Kandidater finns det inget sätt att lista universitet utan nuvarande kandidater. Skapa en separat universitetstabell och länka den till tabellen Kandidater med en kodnyckel för universitetet.

UNDANTAG: Att följa den tredje normala formen, även om det teoretiskt sett är önskvärt, är inte alltid praktiskt. Om du har en kundtabell och vill eliminera alla möjliga beroenden mellan olika områden måste du skapa separata tabeller för städer, postnummer, säljare, kundklasser och andra faktorer som kan dupliceras i flera poster. I teorin är normalisering värt att sträva efter. Många små tabeller kan dock försämra prestanda eller överskrida öppna fil- och minneskapaciteter.

Det kan vara mer möjligt att tillämpa tredje normal form endast på data som ändras ofta. Om vissa beroende fält finns kvar utformar du programmet så att användaren måste verifiera alla relaterade fält när någon av dem ändras.

Andra normaliseringsformulär

Fjärde normal form, även kallad Boyce-Codd Normal Form (BCNF), och femte normal form finns, men är sällan i praktisk design. Om du bortser från dessa regler kan det leda till en mindre perfekt databasdesign, men det bör inte påverka funktionaliteten.

Normalisera en exempeltabell

De här stegen visar hur du normaliserar en fiktiv studenttabell.

1. Onormaliserad tabell:

   Student#	Rådgivare	Adv-Room	Klass 1	Klass 2	Klass 3
   1022	Jones	412	101-07	143-01	159-02
   4123	Smith	216	101-07	143-01	179-04

2. Första normala formuläret: Inga upprepande grupper

   Tabeller bör bara ha två dimensioner. Eftersom en elev har flera klasser bör dessa klasser visas i en separat tabell. Fälten Class1, Class2 och Class3 i ovanstående poster är tecken på designproblem.

   Kalkylblad använder ofta den tredje dimensionen, men tabeller bör inte göra det. Ett annat sätt att se på det här problemet är med en en-till-många-relation, placera inte den ena sidan och de många sidorna i samma tabell. Skapa i stället en annan tabell i första normal form genom att eliminera den upprepande gruppen (Class#), som du ser i följande exempel:

   Student#	Rådgivare	Adv-Room	Klass#
   1022	Jones	412	101-07
   1022	Jones	412	143-01
   1022	Jones	412	159-02
   4123	Smith	216	101-07
   4123	Smith	216	143-01
   4123	Smith	216	179-04

3. Andra normala formen: Eliminera redundanta data

   Observera flera Class#- värden för varje Student#- värde i tabellen ovan. Class# är inte funktionellt beroende av Student# (primär nyckel), så den här relationen är inte i andra normala form.

   Följande tabeller visar det andra normala formatet:

   Studenter:

   Student#	Rådgivare	Adv-Room
   1022	Jones	412
   4123	Smith	216

   Registrering:

   Studentnummer	Klass#
   1022	101-07
   1022	143-01
   1022	159-02
   4123	101-07
   4123	143-01
   4123	179-04

4. Tredje normala formen: Eliminera data som inte är beroende av nyckeln

   I det sista exemplet är Adv-Room (rådgivarens kontorsnummer) funktionellt beroende av advisor-attributet. Lösningen är att flytta attributet från tabellen Studenter till tabellen Fakultet enligt nedan:

   Studenter:

   Student#	Rådgivare
   1022	Jones
   4123	Smith

   Fakultet:

   Namn	Rum	Avd
   Jones	412	42
   Smith	216	42