Artikel-id: 283878 - Visa produkter som artikeln gäller.
Nybörjare: Kräver kunskaper om användargränssnittet på datorer för en användare.

En version av den här artikeln för Microsoft Access 2000 finns i 209534 (Länken kan leda till en webbplats som är helt eller delvis på engelska).
En version av den här artikeln för Microsoft Access 95 eller 97 finns i 100139 (Länken kan leda till en webbplats som är helt eller delvis på engelska).
Visa alla | Dölj alla

På den här sidan

Sammanfattning

I den här artikeln förklaras terminologi för databasnormalisering för nybörjare. En grundläggande förståelse av denna terminologi är användbar för att förstå design av relationsdatabaser.

Obs! Microsoft erbjuder även en webbutsändning om grunderna i databasnormalisering på följande Microsoft-webbplats:
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1

Mer Information

Beskrivning av normalisering

Normalisering är processen att ordna data i en databas. Här ingår att skapa tabeller och upprätta relationer mellan dessa tabeller enligt regler som både ska skydda data och göra databasen mer flexibel genom att eliminera redundans och inkonsekventa beroenden.

Redundanta data innebär slöseri med 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. Det är mycket lättare att ändra en kundadress om uppgiften bara är lagrad i tabellen Kunder och inte någon annanstans i databasen.

Vad är ett "inkonsekvent beroende"? Samtidigt som det är naturligt för en användare att leta i tabellen Kunder efter adressen till en viss kund, är det kanske onaturligt att leta där efter lönen för den anställde som ringer upp kunden. Den anställdes lön är relaterad till, eller beroende av, den anställde och bör alltså flyttas till tabellen Anställda. Inkonsekventa beroenden kan göra det svårt att komma åt data, eftersom sökvägen till data kan saknas eller vara avbruten.

Det finns vissa regler för databasnormalisering, och varje regel kallas en "normalform". Om den första regeln följs sägs databasen vara i "den första normalformen". Om de första tre reglerna följs anses databasen vara i "den tredje normalformen". Även om andra normaliseringsnivåer är möjliga, anses den tredje normalformen utgöra den högsta nivå som krävs för de flesta program.

Som många formella regler och specifikationer följer verkliga scenarier inte alltid teorin fullständigt. Normalisering kräver i allmänhet ytterligare tabeller, vilket vissa kunder tycker är opraktiskt. Om du bestämmer dig för att bryta mot någon av de första tre normaliseringsreglerna, måste du i programmet förutse problem som kan uppstå, till exempel i form av redundanta data och inkonsekventa beroenden.

Följande beskrivningar innehåller exempel.

Första normalformen

  • Eliminera återkommande grupper i enskilda tabeller.
  • Skapa en separat tabell för varje uppsättning relaterade data.
  • Identifiera varje uppsättning relaterade data med en primär nyckel.
Använd inte flera fält i en och samma tabell för att lagra liknande data. Om du till exempel vill spåra ett lagerobjekt som kan komma från två olika källor, kan en lagerpost innehålla fält för Leverantörskod 1 och Leverantörskod 2.

Vad händer då när du lägger till en tredje leverantör? Att lägga till ett fält är ingen lösning, eftersom det kräver program- och tabelländringar och inte kan användas på ett smidigt sätt för att hantera ett dynamiskt antal leverantörer. Placera i stället all leverantörsinformation i en separat tabell med beteckningen Leverantörer, och länka sedan lagret till leverantörer med en objektnummernyckel, eller leverantörer till lagret med en leverantörskodnyckel.

Andra normalformen

  • Skapa separata tabeller för uppsättningar av värden som gäller flera poster.
  • Relatera dessa tabeller med en sekundärnyckel.
Poster ska inte vara beroende av något annat än tabellens primärnyckel (en sammansatt nyckel om så krävs). Ta till exempel en kundadress i ett bokföringssystem. Adressen behövs i tabellen Kunder, men även i tabellerna Order, Leverans, Fakturor, Kortfristiga fordringar och Inkasso. I stället för att lagra kundens adress som en separat post i varje tabell lagrar du den på en plats, antingen i tabellen Kunder eller i en separat tabell Adresser.

Tredje normalformen

  • 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. Varje gång innehållet i en grupp fält kan gälla mer än en enstaka post i tabellen, bör du i allmänhet överväga att placera dessa fält i en separat tabell.

I tabellen Nyanställning kan till exempel ingå namn och adress för ett universitet som en sökande har gått på, men du behöver en fullständig lista med universitet för grupputskick. Om information om universitet lagras i tabellen Sökande, går det inte att göra upp en lista över universitet utan aktuella sökande. Skapa i stället en separat tabell Universitet och länka den till tabellen Sökande med en universitetskodnyckel.

UNDANTAG: Även om det är önskvärt i teorin att följa den tredje normalformen är det inte alltid praktiskt. Om du har en tabell Kunder och vill eliminera alla beroenden mellan fält som är möjliga, måste du skapa separata tabeller för städer, postkoder, säljare, kundklasser och alla andra faktorer som kan dubbleras i flera poster. I teorin är det önskvärt att normalisera, men många små tabeller kan medföra att prestanda sjunker eller att kapaciteten för öppna filer eller minne överskrids.

Det kan vara mer praktiskt att bara använda tredje normalformen på data som ändras ofta. Om det finns kvar några beroende fält utformar du programmet så att användaren måste verifiera alla relaterade fält när ett fält ändras.

Andra normaliseringsformer

Det finns visserligen en fjärde normalform, även kallad BCNF (Boyce Codd Normal Form), och en femte, men de används sällan i praktiken. Brott mot dessa regler kan innebära att databasen inte är helt perfekt konstruerad, men bör inte påverka funktionen.

Normalisera en exempeltabell

Nedan visas normalisering av en fiktiv studenttabell.
  1. Onormaliserad tabell:

    Dölj tabellenVisa tabellen
    Student nrVägledareVägledarrumKurs1Kurs2Kurs3
    1022Johansson412101-07143-01159-02
    4123Svensson216201-01211-02214-01
  2. Första normalformen: Inga återkommande grupper

    Tabeller ska bara ha två dimensioner. Eftersom en student går flera kurser bör dessa kurser anges i en separat tabell. Fälten Kurs1, Kurs2 och Kurs3 i ovanstående poster tyder på konstruktionsproblem.

    I kalkylblad används ofta den tredje dimensionen, men det bör inte vara fallet i tabeller. Ett annat sätt att se på problemet är att man vid en en-till-många-relation inte ska placera en-sidan och många-sidan i samma tabell. Skapa i stället en ny tabell i den första normalformen genom att eliminera den återkommande gruppen (Kursnr) så här:

    Dölj tabellenVisa tabellen
    Student nrVägledareVägledarrumKursnr
    1022Johansson412101-07
    1022Johansson412143-01
    1022Johansson412159-02
    4123Svensson216201-01
    4123Svensson216211-02
    4123Svensson216214-01
  3. Andra normalformen: Eliminera redundanta data

    Notera de olika Kursnr-värdena för varje Student nr-värde i ovanstående tabell. Kursnr är inte funktionellt beroende av Student nr (primärnyckel), så denna relation är inte i den andra normalformen.

    Följande två tabeller visar den andra normalformen:

    Studenter:

    Dölj tabellenVisa tabellen
    Student nrVägledareVägledarrum
    1022Johansson412
    4123Svensson216


    Registrering:

    Dölj tabellenVisa tabellen
    Student nrKursnr
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-01
  4. Tredje normalformen: Eliminera data som inte är beroende av nyckeln

    I det sista exemplet är Vägledarrum (vägledarens kontorsnummer) funktionellt beroende av attributet Vägledare. Lösningen är att flytta detta attribut från tabellen Studenter till tabellen Fakultet, på följande vis:

    Studenter:

    Dölj tabellenVisa tabellen
    Student nrVägledare
    1022Johansson
    4123Svensson


    Fakultet:

    Dölj tabellenVisa tabellen
    NamnRumInstitution
    Johansson41242
    Svensson21642

Egenskaper

Artikel-id: 283878 - Senaste granskning: den 8 februari 2008 - Revision: 6.4
Informationen i denna artikel gäller:
  • Microsoft Office Access 2007
  • Microsoft Office Access 2003
  • Microsoft Access 2002 Standard Edition
Nyckelord: 
kbinfo kbdesign kbdatabase kbhowto KB283878

Ge feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com