Normalisering är processen att minimera redundans från en relation eller en uppsättning relationer. Redundans i relation kan orsaka insättning, radering och uppdateringsavvikelser. Så det hjälper till att minimera redundansen i relationer. Normala former används för att eliminera eller minska redundans i databastabeller.

int i sträng

Normalisering av DBMS av Ranjan Hero

I databashanteringssystem (DBMS) är normala formulär en serie riktlinjer som hjälper till att säkerställa att utformningen av en databas är effektiv, organiserad och fri från dataavvikelser. Det finns flera nivåer av normalisering, var och en med sin egen uppsättning riktlinjer, så kallade normala former.

Viktiga punkter angående normala formulär i DBMS

• Första normala formen (1NF): Detta är den mest grundläggande nivån av normalisering. I 1NF bör varje tabellcell endast innehålla ett enda värde och varje kolumn ska ha ett unikt namn. Den första normala formen hjälper till att eliminera dubbletter av data och förenkla frågor.
• Andra normala formen (2NF): 2NF eliminerar redundanta data genom att kräva att varje icke-nyckelattribut är beroende av primärnyckeln. Det betyder att varje kolumn ska vara direkt relaterad till primärnyckeln och inte till andra kolumner.
• Tredje normalformen (3NF): 3NF bygger på 2NF genom att kräva att alla icke-nyckelattribut är oberoende av varandra. Det betyder att varje kolumn ska vara direkt relaterad till primärnyckeln och inte till några andra kolumner i samma tabell.
• Boyce-Codd normal form (BCNF): BCNF är en striktare form av 3NF som säkerställer att varje determinant i en tabell är en kandidatnyckel. Med andra ord säkerställer BCNF att varje icke-nyckelattribut endast är beroende av kandidatnyckeln.
• Fjärde normalformen (4NF): 4NF är en ytterligare förfining av BCNF som säkerställer att en tabell inte innehåller några beroenden med flera värden.
• Femte normalformen (5NF): 5NF är den högsta nivån av normalisering och innebär att en tabell delas upp i mindre tabeller för att ta bort dataredundans och förbättra dataintegriteten.

Normala formulär hjälper till att minska dataredundans, öka datakonsistensen och förbättra databasprestanda. Men högre nivåer av normalisering kan leda till mer komplexa databasdesigner och frågor. Det är viktigt att hitta en balans mellan normalisering och funktionalitet när man utformar en databas.

Fördelar med normal form

• Minskad dataredundans: Normalisering hjälper till att eliminera dubbletter av data i tabeller, vilket minskar mängden lagringsutrymme som behövs och förbättrar databasens effektivitet.
• Förbättrad datakonsistens: Normalisering säkerställer att data lagras på ett konsekvent och organiserat sätt, vilket minskar risken för datainkonsekvenser och fel.
• Förenklad databasdesign: Normalisering ger riktlinjer för att organisera tabeller och datarelationer, vilket gör det lättare att designa och underhålla en databas.
• Förbättrad frågeprestanda: Normaliserade tabeller är vanligtvis lättare att söka och hämta data från, vilket resulterar i snabbare frågeprestanda.
• Enklare databasunderhåll: Normalisering minskar komplexiteten i en databas genom att dela upp den i mindre, mer hanterbara tabeller, vilket gör det lättare att lägga till, ändra och ta bort data.

Sammantaget hjälper användning av normala formulär i DBMS till att förbättra datakvaliteten, öka databaseffektiviteten och förenkla databasdesign och underhåll.

Första normala formen

Om en relation innehåller sammansatta eller flervärdiga attribut bryter den mot första normalformen eller en relation är i första normalform om den inte innehåller något sammansatt eller flervärdigt attribut. En relation är i första normalform om varje attribut i den relationen är det enskilt värderat attribut .

• Exempel 1 – Relationen STUDENT i tabell 1 finns inte i 1NF på grund av attributet STUD_PHONE med flera värden. Dess sönderdelning till 1NF har visats i tabell 2.

Exempel

• Exempel 2 –

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

• I tabellen ovan är kurs ett attribut med flera värden så det finns inte i 1NF. Tabellen nedan är i 1NF eftersom det inte finns något attribut med flera värden

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

Andra normalformen

För att vara i andra normalform måste en relation vara i första normalform och relation får inte innehålla något partiellt beroende. En relation är i 2NF om den har Inget partiellt beroende, dvs. , inget icke-primärt attribut (attribut som inte är en del av någon kandidatnyckel) är beroende av någon korrekt delmängd av någon kandidatnyckel i tabellen. Partiellt beroende – Om den korrekta delmängden av kandidatnyckeln bestämmer icke-primärt attribut, kallas det partiellt beroende.

• Exempel 1 – Betrakta tabell-3 enligt nedan.

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

• {Observera att det finns många kurser som har samma kursavgift} Här kan COURSE_FEE inte ensamt bestämma värdet på COURSE_NO eller STUD_NO; COURSE_FEE tillsammans med STUD_NO kan inte bestämma värdet på COURSE_NO; COURSE_FEE tillsammans med COURSE_NO kan inte bestämma värdet på STUD_NO; Därför skulle COURSE_FEE vara ett icke-primärt attribut, eftersom det inte tillhör den enda kandidatnyckeln {STUD_NO, COURSE_NO} ; Men, COURSE_NO -> COURSE_FEE, dvs. COURSE_FEE är beroende av COURSE_NO, som är en riktig delmängd av kandidatnyckeln. Icke-primärt attribut COURSE_FEE är beroende av en korrekt delmängd av kandidatnyckeln, vilket är ett partiellt beroende och så denna relation är inte i 2NF. För att konvertera ovanstående relation till 2NF måste vi dela upp tabellen i två tabeller såsom: Tabell 1: STUD_NO, COURSE_NO Tabell 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>

• NOTERA: 2NF försöker minska den redundanta data som lagras i minnet. Till exempel, om det finns 100 elever som tar C1-kurs, behöver vi inte lagra dess avgift som 1000 för alla 100 poster, istället när vi kan lagra den i den andra tabellen eftersom kursavgiften för C1 är 1000.
• Exempel 2 – Överväg att följa funktionella beroenden i relation R (A, B , C, D )

AB ->C [A och B bestämmer tillsammans C] BC -> D [B och C bestämmer tillsammans D]>

I ovanstående relation är AB den enda kandidatnyckeln och det finns inget partiellt beroende, d.v.s. någon korrekt delmängd av AB bestämmer inte något icke-primärt attribut.

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

Exempel 1: I relation STUDENT ges i Tabell 4, FD-uppsättning: {STUD_NO -> STUD_NAME, STUD_NO -> STUD_STATE, STUD_STATE -> STUD_COUNTRY, STUD_NO -> STUD_AGE}

tom lista java

Kandidatnyckel: {STUD_NO}

För denna relation i tabell 4 är STUD_NO -> STUD_STATE och STUD_STATE -> STUD_COUNTRY sanna.

Så STUD_COUNTRY är transitivt beroende av STUD_NO. Det bryter mot den tredje normalformen.

För att konvertera den till tredje normalform kommer vi att dekomponera 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)

Betrakta relation R(A, B, C, D, E) A -> BC, CD -> E, B -> D, E -> A Alla möjliga kandidatnycklar i ovanstående relation är {A, E, CD, BC} Alla attribut är på höger sida av alla funktionella beroenden är prime.

Exempel 2: Hitta den högsta normalformen av en relation R(A,B,C,D,E) med FD satt som {BC->D, AC->BE, B->E}

Steg 1: Som vi kan se, (AC)+ ={A,C,B,E,D} men ingen av dess delmängder kan bestämma alla attribut för relation, så AC kommer att vara kandidatnyckel. A eller C kan inte härledas från något annat attribut i relationen, så det kommer bara att finnas en kandidatnyckel {AC}.

java swing

Steg 2: Primära attribut är de attribut som är en del av kandidatnyckeln {A, C} i detta exempel och andra kommer att vara icke-primära {B, D, E} i det här exemplet.

Steg 3: Relationen R är i 1:a normalform eftersom ett relationellt DBMS inte tillåter flervärdiga eller sammansatta attribut. Relationen är i 2:a normalform eftersom BC->D är i 2:a normalform (BC är inte en riktig delmängd av kandidatnyckel AC) och AC->BE är i 2:a normalform (AC är kandidatnyckel) och B->E är i 2:a normalform (B är inte en riktig delmängd av kandidatnyckel AC).

Relationen är inte i 3:e normalform eftersom i BC->D (varken BC är en supernyckel eller D är ett primärt attribut) och i B->E (varken B är en supernyckel eller E är ett primattribut) utan till tillfredsställ 3:e normalen för antingen LHS i en FD ska vara supernyckel eller RHS ska vara prime attribut. Så den högsta normala formen av relation kommer att vara 2:a normalformen.

Tänk till exempel på relation R(A, B, C) A -> BC, B -> A och B båda är supernycklar så ovanstående relation är i BCNF.

Tredje normalformen

En relation sägs vara i tredje normalform, om vi inte hade något transitivt beroende för icke-primära attribut. Grundvillkoret med den tredje normalformen är att relationen måste vara i den andra normalformen.

Nedan nämns det grundläggande villkoret som måste gälla i det icke-triviala funktionella beroendet X -> Y:

• X är en supernyckel.
• Y är ett primärt attribut (det betyder att elementet i Y är någon del av kandidatnyckeln).

För mer, se Tredje normalformen i DBMS.

BCNF

BCNF (Boyce-Codd Normal Form) är bara en avancerad version av Third Normal Form. Här har vi några ytterligare regler än Third Normal Form. Grundvillkoret för att varje relation ska finnas i BCNF är att den måste vara i tredje normalform.

strängbyggare java

Vi måste fokusera på några grundläggande regler som gäller för BCNF:

1. Table must be in Third Normal Form. 2. In relation X->Y, X måste vara en supernyckel i en relation.>

För mer, se BCNF i DBMS.

Fjärde normalformen

Fjärde normalformen innehåller inget icke-trivialt multivaued-beroende förutom kandidatnyckel. Grundvillkoret med fjärde normalformen är att relationen måste vara i BCNF.

De grundläggande reglerna nämns nedan.

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

För mer, se Fjärde normalformen i DBMS.

Femte normalformen

Femte normalformen kallas också för projicerad normalform. De grundläggande villkoren för femte normalformen nämns nedan.

Ersätt alla

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

För mer, se Femte normalformen i DBMS.

Tillämpningar av normala former i DBMS

• Datakonsistens: Normala formulär säkerställer att data är konsekventa och inte innehåller någon redundant information. Detta hjälper till att förhindra inkonsekvenser och fel i databasen.
• Dataredundans: Normala formulär minimerar dataredundans genom att organisera data i tabeller som bara innehåller unika data. Detta minskar mängden lagringsutrymme som krävs för databasen och gör den lättare att hantera.
• Respons tid: Normala formulär kan förbättra frågeprestanda genom att minska antalet kopplingar som krävs för att hämta data. Detta hjälper till att påskynda frågebehandlingen och förbättra systemets övergripande prestanda.
• Databasunderhåll: Normala formulär gör det lättare att underhålla databasen genom att minska mängden redundant data som behöver uppdateras, raderas eller modifieras. Detta hjälper till att förbättra databashanteringen och minska risken för fel eller inkonsekvenser.
• Databasdesign: Normala formulär ger riktlinjer för att utforma databaser som är effektiva, flexibla och skalbara. Detta hjälper till att säkerställa att databasen enkelt kan ändras, uppdateras eller utökas efter behov.

Några viktiga punkter om normala former

• BCNF är fri från redundans orsakad av funktionella beroenden.
• Om en relation finns i BCNF är 3NF också uppfylld.
• Om alla attribut för relation är primattribut, så är relationen alltid i 3NF.
• En relation i en relationsdatabas är alltid och åtminstone i 1NF-form.
• Varje binär relation (en relation med endast 2 attribut) är alltid i BCNF.
• Om en relation endast har singelkandidatnycklar (dvs varje kandidatnyckel består av endast 1 attribut), så är relationen alltid i 2NF (eftersom inget partiellt funktionellt beroende är möjligt).
• Att gå på BCNF-form kan ibland inte bevara funktionellt beroende. Gå i så fall bara till BCNF om den/de förlorade FD:erna inte krävs, annars normalisera bara till 3NF.
• Det finns många fler normala former som finns efter BCNF, som 4NF och mer. Men i verkliga databassystem är det i allmänhet inte nödvändigt att gå längre än BCNF.

Slutsats

Sammanfattningsvis kan relationsdatabaser ordnas enligt en uppsättning regler som kallas normala former i databas administrering (1NF, 2NF, 3NF, BCNF, 4NF och 5NF), vilket minskar dataredundans och bevarar dataintegriteten. Genom att lösa olika typer av dataavvikelser och beroenden expanderar varje efterföljande normalform till den som kom före den. De särskilda kraven och egenskaperna hos de data som lagras avgör vilken normalform som ska användas; högre normala former erbjuder strängare dataintegritet men kan också resultera i mer komplicerade databasstrukturer.

Föregående år Frågelänkar

• GATE CS 2012, fråga 2
• GATE CS 2013, fråga 54
• GATE CS 2013, fråga 55
• GATE CS 2005, fråga 29
• GATE CS 2002, fråga 23
• GATE CS 2002, fråga 50
• GATE CS 2001, fråga 48
• GATE CS 1999, fråga 32
• GATE IT 2005, fråga 22
• GATE IT 2008, fråga 60
• GATE CS 2016 (uppsättning 1), fråga 31

Vanliga frågor på normal form

F.1: Varför är normalisering viktigt i DBMS?

Svar:

Normalisering hjälper till att förhindra databaser från anomalier, vilket i slutändan säkerställer databasens konsistens och hjälper till att enkelt underhålla databasen.

F.2: Är det möjligt att övernormalisera databasen?

Svar:

Ja, överdriven normalisering kommer att gå till komplexa frågor och minskar också prestandan. Det skapar en balans mellan normering och praktiska egenskaper.

F.3: Är det nödvändigt att normalisera en databas till högsta normala form som (BCNF eller 4NF)?

Svar:

Det finns ingen säker nödvändig förutsättning för någon databasnormalisering. Många gånger kan lägre form vara tillräckligt för specifik prestanda och enkelhet.