Beskrivning av grunderna i databasnormalisering

Anteckning

Office 365 ProPlus byter namn till Microsoft 365-appar för företag. Mer information om den här ändringen finns i det här blogginlägget.

Original-KB-nummer:   283878

I den här artikeln förklaras terminologin för databasnormalisering 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 normaliseringen

Normalisering är processen med att ordna data i en databas. Detta omfattar att skapa tabeller och etablera relationer mellan tabellerna 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 på 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 kundadressen är mycket enklare att implementera om dessa data bara 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 i tabellen Kunder efter en viss kunds adress kanske det inte är meningsfullt att leta där efter lönen för den anställda som ringer till den kunden. Den anställdes lön är relaterad till, eller beroende av, den anställda och bör därför flyttas till tabellen Anställda. Inkonsekventa beroenden kan göra data svåra att komma åt eftersom sökvägen för att hitta data kan saknas eller vara trasig.

Det finns några regler för databasnormalisering. Varje regel kallas för en "normal form". Om den första regeln observeras säger man att databasen är i "den första normalformen". Om de tre första reglerna observeras anses databasen vara i "tredje normalformen". Även om andra normaliseringsnivåer är möjliga, anses den tredje normalformen 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. Normalisering kräver i allmänhet 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 ska du se till att programmet förutser eventuella problem som kan uppstå, till exempel redundanta data och inkonsekventa beroenden.

Följande beskrivningar innehåller exempel.

Den första normalformen

  • Ta bort grupper som upprepas 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 om du vill lagra liknande data. Om du till exempel vill spåra en lagerartikel som kan komma från två möjliga källor kan en lagerpost 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 kan inte smidigt hantera ett dynamiskt antal leverantörer. Placera i stället all leverantörsinformation i en separat tabell med namnet Leverantörer och länka sedan lagret till leverantörer med en artikelnummernyckel eller leverantörer till lager med en leverantörskodnyckel.

Den andra normalformen

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

Poster ska inte vara beroende av något annat än primärnyckeln för en tabell (en sammansatt nyckel, om så behövs). Tänk till exempel på en kunds adress i ett redovisningssystem. Adressen krävs i tabellen Kunder, men även av tabellerna Order, 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 kan du lagra den på ett ställe, antingen i tabellen Kunder eller i en separat Adresstabell.

Den tredje normalformen

  • Ta bort fält som inte är beroende av nyckeln.

Värden i en post som inte ingår i den postens nyckel hör inte hemma i tabellen. När innehållet i en grupp med fält kan gälla för fler än en post i tabellen kan det generellt sett vara bra att placera dessa fält i en separat tabell.

En kandidats universitetsnamn och adress kan till exempel inkluderas i tabellen Rekrytering av anställda. Men du behöver en fullständig lista över universitet för grupputskick. Om universitetsinformation lagras i tabellen Kandidater finns det inget sätt att lista universitet med inga aktuella kandidater. Skapa en separat Universitetstabell och länka den till tabellen Kandidater med en kodnyckel för universitet.

Undantag: det är inte alltid praktiskt att följa den tredje normalformen, även om det är teoretiskt bra. Om du har tabellen Kunder och du vill ta bort alla möjliga beroenden mellan olika platser, måste du skapa separata tabeller för städer, postnummer, säljrepresentanter, kundklasser och alla andra faktorer som kan dupliceras i flera poster. Teoretiskt sett är normalisering värt att sträva efter. Många små tabeller kan emellertid försämra prestanda eller överskrida kapaciteterna för öppen fil och minne.

Det kan vara mer praktiskt att bara tillämpa den tredje normalformen på data som ändras ofta. Om vissa beroende fält finns kvar designar du programmet så att användaren måste verifiera alla relaterade fält när något ändras.

Andra normaliseringsformer

Den fjärde normalformen, som även kallas Boyce Codd Normal Form (BCNF), och den femte normalformen finns, men beaktas sällan i praktisk design. Att ignorera dessa regler kan resultera i mindre än perfekt databasdesign, men bör inte påverka funktionaliteten.

Normalisera en exempeltabell

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

  1. Icke-normaliserad tabell:

    Elev # Rådgivare Rådgivningsrum 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 normalformen: inga upprepade grupper

    Tabeller bör bara ha två dimensioner. Eftersom en elev har flera klasser ska de här klasserna anges i en separat tabell. Fälten Klass 1, Klass 2 och Klass 3 i posterna ovan är indikationer 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. Lägg inte sidan En och sidan Många i samma tabell. Skapa i stället en annan tabell i den första normalformen genom att ta bort den upprepade gruppen (Klass #), som visas nedan:

    Elev # Rådgivare Rådgivningsrum 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. Den andra normalformen: eliminera redundanta data

    Notera de multipla Klass #-värdena för varje Student #-värde i tabellen ovan. Klass # är inte funktionellt beroende av Student # (primärnyckel), vilket innebär att relationen inte är i den andra normalformen.

    Följande tabeller visar den andra normalformen:

    Studenter:

    Elev # Rådgivare Rådgivningsrum
    1022 Jones 412
    4123 Smith 216

    Registrering:

    Elev # Klass #
    1022 101-07
    1022 143-01
    1022 159-02
    4123 101-07
    4123 143-01
    4123 179-04
  4. Tredje normalformen: eliminera data som inte är beroende av nyckeln

    I det sista exemplet är Rådgivningsrummet (rådgivarens kontorsnummer) funktionellt beroende av attributet Rådgivare. Lösningen är att flytta attributet från tabellen Studenter till tabellen Fakultet, enligt nedan:

    Studenter:

    Elev # Rådgivare
    1022 Jones
    4123 Smith

    Fakultet:

    Namn Rum Avdelning
    Jones 412 42
    Smith 216 42