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

Normalisering i en nøddeskal

Normalisering er processen med at strukturere en database for at reducere redundans og forbedre konsistens. Kort sagt opdeler den store, rodede tabeller i mindre, velorganiserede tabeller. Dette sikrer, at data lagres logisk, hvilket gør databaser effektive, nemme at vedligeholde og fri for duplikering eller fejl.

Hvad er databasenormalisering?

Databasenormalisering er en databasedesignteknik, der reducerer dataredundans og eliminerer uønskede karakteristika som indsættelses-, opdaterings- og sletningsanomalier. Normaliseringsregler opdeler større tabeller i mindre tabeller og sammenkæder dem ved hjælp af relationer. Formålet med normalisering i SQL er at eliminere overflødige (gentagne) data og sikre, at data lagres logisk.

Opfinderen af relationel model Edgar Codd foreslog teorien om normalisering af data med introduktionen af den første normale form, og han fortsatte med at udvide teorien med den anden og tredje normale form. Later han sluttede sig til Raymond F. Boyce for at udvikle teorien om Boyce-Codd Normal Form.

Hvorfor har vi brug for normalisering?

Uden normalisering bliver databaser hurtigt inkonsistente og overflødige. Problemer som indsættelsesanomalier (ufuldstændige poster kan ikke tilføjes), opdateringsanomalier (ændringer ét sted afspejles ikke alle steder), og sletningsanomalier (fjernelse af data sletter værdifulde oplysninger ved et uheld) forekommer ofte. Normalisering eliminerer disse problemer, hvilket sikrer dataintegritet, reducerer dobbeltarbejde og forenkler databaseadministration.

Hvad er typerne af normalformer i DBMS?

Her er en liste over normale former i SQL:

1NF (First Normal Form): Sikrer, at databasetabellen er organiseret sådan, at hver kolonne indeholder atomare (udelelige) værdier, og hver post er unik. Dette eliminerer gentagne grupper og strukturerer derved data i tabeller og kolonner.
2NF (anden normalform): Bygger på 1NF af Vi skal fjerne overflødige data fra en tabel, der anvendes på flere rækker. og placere dem i separate tabeller. Det kræver, at alle ikke-nøgle-attributter er fuldt funktionelle på den primære nøgle.
3NF (tredje normalform): Udvider 2NF ved at sikre, at alle ikke-nøgleattributter ikke kun er fuldt funktionelle på den primære nøgle, men også uafhængige af hinanden. Dette eliminerer transitiv afhængighed.
BCNF (Boyce-Codd normal form): En forfining af 3NF, der adresserer uregelmæssigheder, der ikke håndteres af 3NF. Det kræver, at enhver determinant er en kandidatnøgle, hvilket sikrer en endnu strengere overholdelse af normaliseringsreglerne.
4NF (Fjerde Normal Form): Løser afhængigheder med flere værdier. Det sikrer, at der ikke er flere uafhængige fakta med flere værdier om en enhed i en post.
5NF (femte normalform): Også kendt som "Projection-Join Normal Form" (PJNF), Det vedrører rekonstruktion af information fra mindre, forskelligt arrangerede datastykker.
6NF (Sjette Normal Form): Teoretisk og ikke bredt implementeret. Den beskæftiger sig med tidsmæssige data (håndtering af ændringer over tid) ved yderligere at dekomponere tabeller for at eliminere al ikke-tidsbestemt redundans.

Teorien om datanormalisering i MySQL serveren er stadig under udvikling. For eksempel er der diskussioner selv den 6^th Normal Form. Men i de fleste praktiske applikationer opnår normalisering sit bedste i 3^rd Normal form. Udviklingen af normalisering i SQL-teorier er illustreret nedenfor-

Database normale formularer

Databasenormalisering med eksempler

Database Normaliseringseksempel kan let forstås ved hjælp af et casestudie. Antag, at et videobibliotek vedligeholder en database over lejede film. Uden normalisering i databasen gemmes al information i én tabel som vist nedenfor. Lad os forstå normaliseringsdatabase med normaliseringseksempel med løsning:

Her ser du Kolonnen Lejede film har flere værdier. Lad os nu gå ind i 1. Normal Forms:

Første normale form (1NF)

Hver tabelcelle skal indeholde en enkelt værdi.
Hver post skal være unik.

Ovenstående tabel i 1NF-

1NF eksempel

Før vi fortsætter, lad os forstå et par ting –

Hvad er en KEY i SQL

A NØGLE i SQL er en værdi, der bruges til at identificere poster i en tabel entydigt. En SQL KEY er en enkelt kolonne eller kombination af flere kolonner, der bruges til entydigt at identificere rækker eller tupler i tabellen. SQL Key bruges til at identificere duplikerede oplysninger, og det hjælper også med at etablere en relation mellem flere tabeller i databasen.

Bemærk: Kolonner i en tabel, der IKKE bruges til at identificere en post entydigt, kaldes ikke-nøglekolonner.

Hvad er en primær nøgle?

En primær er en enkelt kolonneværdi, der bruges til at identificere en databasepost unikt.

Den har følgende egenskaber

A primærnøgle kan ikke være NULL
En primær nøgleværdi skal være unik
De primære nøgleværdier bør sjældent ændres
Den primære nøgle skal have en værdi, når en ny post indsættes.

Hvad er Composite Key?

En sammensat nøgle er en primær nøgle sammensat af flere kolonner, der bruges til at identificere en post unikt

I vores database har vi to personer med samme navn Robert Phil, men de bor forskellige steder.

Derfor kræver vi både fulde navn og adresse for at identificere en post unikt. Det er en sammensat nøgle.

Lad os gå ind i anden normalform 2NF

Anden normal form (2NF)

Regel 1- Vær i 1NF
Regel 2 - Enkeltkolonne primærnøgle, der ikke er funktionelt afhængig af nogen delmængde af kandidatnøglerelationen

Det er klart, at vi ikke kan komme videre med at lave vores simple database i 2^nd Normaliseringsform, medmindre vi opdeler tabellen ovenfor.

Vi har delt vores 1NF-bord op i to borde, dvs. Tabel 1 og Tabel 2. Tabel 1 indeholder medlemsoplysninger. Tabel 2 indeholder oplysninger om lejede film.

Vi har introduceret en ny kolonne kaldet Membership_id, som er den primære nøgle til tabel 1. Records kan identificeres entydigt i tabel 1 ved hjælp af medlems-id

Database – fremmednøgle

I tabel 2 er Membership_ID den fremmede nøgle

Foreign Key refererer til den primære nøgle i en anden tabel! Det hjælper med at forbinde dine borde

En fremmednøgle kan have et andet navn end dens primære nøgle
Det sikrer, at rækker i én tabel har tilsvarende rækker i en anden
I modsætning til den primære nøgle behøver de ikke at være unikke. Oftest er de ikke
Fremmednøgler kan være nul, selvom primærnøgler ikke kan

Hvorfor har du brug for en fremmednøgle?

Antag, at en nybegynder indsætter en post i tabel B som f.eks

Du vil kun være i stand til at indsætte værdier i din fremmednøgle, som findes i den unikke nøgle i den overordnede tabel. Dette hjælper med referentiel integritet.

Ovenstående problem kan løses ved at erklære medlems-id fra tabel2 som fremmednøgle til medlems-id fra tabel1

Nu, hvis nogen forsøger at indsætte en værdi i medlemskabs-id-feltet, som ikke findes i den overordnede tabel, vil der blive vist en fejl!

Hvad er transitive funktionelle afhængigheder?

En transitiv funktionel afhængighed er, når du ændrer en ikke-nøglekolonne, kan forårsage, at enhver af de andre ikke-nøglekolonner ændres

Overvej tabellen 1. Ændring af ikke-nøglekolonnen Fuldt navn kan ændre hilsen.

Lad os gå ind i 3NF

Tredje normale form (3NF)

Regel 1- Vær i 2NF
Regel 2- Har ingen transitive funktionelle afhængigheder

For at flytte vores 2NF-bord til 3NF, skal vi igen opdele vores bord.

3NF eksempel

Nedenfor er et 3NF eksempel i SQL database:

Vi har igen delt vores borde op og lavet et nyt bord, som gemmer salutations.

Der er ingen transitive funktionelle afhængigheder, og derfor er vores tabel i 3NF

I tabel 3 er hilsen-id primærnøgle, og i tabel 1 er hilsen-id fremmed for primærnøgle i tabel 3

Nu er vores lille eksempel på et niveau, der ikke kan dekomponeres yderligere for at opnå højere normal form for normalisering i DBMS. Faktisk er det allerede i højere normaliseringsformer. Separate bestræbelser på at flytte ind på næste niveauer af normalisering af data er normalt nødvendige i komplekse databaser. Vi vil dog kort diskutere næste niveauer af normalisering i DBMS i det følgende.

Boyce-Codd normal form (BCNF)

Selv når en database er i 3^rd Normal form, der ville stadig være anomalier, hvis den har mere end én Kandidat Nøgle.

Nogle gange kaldes BCNF også 3.5 Normalform.

Fjerde normal form (4NF)

Hvis ingen databasetabelforekomst indeholder to eller flere uafhængige data med flere værdier, der beskriver den relevante enhed, er den i 4^th Normal Form.

Femte normale form (5NF)

Et bord er i 5^th Normal Form kun hvis den er i 4NF og den ikke kan dekomponeres i et hvilket som helst antal mindre tabeller uden tab af data.

Sjette normalform (6NF) foreslået

6^th Normal Form er ikke standardiseret, men det er dog blevet diskuteret af databaseeksperter i nogen tid. Forhåbentlig ville vi have en klar og standardiseret definition for 6^th Normal form i nær fremtid...

Hvad er fordelene ved normalisering?

Forbedre datakonsistens: Normalisering sikrer, at hvert stykke data kun gemmes ét sted, hvilket reducerer chancerne for inkonsistente data. Når data opdateres, skal de kun opdateres ét sted, hvilket sikrer konsistens.
Reducer dataredundans: Normalisering hjælper med at eliminere duplikerede data ved at opdele dem i flere relaterede tabeller. Dette kan spare lagerplads og også gøre databasen mere effektiv.
Forbedre forespørgselsydeevne: Normaliserede databaser er ofte nemmere at forespørge på. Fordi data er organiseret logisk, kan forespørgsler optimeres til at køre hurtigere.
Gør data mere meningsfulde: Normalisering involverer grupperingping data på en måde, der giver mening og er intuitiv. Dette kan gøre databasen nemmere at forstå og bruge, især for folk, der ikke selv har designet databasen.
Reducer chancerne for uregelmæssigheder: Anomalier er problemer, der kan opstå ved tilføjelse, opdatering eller sletning af data. Normalisering kan reducere chancerne for disse anomalier ved at sikre, at data er logisk organiseret.

Hvad er ulemperne ved normalisering?

Øget kompleksitet: Normalisering kan føre til komplekse relationer. Et stort antal tabeller med fremmednøgler kan være vanskelige at administrere, hvilket fører til forvirring.
Reduceret fleksibilitet: På grund af de strenge regler for normalisering kan der være mindre fleksibilitet i lagring af data, der ikke overholder disse regler.
Øgede lagerkrav: Mens normalisering reducerer redundans, kan det være nødvendigt at allokere mere lagerplads for at rumme de ekstra tabeller og indekser.
Overhead over ydeevne: At samle flere borde kan være dyrt med hensyn til ydeevne. Jo mere normaliserede data, jo flere joinforbindelser er nødvendige, hvilket kan sænke datahentningstider.
Tab af datakontekst: Normalisering opdeler data i separate tabeller, hvilket kan føre til tab af forretningskontekst. Det er nødvendigt at undersøge relaterede tabeller for at forstå konteksten af et stykke data.
Behov for ekspertviden: Implementering af en normaliseret database kræver en dyb forståelse af dataene, relationerne mellem data og normaliseringsreglerne. Dette kræver ekspertviden og kan være tidskrævende.

Det er alt til SQL Normalisering!!!

Ofte Stillede Spørgsmål

Normalisering i DBMS er en proces til at organisere data i en database for at reducere redundans og forbedre dataintegriteten. Det involverer at opdele store tabeller i mindre, relaterede tabeller og definere relationer mellem dem. Dette sikrer, at data gemmes logisk og konsekvent, hvilket gør opdateringer, indsættelser og sletninger mere effektive, samtidig med at anomalier forhindres.

Datanormalisering strukturerer databasetabeller for at undgå gentagelse. For eksempel placerer normalisering kundeoplysninger i en separat "Kunde"-tabel, der er forbundet med en nøgle, i stedet for at gemme en kundes adresse i hver ordrepost. Dette reducerer redundans – så hvis en adresse ændres, opdateres den kun én gang. Resultatet er en renere og mere effektiv database med nøjagtige og ensartede data.

Formålet med normalisering er at eliminere overflødige data, minimere anomalier og sikre databaseeffektivitet. Det forenkler vedligeholdelse ved at holdeping organiserer relateret information, reducerer lagerspild og håndhæver datakonsistens. Normalisering forbedrer også forespørgselsydelsen ved at strukturere data logisk, hvilket giver udviklere og brugere adgang til nøjagtige oplysninger uden at skulle håndtere dobbeltarbejde eller modstridende poster.

Tredje normalform (3NF) er et normaliseringstrin, der sikrer, at alle ikke-nøgleattributter kun afhænger af den primære nøgle og ikke af andre ikke-nøgleattributter. For eksempel bør "Afdelingsnavn" i en medarbejdertabel opdeles i en afdelingstabel i stedet for at stole på "Afdelings-ID". Dette undgår transitive afhængigheder og sikrer nøjagtighed, konsistens og effektivitet i datahåndtering.