Normalisering er processen med at minimere redundans fra en relation eller et sæt af relationer. Redundans i forhold kan forårsage indsættelse, sletning og opdatering af uregelmæssigheder. Så det hjælper med at minimere redundansen i relationer. Normale former bruges til at eliminere eller reducere redundans i databasetabeller.

Normalisering af DBMS af Ranjan Hero

I databasestyringssystemer (DBMS) er normale formularer en række retningslinjer, der hjælper med at sikre, at designet af en database er effektivt, organiseret og fri for dataanomalier. Der er flere niveauer af normalisering, hver med sit eget sæt retningslinjer, kendt som normale former.

Vigtige punkter vedrørende normale formularer i DBMS

• Første normale form (1NF): Dette er det mest grundlæggende niveau af normalisering. I 1NF skal hver tabelcelle kun indeholde en enkelt værdi, og hver kolonne skal have et unikt navn. Den første normale formular hjælper med at eliminere duplikerede data og forenkle forespørgsler.
• Anden normal form (2NF): 2NF eliminerer redundante data ved at kræve, at hver ikke-nøgle-attribut er afhængig af den primære nøgle. Det betyder, at hver kolonne skal være direkte relateret til den primære nøgle og ikke til andre kolonner.
• Tredje normalform (3NF): 3NF bygger på 2NF ved at kræve, at alle ikke-nøgleattributter er uafhængige af hinanden. Det betyder, at hver kolonne skal være direkte relateret til den primære nøgle og ikke til andre kolonner i samme tabel.
• Boyce-Codd normal form (BCNF): BCNF er en strengere form for 3NF, der sikrer, at hver determinant i en tabel er en kandidatnøgle. Med andre ord sikrer BCNF, at hver ikke-nøgle-attribut kun er afhængig af kandidatnøglen.
• Fjerde normalform (4NF): 4NF er en yderligere forfining af BCNF, der sikrer, at en tabel ikke indeholder afhængigheder med flere værdier.
• Femte normalform (5NF): 5NF er det højeste niveau af normalisering og involverer dekomponering af en tabel i mindre tabeller for at fjerne dataredundans og forbedre dataintegriteten.

Normale formularer hjælper med at reducere dataredundans, øge datakonsistensen og forbedre databasens ydeevne. Imidlertid kan højere niveauer af normalisering føre til mere komplekse databasedesign og forespørgsler. Det er vigtigt at finde en balance mellem normalisering og praktisk, når du designer en database.

Fordele ved normal form

• Reduceret dataredundans: Normalisering hjælper med at eliminere duplikerede data i tabeller, hvilket reducerer mængden af ​​nødvendig lagerplads og forbedrer databaseeffektiviteten.
• Forbedret datakonsistens: Normalisering sikrer, at data opbevares på en ensartet og organiseret måde, hvilket reducerer risikoen for datainkonsistens og fejl.
• Forenklet databasedesign: Normalisering giver retningslinjer for organisering af tabeller og datarelationer, hvilket gør det nemmere at designe og vedligeholde en database.
• Forbedret forespørgselsydeevne: Normaliserede tabeller er typisk nemmere at søge og hente data fra, hvilket resulterer i hurtigere forespørgselsydeevne.
• Nemmere databasevedligeholdelse: Normalisering reducerer kompleksiteten af ​​en database ved at opdele den i mindre, mere håndterbare tabeller, hvilket gør det nemmere at tilføje, ændre og slette data.

Samlet set hjælper brug af normale formularer i DBMS med at forbedre datakvaliteten, øge databaseeffektiviteten og forenkle databasedesign og vedligeholdelse.

Første Normalform

Hvis en relation indeholder sammensat attribut eller attribut med flere værdier, overtræder den første normalform, eller en relation er i første normalform, hvis den ikke indeholder nogen sammensat attribut eller attribut med flere værdier. En relation er i første normal form, hvis hver egenskab i denne relation er enkelt værdisat attribut .

• Eksempel 1 – Relation STUDENT i tabel 1 er ikke i 1NF på grund af multi-valued attribut STUD_PHONE. Dets nedbrydning til 1NF er vist i tabel 2.

Eksempel

• Eksempel 2 –

ID Name Courses ------------------ 1 A c1, c2 2 E c3 3 M C2, c3>

• I ovenstående tabel er Kurset en attribut med flere værdier, så det er ikke i 1NF. Nedenstående tabel er i 1NF, da der ikke er nogen attribut med flere værdier

ID Name Course ------------------ 1 A c1 1 A c2 2 E c3 3 M c2 3 M c3>

Anden Normalform

For at være i anden normalform skal en relation være i første normalform, og relation må ikke indeholde nogen delvis afhængighed. En relation er i 2NF, hvis den har Ingen delvis afhængighed, dvs. , ingen ikke-primær attribut (attributter, der ikke er en del af en kandidatnøgle) er afhængig af en korrekt delmængde af enhver kandidatnøgle i tabellen. Delvis afhængighed – Hvis den korrekte delmængde af kandidatnøgle bestemmer en ikke-primær attribut, kaldes det delvis afhængighed.

• Eksempel 1 – Overvej tabel-3 som følgende nedenfor.

STUD_NO COURSE_NO COURSE_FEE 1 C1 1000 2 C2 1500 1 C4 2000 4 C3 1000 4 C1 1000 2 C5 2000>

• {Bemærk, at der er mange kurser med samme kursusgebyr} Her kan COURSE_FEE ikke alene bestemme værdien af ​​COURSE_NO eller STUD_NO; COURSE_FEE sammen med STUD_NO kan ikke bestemme værdien af ​​COURSE_NO; COURSE_FEE sammen med COURSE_NO kan ikke bestemme værdien af ​​STUD_NO; Derfor ville COURSE_FEE være en ikke-prime-attribut, da den ikke tilhører den eneste kandidatnøgle {STUD_NO, COURSE_NO} ; Men, COURSE_NO -> COURSE_FEE, dvs. COURSE_FEE er afhængig af COURSE_NO, som er en korrekt delmængde af kandidatnøglen. Ikke-primær attribut COURSE_FEE er afhængig af en korrekt delmængde af kandidatnøglen, som er en delvis afhængighed, og derfor er denne relation ikke i 2NF. For at konvertere ovenstående relation til 2NF, skal vi opdele tabellen i to tabeller såsom: Tabel 1: STUD_NO, COURSE_NO Tabel 2: COURSE_NO, COURSE_FEE

   Table 1     Table 2  STUD_NO COURSE_NO COURSE_NO COURSE_FEE  1 C1 C1 1000 2 C2 C2 1500 1 C4 C3 1000 4 C3 C4 2000 4 C1 C5 2000>

• BEMÆRK: 2NF forsøger at reducere de redundante data, der bliver gemt i hukommelsen. For eksempel, hvis der er 100 studerende, der tager C1-kursus, behøver vi ikke at gemme dets gebyr som 1000 for alle de 100 poster, i stedet for, når vi først kan gemme det i den anden tabel, da kursusgebyret for C1 er 1000.
• Eksempel 2 – Overvej følgende funktionelle afhængigheder i relation R (A, B, C, D)

AB ->C [A og B bestemmer sammen C] BC -> D [B og C bestemmer sammen D]>

I ovenstående relation er AB den eneste kandidatnøgle, og der er ingen delvis afhængighed, dvs. enhver korrekt delmængde af AB bestemmer ikke nogen ikke-primær attribut.

X is a super key. Y is a prime attribute (each element of Y is part of some candidate key).>

Eksempel 1: I relation til STUDENT givet i tabel 4, FD-sæt: {STUD_NO -> STUD_NAME, STUD_NO -> STUD_STATE, STUD_STATE -> STUD_COUNTRY, STUD_NO -> STUD_AGE}

Kandidatnøgle: {STUD_NO}

For denne relation i tabel 4 er STUD_NO -> STUD_STATE og STUD_STATE -> STUD_COUNTRY sande.

Så STUD_COUNTRY er transitivt afhængig af STUD_NO. Det krænker den tredje normalform.

forekomst af java

For at konvertere den i tredje normal form, vil vi dekomponere relationen STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_COUNTRY_STUD_AGE) som: STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_AGE) STATE_COUNTRY (STATE, COUNTRY)

Overvej relation R(A, B, C, D, E) A -> BC, CD -> E, B -> D, E -> A Alle mulige kandidatnøgler i ovenstående relation er {A, E, CD, BC} Alle attributter er på højre side af alle funktionelle afhængigheder er prime.

Eksempel 2: Find den højeste normalform af en relation R(A,B,C,D,E) med FD sat som {BC->D, AC->BE, B->E}

Trin 1: Som vi kan se, (AC)+ ={A,C,B,E,D}, men ingen af ​​dens delmængde kan bestemme alle attributter af relation, så AC vil være kandidatnøgle. A eller C kan ikke udledes af nogen anden attribut i relationen, så der vil kun være 1 kandidatnøgle {AC}.

Trin 2: Primære attributter er de attributter, der er en del af kandidatnøgle {A, C} i dette eksempel, og andre vil være ikke-prime {B, D, E} i dette eksempel.

Trin 3: Relationen R er i 1. normal form, da et relationelt DBMS ikke tillader multi-værdi eller sammensat attribut. Relationen er på 2. normalform, fordi BC->D er på 2. normalform (BC er ikke en korrekt delmængde af kandidatnøgle AC) og AC->BE er på 2. normalform (AC er kandidatnøgle) og B->E er i 2. normalform (B er ikke en korrekt delmængde af kandidatnøgle AC).

Relationen er ikke i 3. normalform, fordi i BC->D (hverken BC er en supernøgle eller D er en prime attribut) og i B->E (hverken B er en supernøgle eller E er en prime attribut) men til opfylde 3. normal for, enten LHS af en FD skal være supernøgle eller RHS skal være prime attribut. Så den højeste normalform for relation vil være 2. Normalform.

læse fra csv java

Overvej for eksempel relation R(A, B, C) A -> BC, B -> A og B er begge supernøgler, så ovenstående relation er i BCNF.

Tredje Normalform

En relation siges at være i tredje normal form, hvis vi ikke havde nogen transitiv afhængighed for ikke-primære attributter. Grundbetingelsen med den tredje normalform er, at relationen skal være i anden normalform.

Nedenfor nævnt er den grundlæggende betingelse, der skal være gældende i den ikke-trivielle funktionelle afhængighed X -> Y:

• X er en supernøgle.
• Y er en primær attribut (dette betyder, at element af Y er en del af kandidatnøgle).

For mere, se Tredje normalform i DBMS.

BCNF

BCNF (Boyce-Codd Normal Form) er blot en avanceret version af Third Normal Form. Her har vi nogle yderligere regler end den tredje normalform. Den grundlæggende betingelse for at enhver relation er i BCNF er, at den skal være i tredje normalform.

Vi er nødt til at fokusere på nogle grundlæggende regler, der er for BCNF:

1. Table must be in Third Normal Form. 2. In relation X->Y, X skal være en supernøgle i en relation.>

For mere, se BCNF i DBMS.

Fjerde Normalform

Fjerde Normalform indeholder ingen ikke-triviel multivaued-afhængighed undtagen kandidatnøgle. Grundbetingelsen med Fjerde Normalform er, at relationen skal være i BCNF.

De grundlæggende regler er nævnt nedenfor.

1. It must be in BCNF. 2. It does not have any multi-valued dependency.>

For mere, se Fjerde normalform i DBMS.

Femte Normalform

Femte normalform kaldes også for den projicerede normalform. De grundlæggende betingelser for Fifth Normal Form er nævnt nedenfor.

java heltal til streng

Relation must be in Fourth Normal Form. The relation must not be further non loss decomposed.>

For mere, se Femte normalform i DBMS.

Anvendelser af normale former i DBMS

• Datakonsistens: Normale formularer sikrer, at data er konsistente og ikke indeholder overflødige oplysninger. Dette hjælper med at forhindre uoverensstemmelser og fejl i databasen.
• Dataredundans: Normale formularer minimerer dataredundans ved at organisere data i tabeller, der kun indeholder unikke data. Dette reducerer mængden af ​​lagerplads, der kræves til databasen, og gør den nemmere at administrere.
• Responstid: Normale formularer kan forbedre forespørgselsydeevnen ved at reducere antallet af joinforbindelser, der kræves for at hente data. Dette hjælper med at fremskynde forespørgselsbehandlingen og forbedre den overordnede systemydeevne.
• Databasevedligeholdelse: Normale formularer gør det nemmere at vedligeholde databasen ved at reducere mængden af ​​overflødige data, der skal opdateres, slettes eller ændres. Dette hjælper med at forbedre databasestyringen og reducere risikoen for fejl eller uoverensstemmelser.
• Database design: Normale formularer giver retningslinjer for design af databaser, der er effektive, fleksible og skalerbare. Dette er med til at sikre, at databasen nemt kan ændres, opdateres eller udvides efter behov.

Nogle vigtige punkter om normale former

• BCNF er fri for redundans forårsaget af funktionelle afhængigheder.
• Hvis en relation er i BCNF, så er 3NF også opfyldt.
• Hvis alle attributter af relation er prime attribut, så er relationen altid i 3NF.
• En relation i en relationsdatabase er altid og mindst i 1NF-form.
• Hver binær relation (en relation med kun 2 attributter) er altid i BCNF.
• Hvis en relation kun har singleton-kandidatnøgler (dvs. hver kandidatnøgle består kun af 1 attribut), så er relationen altid i 2NF (fordi ingen delvis funktionel afhængighed er mulig).
• Nogle gange kan det at gå efter BCNF-form ikke bevare funktionel afhængighed. I så fald skal du kun gå til BCNF, hvis den/de tabte FD(er) ikke er påkrævet, ellers normaliser kun til 3NF.
• Der er mange flere normale former, der eksisterer efter BCNF, som 4NF og mere. Men i databasesystemer i den virkelige verden er det generelt ikke nødvendigt at gå ud over BCNF.

Konklusion

Som konklusion kan relationelle databaser arrangeres i henhold til et sæt regler kaldet normale former i database administration (1NF, 2NF, 3NF, BCNF, 4NF og 5NF), som reducerer dataredundans og bevarer dataintegriteten. Ved at løse forskellige typer dataanomalier og afhængigheder udvider hver efterfølgende normalform sig til den, der kom før den. De særlige krav og egenskaber ved de data, der lagres, bestemmer, hvilken normal form der skal anvendes; højere normale former giver strengere dataintegritet, men kan også resultere i mere komplicerede databasestrukturer.

Spørgsmålslinks til forrige år

• GATE CS 2012, spørgsmål 2
• GATE CS 2013, spørgsmål 54
• GATE CS 2013, spørgsmål 55
• GATE CS 2005, spørgsmål 29
• GATE CS 2002, spørgsmål 23
• GATE CS 2002, spørgsmål 50
• GATE CS 2001, spørgsmål 48
• GATE CS 1999, spørgsmål 32
• GATE IT 2005, spørgsmål 22
• GATE IT 2008, spørgsmål 60
• GATE CS 2016 (sæt 1), spørgsmål 31

Ofte stillede spørgsmål på normal form

Sp.1: Hvorfor er normalisering vigtig i DBMS?

Svar:

Normalisering hjælper med at forhindre databasen fra uregelmæssigheder, hvilket i sidste ende sikrer databasens konsistens og hjælper med nem vedligeholdelse af databasen.

Q.2: Er det muligt at overnormalisere databasen?

Svar:

Ja, overdreven normalisering vil gå til komplekse forespørgsler og reducerer også ydeevnen. Det skaber balance mellem normalisering og praktisk.

Sp.3: Er det nødvendigt at normalisere en database til højeste normalform som (BCNF eller 4NF)?

Svar:

Der er ingen sikker nødvendig betingelse for nogen databasenormalisering. Mange gange kan lavere form være tilstrækkelig til specifik ydeevne og enkelhed.