Du er frakoblet, venter på at Internett skal koble til igjen

Beskrivelse av grunnleggende informasjon om normalisering av databaser

Kundestøtte for Office 2003 er avsluttet

Microsoft avsluttet kundestøtte for Office 2003 den 8. april 2014. Denne endringen har påvirket programvareoppdateringene og sikkerhetsalternativene dine. Finn ut hvordan dette påvirker deg og hvordan du forblir beskyttet.

Nybegynner: Krever kunnskap om brukergrensesnittet på enbruker- maskiner.

Hvis du vil ha en Microsoft Access 2000-versjon av denne artikkelen, kan du se 209534.
Hvis du vil ha en Microsoft Access 95- eller Microsoft Access 97-versjon av denne artikkelen, kan du se 100139.
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:
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. En kundeadresseendring er mye enklere å implementere 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 første tre 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.

Til tross for mange formelle regler og spesifikasjoner, er det ikke alltid mulig å ha perfekt kompatibilitet i ordentlige scenarier. 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ødige 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 mulige 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. Du bør i stedet plassere all leverandørinformasjon i en separat tabell kalt Leverandører, og koble lager til leverandører med en 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, hvis nødvendig). 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 tabell for rekruttering av ansatte 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:

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

    Tabeller bør bare ha to dimensjoner. Ettersom en student har flere klasser, bør disse timene oppføres i en separat tabell. Feltene Klasse1, Klasse2 og Klasse3 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 ene 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 vist nedenfor:

    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 normale form.

    Følgende to tabeller viser andre normale form:

    Studenter:

    Studentnr.RådgiverRåd-rom
    1022Jones412
    4123Smith216


    Registrering:

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

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

    Studenter:

    Studentnr.Rådgiver
    1022Jones
    4123Smith


    Fakultet:

    NavnRomAvd
    Jones41242
    Smith21642
BCNF relational normal model normalize ACC2002 ACC2003
Obs! Dette er en "FAST PUBLISH"-artikkel som er opprettet direkte innenfor Microsofts kundestøtteorganisasjon. Informasjonen her leveres "som den er" som svar på problemer som kan oppstå. Som et resultat av den korte tiden det tar å gjøre materialet tilgjengelig, kan det inneholde skrivefeil, og det kan når som helst og uten forvarsel bli revidert. Se Vilkår for bruk for mer informasjon.
Egenskaper

Artikkel-ID: 283878 – Forrige gjennomgang: 12/29/2014 13:46:00 – Revisjon: 1.0

Microsoft Office Access 2007, Microsoft Office Access 2003, Microsoft Access 2002 Standard Edition

  • kbinfo kbdesign kbdatabase kbhowto KB283878
Tilbakemelding
">>