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

Normalisering i ett nötskal

Normalisering är processen att strukturera en databas för att minska redundans och förbättra konsistens. Enkelt uttryckt delar den upp stora, röriga tabeller i mindre, välorganiserade tabeller. Detta säkerställer att data lagras logiskt, vilket gör databaser effektiva, enkla att underhålla och fria från dubbelarbete eller fel.

Vad är databasnormalisering?

Databas Normalisering är en databasdesignteknik som minskar dataredundans och eliminerar oönskade egenskaper som infogning, uppdatering och raderingsavvikelser. Normaliseringsregler delar in större tabeller i mindre tabeller och länkar dem med hjälp av relationer. Syftet med normalisering i SQL är att eliminera redundanta (repetitiva) data och säkerställa att data lagras logiskt.

Uppfinnaren av relationsmodell Edgar Codd föreslog teorin om normalisering av data med införandet av den första normala formen, och han fortsatte att utöka teorin med den andra och tredje normalformen. Later han gick med Raymond F. Boyce för att utveckla teorin om Boyce-Codds normala form.

Varför behöver vi normalisering?

Utan normalisering blir databaser snabbt inkonsekventa och redundanta. Problem som insättningsanomalier (ofullständiga poster kan inte läggas till), uppdatera avvikelser (förändringar på ett ställe återspeglas inte överallt), och raderingsavvikelser (om man av misstag tar bort data raderas värdefull information) förekommer ofta. Normalisering eliminerar dessa problem, vilket säkerställer dataintegritet, minskar dubbelarbete och förenklar databashanteringen.

Vilka typer av normalformer finns i DBMS?

Här är en lista över normala former i SQL:

• 1NF (första normala formen): Säkerställer att databastabellen är organiserad så att varje kolumn innehåller atomära (odelbara) värden, och varje post är unik. Detta eliminerar återkommande grupper och strukturerar därigenom data i tabeller och kolumner.
• 2NF (andra normalformen): Bygger på 1NF av Vi måste ta bort redundanta data från en tabell som appliceras på flera rader. och placera dem i separata tabeller. Det kräver att alla icke-nyckelattribut är fullt fungerande på primärnyckeln.
• 3NF (tredje normalformen): Utökar 2NF genom att säkerställa att alla icke-nyckelattribut inte bara är fullt funktionella på primärnyckeln utan också oberoende av varandra. Detta eliminerar transitivt beroende.
• BCNF (Boyce-Codd Normal Form): En förfining av 3NF som åtgärdar anomalier som inte hanteras av 3NF. Det kräver att varje bestämningsfaktor är en kandidatnyckel, vilket säkerställer en ännu strängare efterlevnad av normaliseringsreglerna.
• 4NF (fjärde normalformen): Adresserar beroenden med flera värden. Det säkerställer att det inte finns flera oberoende fakta med flera värden om en enhet i en post.
• 5NF (femte normalformen): Även känd som "Projection-Join Normal Form" (PJNF), det avser rekonstruktion av information från mindre, annorlunda ordnade datastycken.
• 6NF (sjätte normalformen): Teoretisk och inte allmänt implementerad. Den hanterar tidsdata (hanterar förändringar över tid) genom att ytterligare sönderdela tabeller för att eliminera all icke-temporell redundans.

Teorin om datanormalisering i MySQL servern utvecklas fortfarande. Till exempel finns det diskussioner även den 6^th Normal form. Men i de flesta praktiska tillämpningar når normalisering sitt bästa i 3^rd Normal form. Utvecklingen av normalisering i SQL-teorier illustreras nedan-

Databasnormalisering med exempel

Databas Normaliseringsexempel kan lätt förstås med hjälp av en fallstudie. Anta att ett videobibliotek upprätthåller en databas över uthyrda filmer. Utan normalisering i databasen lagras all information i en tabell som visas nedan. Låt oss förstå normaliseringsdatabas med normaliseringsexempel med lösning:

Här ser du Hyrda filmer-kolumnen har flera värden. Låt oss nu gå över till 1:a normala formulär:

Första normala formen (1NF)

• Varje tabellcell ska innehålla ett enda värde.
• Varje skiva måste vara unik.

Tabellen ovan i 1NF-

1NF Exempel

Innan vi fortsätter låt oss förstå några saker -

Vad är en KEY i SQL

A KEY i SQL är ett värde som används för att identifiera poster i en tabell unikt. En SQL-NYCKEL är en enda kolumn eller kombination av flera kolumner som används för att unikt identifiera rader eller tupler i tabellen. SQL Key används för att identifiera dubblettinformation, och det hjälper också till att upprätta en relation mellan flera tabeller i databasen.

Obs: Kolumner i en tabell som INTE används för att identifiera en post unikt kallas icke-nyckelkolumner.

Vad är en primärnyckel?

En primär är ett enstaka kolumnvärde som används för att identifiera en databaspost unikt.

Den har följande attribut

• A primär nyckel kan inte vara NULL
• Ett primärnyckelvärde måste vara unikt
• De primära nyckelvärdena bör sällan ändras
• Primärnyckeln måste ges ett värde när en ny post infogas.

Vad är Composite Key?

En sammansatt nyckel är en primärnyckel som består av flera kolumner som används för att identifiera en post unikt

I vår databas har vi två personer med samma namn Robert Phil, men de bor på olika platser.

Därför kräver vi både fullständigt namn och adress för att identifiera en post unikt. Det är en sammansatt nyckel.

Låt oss gå in i den andra normala formen 2NF

Andra normala formen (2NF)

• Regel 1- Var i 1NF
• Regel 2 - Enkolumns primärnyckel som inte är funktionellt beroende av någon delmängd av kandidatnyckelrelationen

Det är tydligt att vi inte kan gå vidare för att göra vår enkla databas i 2^nd Normaliseringsform om vi inte delar upp tabellen ovan.

Vi har delat upp vårt 1NF-bord i två tabeller, dvs. Tabell 1 och Tabell 2. Tabell 1 innehåller medlemsinformation. Tabell 2 innehåller information om hyrda filmer.

Vi har introducerat en ny kolumn som heter Membership_id som är den primära nyckeln för tabell 1. Poster kan identifieras unikt i Tabell 1 med hjälp av medlems-id

Databas – främmande nyckel

I tabell 2 är Membership_ID den främmande nyckeln

Utländsk nyckel refererar till primärnyckeln för en annan tabell! Det hjälper till att koppla ihop dina tabeller

• En främmande nyckel kan ha ett annat namn än dess primärnyckel
• Det säkerställer att rader i en tabell har motsvarande rader i en annan
• Till skillnad från den primära nyckeln behöver de inte vara unika. Oftast är de inte det
• Främmande nycklar kan vara null även om primärnycklar inte kan

Varför behöver du en främmande nyckel?

Antag att en nybörjare infogar en post i tabell B som t.ex

Du kommer bara att kunna infoga värden i din främmande nyckel som finns i den unika nyckeln i den överordnade tabellen. Detta hjälper till med referensintegritet.

Ovanstående problem kan övervinnas genom att deklarera medlems-id från Tabell2 som främmande nyckel för medlems-ID från Tabell1

Nu, om någon försöker infoga ett värde i medlems-id-fältet som inte finns i den överordnade tabellen, kommer ett fel att visas!

Vad är transitiva funktionella beroenden?

En transitiv funktionellt beroende är när du ändrar en icke-nyckelkolumn, kan orsaka att någon av de andra icke-nyckelkolumnerna ändras

Tänk på tabellen 1. Om du ändrar kolumnen utan nyckel Fullständigt namn kan hälsningen ändras.

Låt oss gå in i 3NF

Tredje normala formen (3NF)

• Regel 1- Var i 2NF
• Regel 2- Har inga transitiva funktionella beroenden

För att flytta vårt 2NF-bord till 3NF måste vi återigen dela upp vårt bord.

3NF Exempel

Nedan är ett 3NF-exempel i SQL-databas:

Vi har återigen delat upp våra bord och skapat ett nytt bord som lagrar hälsningar.

Det finns inga transitiva funktionella beroenden, och därför är vår tabell i 3NF

I tabell 3 är hälsnings-ID primärnyckel, och i tabell 1 är hälsnings-ID främmande för primärnyckeln i tabell 3

Nu är vårt lilla exempel på en nivå som inte kan dekomponeras ytterligare för att uppnå högre normala former av normalisering i DBMS. I själva verket är det redan i högre normaliseringsformer. Separata ansträngningar för att gå till nästa nivå av normalisering av data behövs normalt i komplexa databaser. Men vi kommer att diskutera nästa nivåer av normalisering i DBMS i korthet i det följande.

Boyce-Codd normal form (BCNF)

Även när en databas finns i 3^rd Normal form, fortfarande skulle det uppstå anomalier om den har mer än en Kandidat Nyckel.

Ibland kallas BCNF också 3.5 Normalform.

Fjärde normalform (4NF)

Om ingen databastabellinstans innehåller två eller flera, oberoende och flervärdesdata som beskriver den relevanta enheten, är den i 4^th Normal form.

Femte normalform (5NF)

En tabell är i 5^th Normal form endast om den är i 4NF och den inte kan dekomponeras i ett antal mindre tabeller utan dataförlust.

Sjätte normalformen (6NF) Föreslagen

6^th Normal Form är inte standardiserad, men den har dock diskuterats av databasexperter under en tid. Förhoppningsvis skulle vi ha en tydlig och standardiserad definition för 6^th Normal form inom en snar framtid...

Vilka är fördelarna med normalisering?

• Förbättra datakonsistens: Normalisering säkerställer att varje databit bara lagras på ett ställe, vilket minskar risken för inkonsekventa data. När data uppdateras behöver den bara uppdateras på ett ställe, vilket säkerställer konsekvens.
• Minska dataredundans: Normalisering hjälper till att eliminera dubbletter av data genom att dela upp dem i flera relaterade tabeller. Detta kan spara lagringsutrymme och även göra databasen mer effektiv.
• Förbättra frågeprestanda: Normaliserade databaser är ofta lättare att söka efter. Eftersom data är logiskt organiserade kan frågor optimeras för att köras snabbare.
• Gör data mer meningsfulla: Normalisering innebär groupping data på ett sätt som är begripligt och intuitivt. Detta kan göra databasen lättare att förstå och använda, särskilt för personer som inte designat databasen.
• Minska risken för anomalier: Avvikelser är problem som kan uppstå när man lägger till, uppdaterar eller tar bort data. Normalisering kan minska risken för dessa anomalier genom att säkerställa att data är logiskt organiserade.

Vilka är nackdelarna med normalisering?

• Ökad komplexitet: Normalisering kan leda till komplexa relationer. Ett stort antal tabeller med främmande nycklar kan vara svåra att hantera, vilket leder till förvirring.
• Minskad flexibilitet: På grund av de strikta reglerna för normalisering kan det finnas mindre flexibilitet när det gäller att lagra data som inte följer dessa regler.
• Ökade lagringskrav: Medan normalisering minskar redundans, kan det vara nödvändigt att tilldela mer lagringsutrymme för att rymma de ytterligare tabellerna och indexen.
• Prestandaoverhead: Att slå samman flera bord kan vara kostsamt när det gäller prestanda. Ju mer normaliserad data är, desto fler kopplingar behövs, vilket kan sakta ner tiderna för datahämtning.
• Förlust av datakontext: Normalisering bryter ner data i separata tabeller, vilket kan leda till att affärskontexten försvinner. Att undersöka relaterade tabeller är nödvändigt för att förstå sammanhanget för en databit.
• Behov av expertkunskap: Att implementera en normaliserad databas kräver en djup förståelse av data, relationerna mellan data och normaliseringsreglerna. Detta kräver expertkunskap och kan vara tidskrävande.

Det är allt till SQL-normalisering!!!

Vanliga frågor

Sammanfattning