Database Normalisering Opplæring: 1NF 2NF 3NF BCNF Eksempler

database normalization tutorial

Denne opplæringen vil forklare hva som er databasenormalisering og forskjellige normale former som 1NF 2NF 3NF og BCNF med eksempler på SQL-kode:

Database Normalization er en kjent teknikk som brukes til å designe databaseskjema.

Hovedformålet med å bruke normaliseringsteknikken er å redusere redundansen og avhengigheten av data. Normalisering hjelper oss med å dele store tabeller i flere små tabeller ved å definere et logisk forhold mellom disse tabellene.

Hva du vil lære:

• Hva er database normalisering?
  • Fordeler med DBMS normalisering
  • Ulemper ved normalisering av databaser
  • Typer av normale former
    • # 1) 1NF (første normale skjema)
    • # 2) 2NF (Second Normal Form)
    • # 3) 3NF (tredje normale skjema)
    • # 4) Boyce-Codd Normal Form (3,5 Normal Form)
    • # 5) Fjerde normalform (4 normalform)
    • # 6) Femte normalform (5 normalform)
  • Ofte stilte spørsmål og svar
• Konklusjon
  • Anbefalt lesing

Hva er database normalisering?

Database normalisering eller SQL normalisering hjelper oss med å gruppere relaterte data i en enkelt tabell. Eventuelle attributter eller indirekte relaterte data er plassert i forskjellige tabeller, og disse tabellene er knyttet til et logisk forhold mellom foreldre- og barnetabeller.

I 1970 kom Edgar F. Codd med begrepet normalisering. Han delte en artikkel kalt 'A Relational Model of Data for Large Shared Banks' der han foreslo 'First Normal Form (1NF)'.

Fordeler med DBMS normalisering

Databasens normalisering gir følgende grunnleggende fordeler:

1. Normalisering øker datakonsistensen, da det unngår duplisering av data ved å lagre dataene bare ett sted.
2. Normalisering hjelper til med å gruppere like eller relaterte data under samme skjema, og resulterer i bedre gruppering av data.
3. Normalisering forbedrer søket raskere ettersom indekser kan opprettes raskere. Derfor brukes den normaliserte databasen eller tabellen for OLTP (Online Transaction Processing).

Ulemper ved normalisering av databaser

DBMS Normalisering har følgende ulemper:

1. Vi kan ikke finne tilknyttede data for, for eksempel et produkt eller en ansatt på ett sted, og vi må bli med i mer enn en tabell. Dette medfører en forsinkelse i å hente dataene.
2. Dermed er normalisering ikke et godt alternativ i OLAP-transaksjoner (Online Analytical Processing).

La oss forstå følgende vilkår før vi går videre:

• Enhet: Enhet er et objekt fra virkeligheten, der dataene knyttet til et slikt objekt er lagret i tabellen. Eksemplet på slike gjenstander er ansatte, avdelinger, studenter osv.
• Attributter: Attributter er egenskapene til enheten, som gir litt informasjon om enheten. For eksempel, Hvis tabeller er enheter, er kolonnene deres attributter.

Typer av normale former

# 1) 1NF (første normale skjema)

Per definisjon kan en enhet som ikke har noen gjentakende kolonner eller datagrupper, betegnes som det første normale skjemaet. I den første normale skjemaet er hver kolonne unik.

Følgende er hvordan våre ansatte og avdelingstabell ville ha sett ut i første normalform (1NF):

Her har alle kolonnene i både ansatte og avdelingstabeller blitt klumpet sammen til en, og det er ikke behov for å koble sammen kolonner, som deptNum, da alle data er tilgjengelige på ett sted.

Men en tabell som dette med alle nødvendige kolonner i, ville ikke bare være vanskelig å administrere, men også vanskelig å utføre operasjoner på og også ineffektiv fra lagringssynspunktet.

# 2) 2NF (Second Normal Form)

Per definisjon er en enhet som er 1NF og en av dens attributter definert som primærnøkkel, og de gjenværende attributtene er avhengig av primærnøkkelen.

Følgende er et eksempel på hvordan de ansatte og avdelingstabellen vil se ut:

Ansatte Tabell:

Avdelingstabell:

EmpDept-tabell:

Her kan vi observere at vi har delt tabellen i 1NF-form i tre forskjellige tabeller. tabellen Ansatte er en enhet om alle ansatte i et selskap, og dets egenskaper beskriver egenskapene til hver ansatt. Den primære nøkkelen til denne tabellen er empNum.

Tilsvarende er avdelingstabellen en enhet om alle avdelingene i et selskap, og dets attributter beskriver egenskapene til hver avdeling. Den primære nøkkelen til denne tabellen er deptNum.

I den tredje tabellen har vi kombinert primærnøklene til begge tabellene. Primærnøklene til tabellene for ansatte og avdelinger er referert til som utenlandske nøkler i denne tredje tabellen.

Hvis brukeren vil ha en utgang som ligner den vi hadde i 1NF, må brukeren bli med i alle de tre tabellene ved hjelp av primærnøklene.

Et eksempelspørsmål ser ut som vist nedenfor:

# 3) 3NF (tredje normale skjema)

Per definisjon blir en tabell ansett som tredje normal hvis tabellen / enheten allerede er i den andre normale formen og kolonnene i tabellen / enheten er ikke-transitt avhengig av primærnøkkelen.

La oss forstå ikke-transitiv avhengighet, ved hjelp av følgende eksempel.

Si en tabell med navnet Kunden har kolonnene nedenfor:

Kunde ID - Primærnøkkel som identifiserer en unik kunde
CustomerZIP - Postnummer til lokalitetskunden er bosatt i
CustomerCity - Byen kunden bor i

I ovennevnte tilfelle er CustomerCity-kolonnen avhengig av CustomerZIP-kolonnen, og CustomerZIP-kolonnen er avhengig av CustomerID.

Ovenstående scenario kalles transitiv avhengighet av CustomerCity-kolonnen på CustomerID, dvs. den primære nøkkelen. Etter å ha forstått transitiv avhengighet, la oss nå diskutere problemet med denne avhengigheten.

Det kan være et mulig scenario der en uønsket oppdatering gjøres i tabellen for oppdatering av CustomerZIP til et postnummer fra en annen by uten å oppdatere CustomerCity, og derved forlate databasen i en inkonsekvent tilstand.

For å løse dette problemet, må vi fjerne den transitive avhengigheten som kan gjøres ved å lage en annen tabell, for eksempel CustZIP-tabell som inneholder to kolonner, dvs. CustomerZIP (som primærnøkkel) og CustomerCity.

CustomerZIP-kolonnen i Customer-tabellen er en fremmed nøkkel til CustomerZIP i CustZIP-tabellen. Dette forholdet sikrer at det ikke er noen uregelmessigheter i oppdateringene der en CustomerZIP oppdateres uten å gjøre endringer i CustomerCity.

# 4) Boyce-Codd Normal Form (3,5 Normal Form)

Per definisjon er tabellen ansett som Boyce-Codd Normal Form, hvis den allerede er i den tredje normale formen, og for hver funksjonelle avhengighet mellom A og B, bør A være en supernøkkel.

Denne definisjonen høres litt komplisert ut. La oss prøve å bryte den for å forstå det bedre.

• Funksjonell avhengighet: Attributtene eller kolonnene i en tabell sies å være funksjonelt avhengige når et attributt eller kolonne i en tabell unikt identifiserer et annet attributt (er) eller kolonne (r) i samme tabell.
  For eksempel, kolonnen empNum eller ansattnummer identifiserer de andre kolonnene unikt, som ansattes navn, lønn til ansatte osv. i tabellen for ansatte.
• Super Key: En enkelt nøkkel eller gruppe med flere taster som unikt kan identifisere en enkelt rad i en tabell kan betegnes som Super Key. Generelt sett kjenner vi slike taster som Composite Keys.

La oss vurdere følgende scenario for å forstå når det er et problem med Third Normal Form, og hvordan kommer Boyce-Codd Normal Form til å redde.

I eksemplet ovenfor jobber ansatte med empNum 1001 og 1007 i to forskjellige avdelinger. Hver avdeling har en avdelingsleder. Det kan være flere avdelingsledere for hver avdeling. I likhet med regnskapsavdelingen er Raymond og Samara de to lederne for avdelingene.

I dette tilfellet er empNum og deptName supernøkler, noe som betyr at deptName er et hovedattributt. Basert på disse to kolonnene kan vi identifisere hver eneste rad unikt.

DeptName avhenger også av deptHead, noe som betyr at deptHead er et ikke-prime-attributt. Dette kriteriet diskvalifiserer tabellen fra å være en del av BCNF.

For å løse dette vil vi dele tabellen inn i tre forskjellige tabeller som nevnt nedenfor:

Ansatte Tabell:

Avdelingstabell:

# 5) Fjerde normalform (4 normalform)

Per definisjon er en tabell i fjerde normalform, hvis den ikke har to eller flere uavhengige data som beskriver den aktuelle enheten.

# 6) Femte normalform (5 normalform)

En tabell kan bare vurderes i femte normalform hvis den oppfyller vilkårene for fjerde normalform og kan deles inn i flere tabeller uten tap av data.

Ofte stilte spørsmål og svar

Q # 1) Hva er normalisering i en database?

Svar: Database Normalisering er en designteknikk. Ved å bruke dette kan vi designe eller omforme skjemaer i databasen for å redusere overflødige data og avhengigheten av data ved å dele dataene inn i mindre og mer relevante tabeller.

Q # 2) Hva er de forskjellige typene normalisering?

Svar: Følgende er de forskjellige typene normaliseringsteknikker som kan brukes til å utforme databaseskjemaer:

c ++ udefinert referanse til klassefunksjon

• Første normale form (1NF)
• Andre normalform (2NF)
• Tredje normalform (3NF)
• Boyce-Codd Normal Form (3.5NF)
• Fjerde normalform (4NF)
• Femte normalform (5NF)

Q # 3) Hva er formålet med normalisering?

Svar: Det primære formålet med normaliseringen er å redusere dataredundansen, dvs. at dataene bare skal lagres en gang. Dette er for å unngå dataavvik som kan oppstå når vi prøver å lagre de samme dataene i to forskjellige tabeller, men endringene gjelder bare for den ene og ikke for den andre.

Q # 4) Hva er denormalisering?

Svar: Denormalisering er en teknikk for å øke ytelsen til databasen. Denne teknikken legger til overflødige data i databasen, i motsetning til den normaliserte databasen som fjerner redundansen til dataene.

Dette gjøres i store databaser der det er en kostbar sak å utføre en JOIN for å få data fra flere tabeller. Dermed lagres overflødige data i flere tabeller for å unngå JOIN-operasjoner.

Konklusjon

Så langt har vi alle gått gjennom tre skjemaer for normalisering av databaser.

Teoretisk er det høyere former for databasenormaliseringer som Boyce-Codd Normal Form, 4NF, 5NF. 3NF er imidlertid det mye brukte normaliseringsskjemaet i produksjonsdatabasene.

Glad lesning !!

Anbefalt lesing

• Databasetesting med JMeter
• MongoDB Create Database Backup
• MongoDB Opprette databaseopplæring
• Topp 10 databasedesignverktøy for å bygge komplekse datamodeller
• MongoDB-ytelse: Låsing av ytelse, sidefeil og databaseprofilering
• Altibase Open Source Relational Database Review
• MongoDB Database Profiler for Monitoring Queries and Performance
• Hvordan teste Oracle Database