Beskrivelse af grundprincipperne i databasenormalisering

Oversættelser af artikler Oversættelser af artikler
Artikel-id: 283878 - Få vist de produkter, som denne artikel refererer til.
Begyndere: Kræver kendskab til brugergrænsefladen på computere med kun en bruger.

Du kan finde en Microsoft Access 2000-version af denne artikel under 209534. . Artiklen er evt. på engelsk.
Du kan finde en Microsoft Access 95- eller Microsoft Access 97-version af denne artikel under 100139. . Artiklen er evt. på engelsk.
Udvid alle | Skjul alle

På denne side

Sammenfatning

I denne artikel forklares terminologien om databasenormalisering for begyndere. En grundlæggende forståelse af denne terminologi er nyttig i forbindelse med redegørelser for, hvordan en relationel database skal designes.

BEMÆRK! Microsoft tilbyder også en webudgivelse, der gør rede for grundprincipperne i databasenormalisering. Hvis du vil se denne webudgivelse, skal du besøge følgende Microsoft-websted:
http://support.microsoft.com/?fr=1&ln=da

Yderligere Information

Beskrivelse af normalisering

Normalisering er den proces, der organiserer data i en database. Dette omfatter oprettelse af tabeller og etablering af relationer mellem disse tabeller i henhold til et sæt af regler. Reglerne er udviklet til både at beskytte data og gøre databasen mere fleksibel ved at fjerne overflødige data og inkonsistent afhængighed.

Overflødige data spilder diskplads og forårsager vedligeholdelsesproblemer. Hvis de data, der findes mere end ét sted, skal ændres, skal de ændres på præcist den samme måde alle steder. En ændring af en kundeadresse er langt nemmere at implementere, hvis dataene kun er gemt i kundetabellen og ingen andre steder i databasen.

Hvad er "inkonsistent afhængighed"? Det er mest nærliggende for en bruger at søge efter en bestemt kundes adresse i kundetabellen, men det giver til gengæld ingen mening at søge i samme tabel efter lønnen til den medarbejder, der har med den pågældende kunde at gøre. Medarbejderens løn er relateret til eller afhængig af medarbejderen og skal således flyttes til tabellen over medarbejdere. Inkonsistente afhængigheder kan gøre det besværligt at få adgang til data, da stien til den pågældende data muligvis mangler eller er brudt.

Der gælder nogle få regler for databasenormalisering. Hver regel kaldes en "normalform". Hvis den første regel er fulgt, er databasen i "første normalform". Hvis de første tre regler er fulgt, er databasen i "tredje normalform". Selvom der findes andre niveauer af normalisering, anses den tredje normalform for at være det højeste niveau til de fleste anvendelser.

Ligesom det er tilfældet med mange formelle regler og specifikationer, er der ikke altid perfekt kompatibilitet med virkelighedens scenarier. Normalisering kræver generelt flere tabeller, og nogle kunder finder dette besværligt. Hvis du bestemmer dig for at bryde en af de tre første regler for normalisering, skal du sikre dig, at dit program tager højde for eventuelle problemer, f.eks. med overflødige data og inkonsistente afhængigheder.

Følgende beskrivelser giver eksempler på dette.

Første normalform

  • Fjern gentagende grupper i individuelle tabeller.
  • Opret en særskilt tabel for hvert sæt af relateret data.
  • Identificer hvert sæt af relateret data med en primærnøgle.
Brug ikke flere felter i en enkelt tabel til at gemme data, der ligner hinanden. Hvis du f.eks. vil finde en vare, der kan komme fra to mulige kilder, kan en varepost indeholde felter til leverandørkode 1 og leverandørkode 2.

Hvad sker der, hvis du tilføjer en tredje leverandør? Løsningen er ikke at tilføje endnu et felt. Der kræves program- og tabelændringer, og det er ikke muligt nemt at tilpasse databasen til et dynamisk antal leverandører. Du skal i stedet placere alle leverandøroplysninger i en særskilt tabel med navnet Leverandør og derefter kæde varer til leverandører med en varenummernøgle eller leverandører til varer med en leverandørkodenøgle.

Anden normalform

  • Opret særskilte tabeller til værdisæt, som kan anvendes til flere poster.
  • Relater disse med en fremmednøgle.
Poster skal ikke afhænge af andet end tabellens primærnøgle (evt. en sammensat nøgle). Tag f.eks. en kundes adresse i et regnskabssystem. Adressen er relevant i kundetabellen, men også i tabellerne over ordrer, levering, fakturaer, udeståender og opkrævninger. I stedet for at gemme kundens adresse i en særskilt post i hver af disse tabeller, skal du gemme den ét sted, enten i kundetabellen eller i en særskilt adressetabel.

Tredje normalform

  • Fjern de felter, der ikke afhænger af nøglen.
Værdier i en post, som ikke er en del af den pågældendes posts nøgle, hører ikke til i tabellen. Når indholdet i en gruppe af felter gælder for mere end én enkelt post i en tabel, skal du generelt set overveje at placere disse felter i en særskilt tabel.

I en tabel over ansøgere kan navnet på en kandidats uddannelsesinstitution samt adresse inkluderes. Men du har brug for en komplet liste over uddannelsesinstitutioner til masseforsendelser. Hvis oplysningerne om uddannelsesinstitutionen er gemt i tabellen over kandidater, er det ikke muligt at inkludere uddannelsesinstitutioner, hvor der i øjeblikket ingen kandidater er. Opret en særskilt tabel over uddannelsesinstitutioner, og kæd den sammen med en kodenøgle til uddannelsesinstitutioner.

UNDTAGELSE: Teoretisk set er det at foretrække at holde sig til den tredje normalform, men det ikke altid praktisk muligt. Hvis du har en kundetabel, og du vil fjerne alle mulige tværgående afhængigheder, skal du oprette særskilte tabeller for byer, postnumre, sælgere, kundeklasser og andre kategorier, der kan optræde i flere poster. Teoretisk set er normalisering værd at gå efter. Men mange små tabeller kan forringe ydeevnen eller overskride hukommelseskapaciteterne og muligheden for at åbne filer.

Det er sandsynligvis mere praktisk anvendeligt kun at bruge den tredje normalform i forbindelse med data, der ofte ændres. Hvis der stadig er nogle afhængighedsfelter, skal du designe dit program, så det får brugeren til at bekræfte alle relaterede felter, når nogle af disse ændres.

Andre normaliseringsformer

Der findes en fjerde normaliseringsform, som også kaldes BCNF (Codd Normal Form), og en femte normaliseringsform, men de bruges sjældent i forbindelse med praktisk databasedesign. Hvis du ignorerer disse regler, kan det resultere i et databasedesign, der ikke er helt perfekt, men det skulle ikke påvirke funktionaliteten.

Normalisering af en eksempeltabel

I nedenstående trin vises normaliseringsprocessen i en fiktiv tabel over studerende.
  1. Unormaliseret tabel:

    Skjul tabellenUdvid tabellen
    Studerende#RådgiverRådgiverrumKlasse1Klasse2Klasse3
    1022Jensen412101-07143-01159-02
    4123Sørensen216201-01211-02214-01
  2. Første normalform: Ingen gentagende grupper

    Tabeller skal kun være todimensionelle. Da én studerende har flere klasser, skal disse klasser opstilles i særskilte tabeller. Felterne Klasse1, Klasse2 og Klasse3 i ovenstående poster angiver, at der er designproblemer.

    Regneark bruges ofte tredimensionelt, men det skal tabeller ikke. En anden måde at anskue dette problem på er med en en-til-mange-relation. Placer ikke en-siden og mange-siden i den samme tabel. Opret i stedet for en anden tabel i første normalform ved at fjerne den gentagende gruppe (Klasse#), som vist nedenfor:

    Skjul tabellenUdvid tabellen
    Studerende#RådgiverRådgiverrumKlasse#
    1022Jensen412101-07
    1022Jensen412143-01
    1022Jensen412159-02
    4123Sørensen216201-01
    4123Sørensen216211-02
    4123Sørensen216214-01
  3. Anden normalform: Fjern overflødige data

    Bemærk de mange Klasse#-værdier for hver Studerende#-værdi i ovenstående tabel. Klasse# er ikke funktionelt afhængig af Studerende# (primærnøgle), så denne relation er ikke med i den anden normalform.

    Følgende to tabeller demonstrerer anden normalform:

    Studerende:

    Skjul tabellenUdvid tabellen
    Studerende#RådgiverRådgiverrum
    1022Jensen412
    4123Sørensen216


    Registrering:

    Skjul tabellenUdvid tabellen
    Studerende#Klasse#
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-01
  4. Tredje normalform: Fjern data, som ikke er afhængig af nøgle

    I det sidste eksempel er Rådgiverrum (rådgiverens kontortelefonnummer) funktionelt afhængig af rådgiver-attributten. Løsningen er at flytte den pågældende attribut fra tabellen over studerende til fakultetstabellen, som vist nedenfor:

    Studerende:

    Skjul tabellenUdvid tabellen
    Studerende#Rådgiver
    1022Jensen
    4123Sørensen


    Fakultet:

    Skjul tabellenUdvid tabellen
    NavnRumInstitut
    Jensen41242
    Sørensen21642
Bemærk! Dette er en artikel til hurtig udgivelse, som er oprettet direkte i Microsofts supportafdeling. Oplysningerne i artiklen præsenteres som de og behandler aktuelle problemer. Fordi artiklen er blevet udgivet hurtigt, kan der forekomme slåfejl, og artiklen kan blive redigeret uden varsel. Se andre forbehold under Vilkår for anvendelse.

Egenskaber

Artikel-id: 283878 - Seneste redigering: 31. januar 2014 - Redigering: 1.0
Oplysningerne i denne artikel gælder:
  • Microsoft Office Access 2007
  • Microsoft Office Access 2003
  • Microsoft Access 2002 Standard Edition
Nøgleord: 
kbinfo kbdesign kbdatabase kbhowto KB283878

Send 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