DBMS-normalisering: 1NF, 2NF, 3NF Databaseeksempel

Normalisering i et nøtteskall

Normalisering er prosessen med å strukturere en database for å redusere redundans og forbedre konsistens. Enkelt sagt deler den opp store, rotete tabeller i mindre, velorganiserte tabeller. Dette sikrer at data lagres logisk, noe som gjør databaser effektive, enkle å vedlikeholde og fri for duplisering eller feil.

Hva er databasenormalisering?

Database Normalisering er en databasedesignteknikk som reduserer dataredundans og eliminerer uønskede egenskaper som innsetting, oppdatering og slettingsanomalier. Normaliseringsregler deler større tabeller inn i mindre tabeller og kobler dem ved hjelp av relasjoner. Formålet med normalisering i SQL er å eliminere redundante (repeterende) data og sikre at data lagres logisk.

Oppfinneren av relasjonsmodell Edgar Codd foreslo teorien om normalisering av data med introduksjonen av den første normalformen, og han fortsatte å utvide teorien med andre og tredje normalform. Later han ble med Raymond F. Boyce for å utvikle teorien om Boyce-Codd Normal Form.

Hvorfor trenger vi normalisering?

Uten normalisering blir databaser raskt inkonsistente og overflødige. Problemer som innsettingsanomalier (ufullstendige poster kan ikke legges til), oppdateringsavvik (endringer på ett sted gjenspeiles ikke overalt), og slettingsavvik (utilsiktet sletting av data fører ofte til at verdifull informasjon slettes). Normalisering eliminerer disse problemene, sikrer dataintegritet, reduserer duplisering og forenkler databaseadministrasjon.

Hva er typene normalformer i DBMS?

Her er en liste over normale skjemaer i SQL:

1NF (første normalform): Sikrer at databasetabellen er organisert slik at hver kolonne inneholder atomære (udelelige) verdier, og hver post er unik. Dette eliminerer gjentatte grupper, og strukturerer dermed data i tabeller og kolonner.
2NF (andre normalform): Bygger på 1NF av Vi må fjerne overflødige data fra en tabell som brukes på flere rader. og plassere dem i separate tabeller. Det krever at alle ikke-nøkkelattributter er fullt funksjonelle på primærnøkkelen.
3NF (tredje normalform): Utvider 2NF ved å sikre at alle ikke-nøkkelattributter ikke bare er fullt funksjonelle på primærnøkkelen, men også uavhengige av hverandre. Dette eliminerer transitiv avhengighet.
BCNF (Boyce-Codd normal form): En foredling av 3NF som adresserer uregelmessigheter som ikke håndteres av 3NF. Det krever at hver determinant er en kandidatnøkkel, noe som sikrer enda strengere overholdelse av normaliseringsreglene.
4NF (fjerde normalform): Adresserer avhengigheter med flere verdier. Det sikrer at det ikke er flere uavhengige fakta med flere verdier om en enhet i en post.
5NF (femte normalform): Også kjent som "Projection-Join Normal Form" (PJNF), det gjelder rekonstruksjon av informasjon fra mindre, annerledes ordnede databiter.
6NF (Sjette normalform): Teoretisk og lite implementert. Den tar for seg tidsdata (håndterer endringer over tid) ved å dekomponere tabeller ytterligere for å eliminere all ikke-tidsmessig redundans.

Teorien om datanormalisering i MySQL serveren er fortsatt under utvikling. For eksempel er det diskusjoner selv på 6^th Normal form. Men i de fleste praktiske applikasjoner oppnår normalisering sitt beste i 3^rd Normal form. Utviklingen av normalisering i SQL-teorier er illustrert nedenfor-

Database normale skjemaer

Databasenormalisering med eksempler

Database Normaliseringseksempel kan lett forstås ved hjelp av en casestudie. Anta at et videobibliotek opprettholder en database over filmer som er leid ut. Uten normalisering i databasen lagres all informasjon i én tabell som vist nedenfor. La oss forstå normaliseringsdatabase med normaliseringseksempel med løsning:

Her ser du Filmer leid-kolonnen har flere verdier. La oss nå gå til 1. Normal Forms:

Første normale form (1NF)

Hver tabellcelle skal inneholde én enkelt verdi.
Hver post må være unik.

Tabellen ovenfor i 1NF-

1NF eksempel

Før vi fortsetter, la oss forstå et par ting -

Hva er en KEY i SQL

A NØKKEL i SQL er en verdi som brukes til å identifisere poster i en tabell unikt. En SQL-nøkkel er en enkelt kolonne eller kombinasjon av flere kolonner som brukes til å identifisere rader eller tupler i tabellen unikt. SQL Key brukes til å identifisere duplikatinformasjon, og den hjelper også med å etablere et forhold mellom flere tabeller i databasen.

Merk: Kolonner i en tabell som IKKE brukes til å identifisere en post unikt kalles ikke-nøkkelkolonner.

Hva er en primærnøkkel?

En primær er en enkelt kolonneverdi som brukes til å identifisere en databasepost unikt.

Den har følgende attributter

A primærnøkkel kan ikke være NULL
En primærnøkkelverdi må være unik
Primærnøkkelverdiene bør sjelden endres
Primærnøkkelen må gis en verdi når en ny post settes inn.

Hva er Composite Key?

En sammensatt nøkkel er en primærnøkkel som består av flere kolonner som brukes til å identifisere en post unikt

I databasen vår har vi to personer med samme navn Robert Phil, men de bor på forskjellige steder.

Derfor krever vi både fullt navn og adresse for å identifisere en post unikt. Det er en sammensatt nøkkel.

La oss gå inn i andre normalform 2NF

Andre normalform (2NF)

Regel 1- Vær i 1NF
Regel 2 - Enkeltkolonne primærnøkkel som ikke er funksjonelt avhengig av noen delsett av kandidatnøkkelrelasjonen

Det er klart at vi ikke kan gå videre for å lage vår enkle database i 2^nd Normaliseringsform med mindre vi deler opp tabellen ovenfor.

Vi har delt vårt 1NF-bord i to tabeller, nemlig. Tabell 1 og Tabell 2. Tabell 1 inneholder medlemsinformasjon. Tabell 2 inneholder informasjon om leid filmer.

Vi har introdusert en ny kolonne kalt Membership_id som er primærnøkkelen for tabell 1. Poster kan identifiseres unikt i Tabell 1 ved hjelp av medlems-ID

Database – fremmednøkkel

I tabell 2 er Membership_ID den fremmede nøkkelen

Foreign Key refererer til primærnøkkelen til en annen tabell! Det hjelper med å koble sammen tabellene dine

En fremmednøkkel kan ha et annet navn enn primærnøkkelen
Det sikrer at rader i en tabell har tilsvarende rader i en annen
I motsetning til primærnøkkelen, trenger de ikke å være unike. Oftest er de ikke det
Fremmednøkler kan være null selv om primærnøkler ikke kan

Hvorfor trenger du en fremmednøkkel?

Anta at en nybegynner setter inn en post i tabell B som f.eks

Du vil kun kunne sette inn verdier i din fremmednøkkel som finnes i den unike nøkkelen i den overordnede tabellen. Dette hjelper med referanseintegritet.

Problemet ovenfor kan løses ved å erklære medlems-ID fra Tabell2 som fremmednøkkel for medlems-ID fra Tabell1

Nå, hvis noen prøver å sette inn en verdi i medlems-ID-feltet som ikke eksisterer i den overordnede tabellen, vil en feil vises!

Hva er transitive funksjonelle avhengigheter?

En transitiv funksjonell avhengighet er når du endrer en ikke-nøkkelkolonne, kan føre til at noen av de andre ikke-nøkkelkolonnene endres

Tenk på tabellen 1. Endring av ikke-nøkkelkolonnen Fullt navn kan endre hilsen.

La oss gå inn i 3NF

Tredje normalform (3NF)

Regel 1- Vær i 2NF
Regel 2- Har ingen transitive funksjonelle avhengigheter

For å flytte 2NF-tabellen vår til 3NF, må vi igjen dele bordet vårt.

3NF eksempel

Nedenfor er et 3NF-eksempel i SQL-database:

Vi har igjen delt bordene våre og laget et nytt bord som lagrer hilsener.

Det er ingen transitive funksjonelle avhengigheter, og derfor er tabellen vår i 3NF

I tabell 3 er hilsen-ID primærnøkkel, og i tabell 1 er hilsen-ID fremmed for primærnøkkelen i tabell 3

Nå er vårt lille eksempel på et nivå som ikke kan dekomponeres videre for å oppnå høyere normalformtyper av normalisering i DBMS. Faktisk er det allerede i høyere normaliseringsformer. Separate anstrengelser for å gå inn på neste nivå med normalisering av data er vanligvis nødvendig i komplekse databaser. Imidlertid vil vi diskutere neste nivåer av normalisering i DBMS i korthet i det følgende.

Boyce-Codd normal form (BCNF)

Selv når en database er i 3^rd Normal form, fortsatt vil det være anomalier hvis den har mer enn én Kandidat Key.

Noen ganger er BCNF også referert til som 3.5 Normalform.

Fjerde normalform (4NF)

Hvis ingen databasetabellforekomst inneholder to eller flere uavhengige og multiverdidata som beskriver den relevante enheten, er den i 4^th Normal form.

Femte normalform (5NF)

Et bord er i 5^th Normal Form bare hvis den er i 4NF og den ikke kan dekomponeres i et antall mindre tabeller uten tap av data.

Sjette normalform (6NF) foreslått

6^th Normal form er ikke standardisert, men det er imidlertid diskutert av databaseeksperter i noen tid. Forhåpentligvis vil vi ha en klar og standardisert definisjon for 6^th Normal form i nær fremtid...

Hva er fordelene med normalisering?

Forbedre datakonsistens: Normalisering sikrer at hver del av data bare lagres på ett sted, noe som reduserer sjansene for inkonsistente data. Når data oppdateres, trenger de bare å oppdateres på ett sted, noe som sikrer konsistens.
Reduser dataredundans: Normalisering hjelper til med å eliminere dupliserte data ved å dele dem inn i flere relaterte tabeller. Dette kan spare lagringsplass og også gjøre databasen mer effektiv.
Forbedre søkeytelsen: Normaliserte databaser er ofte lettere å søke etter. Fordi data er logisk organisert, kan spørringer optimaliseres for å kjøre raskere.
Gjør data mer meningsfulle: Normalisering innebærer grupperingping data på en måte som gir mening og er intuitiv. Dette kan gjøre databasen enklere å forstå og bruke, spesielt for folk som ikke designet databasen.
Reduser sjansene for uregelmessigheter: Avvik er problemer som kan oppstå når du legger til, oppdaterer eller sletter data. Normalisering kan redusere sjansene for disse anomaliene ved å sikre at data er logisk organisert.

Hva er ulempene med normalisering?

Økt kompleksitet: Normalisering kan føre til komplekse relasjoner. Et stort antall tabeller med fremmednøkler kan være vanskelig å administrere, noe som fører til forvirring.
Redusert fleksibilitet: På grunn av de strenge reglene for normalisering, kan det være mindre fleksibilitet i lagring av data som ikke overholder disse reglene.
Økte lagringskrav: Mens normalisering reduserer redundans, kan det være nødvendig å tildele mer lagringsplass for å imøtekomme de ekstra tabellene og indeksene.
Ytelsesoverhead: Å slå sammen flere bord kan være kostbart med tanke på ytelse. Jo mer normaliserte dataene er, desto flere sammenføyninger er nødvendig, noe som kan redusere tiden for datainnhenting.
Tap av datakontekst: Normalisering bryter ned data i separate tabeller, noe som kan føre til tap av forretningskontekst. Å undersøke relaterte tabeller er nødvendig for å forstå konteksten til et datastykke.
Behov for ekspertkunnskap: Implementering av en normalisert database krever en dyp forståelse av dataene, forholdet mellom data og normaliseringsreglene. Dette krever ekspertkunnskap og kan være tidkrevende.

Det er alt til SQL-normalisering!!!

Spørsmål og svar

Normalisering i DBMS er en prosess for å organisere data i en database for å redusere redundans og forbedre dataintegriteten. Det innebærer å dele opp store tabeller i mindre, relaterte tabeller og definere relasjoner mellom dem. Dette sikrer at data lagres logisk og konsekvent, noe som gjør oppdateringer, innsettinger og slettinger mer effektive samtidig som det forhindrer avvik.

Datanormalisering strukturerer databasetabeller for å unngå repetisjon. For eksempel, i stedet for å lagre en kundes adresse i hver ordrepost, plasserer normalisering kundedetaljer i en separat «Kunde»-tabell koblet sammen med en nøkkel. Dette reduserer redundans – så hvis en adresse endres, oppdateres den bare én gang. Resultatet er en renere og mer effektiv database med nøyaktige og konsistente data.

Formålet med normalisering er å eliminere overflødige data, minimere avvik og sikre databaseeffektivitet. Det forenkler vedlikehold ved å holdeping organiserer relatert informasjon, reduserer lagringssløsing og fremtvinger datakonsistens. Normalisering forbedrer også spørringsytelsen ved å strukturere data logisk, slik at utviklere og brukere får tilgang til nøyaktig informasjon uten å måtte håndtere duplisering eller motstridende oppføringer.

Tredje normalform (3NF) er et normaliseringsstadium som sikrer at alle ikke-nøkkelattributter kun avhenger av primærnøkkelen og ikke av andre ikke-nøkkelattributter. For eksempel, i en ansatttabell, bør «Avdelingsnavn» skilles ut i en avdelingstabell i stedet for å stole på «Avdelings-ID». Dette unngår transitive avhengigheter, og sikrer nøyaktighet, konsistens og effektivitet i datahåndtering.