Introduksjon til database normalisering

Database normalization er en prosess som brukes til å organisere en database i tabeller og kolonner. Hovedideen med dette er at en tabell skal handle om et bestemt emne og bare støtteemner inkludert. Ta et regneark som inneholder informasjonen som et eksempel, der dataene inneholder selgere og kunder som har flere formål:

• Identifiser selgere i organisasjonen din
• Liste over alle kundene bedriften din ber om å selge et produkt
• Identifiser hvilke selgere som ringer til bestemte kunder.

Ved å begrense en tabell til ett formål reduserer du antallet duplikatdata som finnes i databasen din. Dette eliminerer noen problemer som skyldes databasemodifikasjoner.

For å nå disse målene bruker vi noen etablerte regler. Når du bruker disse reglene, dannes det nye tabeller. Progresjonen fra urolig til optimalisert går gjennom flere normale former.

Det er tre normale former de fleste databaser holder seg til å bruke. Ettersom tabeller tilfredsstiller hvert påfølgende databasens normaliseringsskjema, blir de mindre utsatt for endringer i databasemodifikasjoner og mer fokusert mot et eneste formål eller emne. Før du går videre, må du være sikker på at du forstår definisjonen av en databasetabell.

Årsaker til databasens normalisering

Det er tre hovedårsaker til å normalisere en database. Den første er å minimere dupliserte data, den andre er å minimere eller unngå dataendringsproblemer, og den tredje er å forenkle spørsmål.

Når vi går gjennom de forskjellige tilstandene til normalisering, vil vi diskutere hvordan hvert skjema adresserer disse problemene, men for å starte, la oss se på noen data som ikke er normalisert, og diskutere noen potensielle fallgruver.

Jeg tror at når du forstår problemene, setter du bedre pris på normalisering. Tenk på følgende tabell:

Det første du må legge merke til er at denne tabellen tjener mange formål, inkludert:

1. Identifisering av organisasjonens selgere
2. Oppføring av salg kontorer og telefonnumre
3. Tilknytte en selger til et salgskontor
4. Viser hver selgers kunder

Som en DBA hever dette et rødt flagg. Generelt liker jeg å se tabeller som har ett formål. Å ha bordet tjener mange formål introduserer mange av utfordringene; nemlig data duplisering, dataoppdateringsproblemer og økt innsats for å spørre data.

Data duplisering og modifikasjonsavvik

Legg merke til at for hver SalesPerson har vi listet opp både SalesOffice og OfficeNumber. Det er dupliserte selgerdata. Duplisert informasjon gir to problemer:

1. Det øker lagring og reduserer ytelsen.
2. Det blir vanskeligere å opprettholde dataendringene.

For eksempel:

Tenk om vi flytter Chicago-kontoret til Evanston, IL. For å gjenspeile dette riktig i tabellen vår, må vi oppdatere oppføringene for alle SalesPersons som er i Chicago. Tabellen vår er et lite eksempel, men du kan se om det var større, at dette potensielt kan innebære hundrevis av oppdateringer.

Disse situasjonene er modifiseringsavvik. Databasens normalisering løser dem. Det er tre endringsavvik som kan oppstå:

Sett inn anomali

Det er fakta vi ikke kan registrere før vi vet informasjon for hele raden. I vårt eksempel kan vi ikke spille inn et nytt salgskontor før vi også kjenner selgeren. Hvorfor? For for å opprette posten, trenger vi å oppgi en primærnøkkel. I vårt tilfelle er dette EmployeeID.

Oppdater anomali

I dette tilfellet har vi den samme informasjonen i flere rader. For eksempel hvis kontornummeret endres, er det flere oppdateringer som må gjøres. Hvis vi ikke oppdaterer alle radene, vises inkonsekvenser.

Slettingsavvik

Sletting av en rad fører til at mer enn ett sett med fakta fjernes. For eksempel, hvis John Hunt går av med pensjon, kan det føre til at vi mister informasjon om New York-kontoret når vi sletter den raden.

Søke- og sorteringsproblemer

Den siste grunnen til at vi vil vurdere er å gjøre det lettere å søke etter og sortere dataene dine. Hvis du vil søke etter en bestemt kunde som Ford, i SalesStaff-tabellen, må du skrive et spørsmål som

SELECT SalesOfficeFROM SalesStaffWHERE Customer1 = ‘Ford’ OR Customer2 = ‘Ford’ OR Customer3 = ‘Ford’

Klart hvis kunden på en eller annen måte var i en kolonne ville spørsmålet vårt være enklere. Vurder også om du vil kjøre et spørsmål og sortere etter kunde.

Vår nåværende tabell gjør dette tøft. Du må bruke tre separate UNION-spørsmål!Du kan eliminere eller redusere disse avvikene ved å skille dataene i forskjellige tabeller. Dette setter dataene i tabeller som tjener et enkelt formål.

Prosessen for å redesigne tabellen er databasens normalisering.

Definisjon av database normalisering

Det er tre vanlige former for database normalisering: 1., 2. og 3. normal form. De er også forkortet henholdsvis 1NF, 2NF og 3NF.

Det finnes flere tilleggsformer, for eksempel BCNF, men jeg anser de som avanserte, og ikke for nødvendige å lære i begynnelsen.

Skjemaene er progressive, noe som betyr at for å kvalifisere for 3. normalform må en tabell først tilfredsstille reglene for 2. normalform, og 2. normalform må følge de for 1. normalform. Før vi diskuterer de forskjellige formene og reglene i detalj, la oss oppsummere de ulike formene:

• Første normale form – Informasjonen lagres i en relasjonstabell med hver kolonne som inneholder atomverdier. Det er ingen gjentatte kolonnegrupper.
• Andre normalform – Tabellen er i første normale form, og alle kolonnene avhenger av tabellens primære nøkkel.
• Tredje normalform – tabellen er i andre normalform, og alle kolonnene er ikke avhengig av hovednøkkelen

Hvis reglene ikke gir for mye mening, ikke bekymre deg. Jeg har lenket til artikkelen for å hjelpe deg med å forstå dem.

Foreløpig er det viktig å forstå at det er tre regler for normalisering av databaser som gjelder hverandre. Noen mennesker gjør at databasenormalisering virker komplisert.

men det trenger ikke å være, og når du først forstår det, blir det intuitivt.