Beskrivelse av grunnleggende informasjon om normalisering av databaser

Artikkeloversettelser Artikkeloversettelser
Artikkel-ID: 283878 - Vis produkter som denne artikkelen gjelder for.
Nybegynner: Krever kunnskap om brukergrensesnittet på enbrukermaskiner.

Hvis du vil ha en Microsoft Access 2000-versjon av denne artikkelen, kan du se 209534 (denne artikkelen kan være på engelsk).
Hvis du vil ha en Microsoft Access 95- eller Microsoft Access 97-versjon av denne artikkelen, kan du se 100139 (denne artikkelen kan være på engelsk).
Vis alt | Skjul alt

På denne siden

Sammendrag

Denne artikkelen forklarer databasenormaliseringstermer for nybegynnere. Det er nyttig å ha en grunnleggende forståelse av terminologien når vi diskuterer utformingen til en relasjonsdatabase.

Obs!  Microsoft har også en webkasting som tar for seg grunnleggende informasjon om databasenormalisering. Du finner denne webkastingen ved å gå til følgende Microsoft-webområde:
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1

Mer informasjon

Beskrivelse av normalisering

Normalisering er en prosess som organiserer data i en database. Dette omfatter å opprette tabeller og etablere forhold mellom disse tabellene i henhold til regler som skal beskytte dataene og gjøre databasen mer fleksibel ved å eliminere redundans og inkonsekvent avhengighet.

Overflødig data bruker diskplass og skaper vedlikeholdsproblemer. Hvis du må endre data som finnes på mer enn ett sted, må dataene endres på nøyaktig samme vis på alle stedene. Det er enklere å endre en kundeadresse hvis dataene bare er lagret i Kunder-tabellen og ikke andre steder i databasen.

Hva er inkonsekvent avhengighet? Det er logisk for en bruker å lete etter en kundeadresse i Kunder-tabellen, men det er ikke like logisk å lete etter lønnen til den ansatte som behandler kunden, der. Lønnen til den ansatte er knyttet til, eller avhengig av, den ansatte, og bør derfor flyttes til Ansatte-tabellen. Inkonsekvente avhengigheter kan gjøre det vanskelig å finne data, fordi banen til dataene kan mangle eller være brutt.

Det finnes et par regler for databasenormalisering. Hver regel kalles en normal form. Hvis den første regelen overholdes, er databasen i såkalt første normale form. Hvis de tre første reglene overholdes, er databasen i tredje normale form. Det er mulig å ha flere normaliseringsnivå, men tredje normale form anses som det høyeste nødvendige nivået for de fleste programmer.

Det er ikke alltid mulig å ha perfekt kompatibilitet i ordentlige scenarier, til tross for formelle regler og spesifikasjoner. Normalisering krever vanligvis ekstra tabeller, og noen kunder synes at det er tungvint. Hvis du bestemmer deg for å bryte en av de tre første normaliseringsreglene, må du sørge for at programmet er klar over eventuelle problemer som kan oppstå, som for eksempel overflødig data og inkonsekvente avhengigheter.

Følgende beskrivelser har eksempler.

Første normale form

  • Fjern gjentakende grupper i individuelle tabeller.
  • Opprett en separat tabell for hvert sett tilknyttet data.
  • Identifiser hvert sett tilknyttet data med en primærnøkkel.
Ikke bruk flere felter i en enkel tabell for å lagre lignende data. Hvis du for eksempel skal spore en lagervare som kan komme fra to mulig kilder, kan en lagerpost inneholde felt for leverandørkode 1 og leverandørkode 2.

Hva skjer når du legger til en tredje leverandør? Løsningen er ikke å legge til et felt, for det krever endring av program og tabell, og gjør det ikke enkelt å tilpasse et dynamisk antall leverandører. I stedet for bør du plassere all leverandørinformasjon i en separat tabell kalt Leverandører, og koble lager til leverandører med et varenummernøkkel eller leverandører til lager med en leverandørkodenøkkel.

Andre normale form

  • Opprett separate tabeller for verdisett som gjelder flere poster.
  • Knytt disse tabellene sammen med en sekundærnøkkel.
Postene bør ikke være avhengig av noe annet enn tabellens primærnøkkel (en sammensatt nøkkel). Ta for eksempel en kundeadresse i et regnskapssystem. Adressen er nødvendig i Kunde-tabellen, men også i tabellene Ordrer, Forsendelser, Fakturaer, Regnskap og Samlinger. I stedet for å lagre kundeadressen som en separat post i alle disse tabellene, kan du lagre den på én plass ? enten i Kunder-tabellen eller i en separat Adresser-tabell.

Tredje normale form

  • Fjern felt som ikke er avhengig av nøkkelen.
Verdier i en post som ikke er del av postens nøkkel, hører ikke hjemme i tabellen. Hver gang innholdet i en gruppe felter gjelder for mer enn én enkel post i tabellen, bør du generelt sett plassere disse feltene i en separat tabell.

I en rekrutteringstabell finner du for eksempel kandidatens universitetsnavn og adresse. Men du trenger en komplett liste over universiteter for gruppemeldinger. Hvis universitetsinformasjonen er lagret i Kandidat-tabellen, er det umulig å lage en liste over universiteter uten gjeldende kandidater. Opprett en separat Universiteter-tabell, og koble den til Kandidater-tabellen med en universitetskodenøkkel.

UNNTAK: Selv om det er bra i teorien, er det ikke alltid praktisk å følge den tredje normale formen. Hvis du har en Kunder-tabell og vil fjerne alle mulige avhengigheter mellom felter, må du opprette separate tabeller for byer, postnummer, salgsrepresentanter, kundeklasser og alle andre faktorer som kan dupliseres i flere poster. I teorien er det verdt å bruke normalisering. Mange små tabeller kan imidlertid forverre ytelsen eller overstige kapasiteten for åpne filer og minne.

Det kan være mer praktisk å bare bruke tredje normale form på data som endres ofte. Hvis det fremdeles finnes avhengige felter, kan du sørge for at programmet ber brukeren om å verifisere alle tilknyttede felter når ett felt endres.

Andre normaliserende former

Det finnes en fjerde normale form, også kalt BCNF (Boyce Codd Normal Form), og en femte normale form, men de blir sjelden brukt i praksis. Hvis du ser bort fra disse reglene, kan det føre til en mindre perfekt databaseutforming, men det bør ikke påvirke funksjonaliteten.

Normalisere en eksempeltabell

Denne fremgangsmåten viser prosessen med å normalisere en oppdiktet studenttabell.
  1. Ikke-normalisert tabell:

    Skjul denne tabellenVis denne tabellen
    Studentnr.RådgiverRåd-romKlasse1Klasse2Klasse3
    1022Jones412101-07143-01159-02
    4123Smith216201-01211-02214-01
  2. Første normale form: Ingen gjentagende grupper

    Tabellene bør bare har to dimensjoner. Ettersom en student har flere klasser, bør disse timene oppføres i en separat tabell. Feltene Klasse1, Klasse2 og Klasse 3 i postene ovenfor er tegn på utformingsproblemer.

    Regneark bruker ofte den tredje dimensjonen, men det bør ikke tabeller. Du kan også se på dette problemet som et en-til-mange forhold. Ikke ha den en siden og mange siden i samme tabell. I stedet for kan du opprette en annen tabell i første normale form ved å fjerne den gjentagende gruppen (klassenr), som vis nedenfor:

    Skjul denne tabellenVis denne tabellen
    Studentnr.RådgiverRåd-romKlassenr
    1022Jones412101-07
    1022Jones412143-01
    1022Jones412159-02
    4123Smith216201-01
    4123Smith216211-02
    4123Smith216214-01
  3. Andre normale form: Fjern øverflødig data

    Merk alle verdiene for klassenr. for hver verdi for studentnr. i tabellen ovenfor. Klassenr. er ikke funksjonelt avhengig av Studentnr. (primærnøkkel), så dette forholdet er ikke i andre formale form.

    Følgende to tabeller viser andre normale form:

    Studenter:

    Skjul denne tabellenVis denne tabellen
    Studentnr.RådgiverRåd-rom
    1022Jones412
    4123Smith216


    Registrering:

    Skjul denne tabellenVis denne tabellen
    Studentnr.Klassenr
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-01
  4. Tredje normale form: Fjern data som ikke er avhengig av nøkkel

    I det siste eksemplet er Råd-rom (rådgiverens kontornummer) funksjonelt avhengig av Rådgiver-attributtet. Løsningen er å flytte attributtet fra Studenter-tabellen til Fakultet-tabellen, som vist nedenfor:

    Studenter:

    Skjul denne tabellenVis denne tabellen
    Studentnr.Rådgiver
    1022Jones
    4123Smith


    Fakultet:

    Skjul denne tabellenVis denne tabellen
    NavnRomAvd
    Jones41242
    Smith21642

Egenskaper

Artikkel-ID: 283878 - Forrige gjennomgang: 8. februar 2008 - Gjennomgang: 6.4
Informasjonen i denne artikkelen gjelder:
  • Microsoft Office Access 2007
  • Microsoft Office Access 2003
  • Microsoft Access 2002 Standard Edition
Nøkkelord: 
kbinfo kbdesign kbdatabase kbhowto KB283878

Gi tilbakemelding

 

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