Beskrivelse av grunnleggende informasjon om normalisering av databaser

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:

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ådgiver	Råd-rom	Klasse1	Klasse2	Klasse3
   1022	Jones	412	101-07	143-01	159-02
   4123	Smith	216	201-01	211-02	214-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ådgiver	Råd-rom	Klassenr
   1022	Jones	412	101-07
   1022	Jones	412	143-01
   1022	Jones	412	159-02
   4123	Smith	216	201-01
   4123	Smith	216	211-02
   4123	Smith	216	214-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ådgiver	Råd-rom
   1022	Jones	412
   4123	Smith	216

   
   
   Registrering:
   
   
   Skjul denne tabellenVis denne tabellen

   Studentnr.	Klassenr
   1022	101-07
   1022	143-01
   1022	159-02
   4123	201-01
   4123	211-02
   4123	214-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
   1022	Jones
   4123	Smith

   
   
   Fakultet:
   
   
   Skjul denne tabellenVis denne tabellen

   Navn	Rom	Avd
   Jones	412	42
   Smith	216	42