Beskrivelse av grunnleggende om databasenormalisering
Denne artikkelen forklarer terminologien for databasenormalisering for nybegynnere. En grunnleggende forståelse av denne terminologien er nyttig når du diskuterer utformingen av en relasjonsdatabase.
Beskrivelse av normalisering
Normalisering er prosessen med å organisere data i en database. Det inkluderer å opprette tabeller og etablere relasjoner mellom disse tabellene i henhold til regler som er utformet både for å beskytte dataene og gjøre databasen mer fleksibel ved å eliminere redundans og inkonsekvent avhengighet.
Overflødige data sløser med diskplass og skaper vedlikeholdsproblemer. Hvis data som finnes på mer enn ett sted må endres, må dataene endres på nøyaktig samme måte på alle plasseringene. En kundeadresseendring er enklere å implementere hvis disse dataene bare lagres i Kunder-tabellen og ingen andre steder i databasen.
Hva er en «inkonsekvent avhengighet»? Selv om det er intuitivt for en bruker å se i Kunder-tabellen etter adressen til en bestemt kunde, er det kanskje ikke fornuftig å se etter lønnen til den ansatte som ringer til kunden. Den ansattes lønn er relatert til, eller avhengig av, den ansatte, og bør derfor flyttes til medarbeidertabellen. Inkonsekvente avhengigheter kan gjøre det vanskelig å få tilgang til data, siden banen for å finne dataene kan mangle eller være brutt.
Det finnes noen regler for databasenormalisering. Hver regel kalles et «normalt skjema». Hvis den første regelen observeres, sies databasen å være i «første normale form». Hvis de tre første reglene blir observert, anses databasen å være i «tredje normale form». Selv om andre nivåer av normalisering er mulig, regnes tredje normalform som det høyeste nivået som er nødvendig for de fleste programmer.
Som med mange formelle regler og spesifikasjoner tillater ikke scenarioer i den virkelige verden alltid perfekt overholdelse. Normalisering krever vanligvis flere tabeller, og noen kunder synes dette er tungvint. Hvis du bestemmer deg for å bryte en av de tre første normaliseringsreglene, må du kontrollere at programmet forventer eventuelle problemer som kan oppstå, for eksempel overflødige data og inkonsekvente avhengigheter.
Følgende beskrivelser inkluderer eksempler.
Første normale form
- Fjern gjentatte grupper i individuelle tabeller.
- Opprett en egen tabell for hvert sett med relaterte data.
- Identifiser hvert sett med relaterte data med en primærnøkkel.
Ikke bruk flere felt i én enkelt tabell til å lagre lignende data. Hvis du for eksempel vil spore et lagerelement 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? Å legge til et felt er ikke svaret. den krever endringer i programmer og tabeller og har ikke god plass til et dynamisk antall leverandører. Plasser i stedet all leverandørinformasjon i en egen tabell kalt Leverandører, og koble deretter beholdningen til leverandører med en varenummernøkkel eller leverandører til lager med en leverandørkodenøkkel.
Andre normale form
- Opprett separate tabeller for sett med verdier som gjelder for flere oppføringer.
- Relater disse tabellene med en fremmednøkkel.
Poster bør ikke være avhengige av noe annet enn primærnøkkelen for en tabell (en sammensatt nøkkel, om nødvendig). Vurder for eksempel kundens adresse i et regnskapssystem. Adressen er nødvendig for Kunder-tabellen, men også av ordre-, sending-, faktura-, kundefordring- og inkassotabeller. Fremfor å lagre kundens adresse som en egen oppføring i hver av disse tabellene, må du lagre den på ett sted, enten i kundetabellen eller i en egen adressetabell.
Tredje normale form
- Fjern felt som ikke avhenger av nøkkelen.
Verdier i en post som ikke er en del av denne postens nøkkel, hører ikke hjemme i tabellen. Generelt sett bør du vurdere å plassere disse feltene i en egen tabell når innholdet i en gruppe med felt kan gjelde for mer enn én enkelt post i tabellen.
I en ansattrekrutteringstabell, kan for eksempel en kandidats universitetsnavn og -adresse inkluderes. Men du trenger en fullstendig liste over universiteter for gruppeutsendelser. Hvis universitetsinformasjon er lagret i Kandidater-tabellen, er det ikke mulig å liste universiteter uten aktuelle kandidater. Opprett en egen universitetstabell, og koble den til Kandidater-tabellen med en universitetskodenøkkel.
UNNTAK: Å følge den tredje normale formen, mens teoretisk ønskelig, er ikke alltid praktisk. Hvis du har en kundetabell og vil fjerne alle mulige avhengigheter mellom felter, må du opprette separate tabeller for byer, postnummer, selgere, kundeklasser og andre faktorer som kan dupliseres i flere poster. I teorien er normalisering verdt å forfølge. Mange små tabeller kan imidlertid redusere ytelsen eller overskride åpne fil- og minnekapasiteter.
Det kan være mer gjennomførbart å bruke tredje normale form bare på data som endres ofte. Hvis noen avhengige felt forblir, kan du utforme programmet slik at det krever at brukeren kontrollerer alle relaterte felt når noen av dem endres.
Andre normaliseringsformer
Fjerde normalform, også kalt Boyce-Codd Normal Form (BCNF), og femte normalform finnes, men vurderes sjelden i praktisk utforming. Ignorering av disse reglene kan føre til mindre enn perfekt databaseutforming, men bør ikke påvirke funksjonaliteten.
Normalisere en eksempeltabell
Disse trinnene viser prosessen med å normalisere en fiktiv elevtabell.
Unormalisert tabell:
Student# Rådgiver Råd-rom Klasse1 Klasse2 Klasse3 1022 Jones 412 101-07 143-01 159-02 4123 Smith 216 101-07 143-01 179-04 Første normale form: Ingen gjentatte grupper
Tabeller skal bare ha to dimensjoner. Siden én elev har flere klasser, bør disse klassene være oppført i en egen tabell. Feltene klasse1, klasse2 og klasse3 i postene ovenfor er indikasjoner på utformingsproblemer.
Regneark bruker ofte den tredje dimensjonen, men tabeller bør ikke gjøre det. En annen måte å se på dette problemet på er med en én-til-mange-relasjon, ikke plasser den ene siden og de mange sidene i samme tabell. Opprett i stedet en ny tabell i første normale form ved å eliminere den gjentatte gruppen (klasse#), som vist i eksemplet nedenfor:
Student# Rådgiver Råd-rom Klasse# 1022 Jones 412 101-07 1022 Jones 412 143-01 1022 Jones 412 159-02 4123 Smith 216 101-07 4123 Smith 216 143-01 4123 Smith 216 179-04 Andre normale form: Eliminere overflødige data
Legg merke til flere klasse# -verdier for hver Student#- verdi i tabellen ovenfor. Klasse# er ikke funksjonelt avhengig av Student# (primærnøkkel), så denne relasjonen er ikke i andre normale form.
Tabellene nedenfor viser den andre normale formen:
Studenter:
Student# Rådgiver Råd-rom 1022 Jones 412 4123 Smith 216 Registrering:
Student# Klasse# 1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04 Tredje normale form: Fjern data som ikke er avhengige av nøkkelen
I det siste eksemplet råd-rom (rådgiverens kontornummer) funksjonelt avhengig av rådgiver-attributtet. Løsningen er å flytte dette attributtet fra studenter-tabellen til fakultet-tabellen, som vist nedenfor:
Studenter:
Student# Rådgiver 1022 Jones 4123 Smith Fakultet:
Navn Rom Avd Jones 412 42 Smith 216 42
Tilbakemeldinger
Kommer snart: Gjennom 2024 faser vi ut GitHub Issues som tilbakemeldingsmekanisme for innhold, og erstatter det med et nytt system for tilbakemeldinger. Hvis du vil ha mer informasjon, kan du se: https://aka.ms/ContentUserFeedback.
Send inn og vis tilbakemelding for