Databas Normalisering Handledning: 1NF 2NF 3NF BCNF Exempel

database normalization tutorial

Denna handledning kommer att förklara vad som är databasnormalisering och olika normala former som 1NF 2NF 3NF och BCNF med exempel på SQL-kod:

Databasnormalisering är en välkänd teknik som används för att utforma databasschema.

Huvudsyftet med att använda normaliseringstekniken är att minska redundansen och beroendet av data. Normalisering hjälper oss att dela upp stora tabeller i flera små tabeller genom att definiera en logisk relation mellan dessa tabeller.

Vad du kommer att lära dig:

• Vad är databasnormalisering?
  • Fördelar med DBMS-normalisering
  • Nackdelar med databasnormalisering
  • Typer av normala former
    • # 1) 1NF (första normala form)
    • # 2) 2NF (andra normala form)
    • # 3) 3NF (tredje normala form)
    • # 4) Boyce-Codd Normal Form (3,5 Normal Form)
    • # 5) Fjärde normalform (4 normalform)
    • # 6) Femte normalform (5 normalform)
  • Vanliga frågor och svar
• Slutsats
  • Rekommenderad läsning

Vad är databasnormalisering?

Databasnormalisering eller SQL-normalisering hjälper oss att gruppera relaterade data i en enda tabell. Alla attributdata eller indirekt relaterade data placeras i olika tabeller och dessa tabeller är kopplade till ett logiskt förhållande mellan föräldra- och underordnade tabeller.

1970 kom Edgar F. Codd med begreppet normalisering. Han delade en uppsats med namnet 'En relationsmodell för data för stora delade banker' där han föreslog 'First Normal Form (1NF)'.

Fördelar med DBMS-normalisering

Databasnormalisering ger följande grundläggande fördelar:

1. Normalisering ökar datakonsistensen eftersom det undviker dataduplicitet genom att endast lagra data på ett ställe.
2. Normalisering hjälper till att gruppera liknande eller relaterade data under samma schema, vilket resulterar i en bättre gruppering av data.
3. Normalisering förbättrar sökningen snabbare eftersom index kan skapas snabbare. Därför används den normaliserade databasen eller tabellen för OLTP (Online Transaction Processing).

Nackdelar med databasnormalisering

DBMS-normalisering har följande nackdelar:

1. Vi kan inte hitta tillhörande data för exempelvis en produkt eller anställd på ett ställe och vi måste gå med i mer än en tabell. Detta orsakar en fördröjning när data hämtas.
2. Normalisering är alltså inte ett bra alternativ i OLAP-transaktioner (Online Analytical Processing).

Innan vi går vidare ska vi förstå följande termer:

• Entitet: Enhet är ett verkligt objekt där data som är associerade med ett sådant objekt lagras i tabellen. Exemplet på sådana objekt är anställda, avdelningar, studenter etc.
• Attribut: Attribut är enhetens egenskaper som ger viss information om enheten. Till exempel, om tabeller är enheter är kolumnerna deras attribut.

Typer av normala former

# 1) 1NF (första normala form)

Per definition kan en enhet som inte har några upprepande kolumner eller datagrupper kallas First First Form. I det första normala formuläret är varje kolumn unik.

Följande är hur våra anställda och avdelningstabell skulle ha sett ut i första normala form (1NF):

Här har alla kolumner i både anställda och avdelningstabeller klubbats i en och det finns inget behov av att ansluta kolumner, som deptNum, eftersom all data finns på ett ställe.

Men en tabell som denna med alla nödvändiga kolumner i den skulle inte bara vara svår att hantera utan också svår att utföra operationer på och även ineffektiv ur lagringssynpunkt.

# 2) 2NF (andra normala form)

Per definition definieras en enhet som är 1NF och en av dess attribut som den primära nyckeln och de återstående attributen är beroende av den primära nyckeln.

Följande är ett exempel på hur anställda och avdelningstabell skulle se ut:

Anställdas tabell:

Avdelningstabell:

EmpDept-tabell:

Här kan vi observera att vi har delat tabellen i 1NF-form i tre olika tabeller. tabellen Anställda är en enhet om alla anställda i ett företag och dess attribut beskriver varje anställds egenskaper. Den primära nyckeln för denna tabell är empNum.

På samma sätt är tabellen avdelningar en enhet om alla avdelningar i ett företag och dess attribut beskriver varje avdelnings egenskaper. Den primära nyckeln för denna tabell är deptNum.

I den tredje tabellen har vi kombinerat huvudtangenterna för båda tabellerna. De primära nycklarna i tabellerna Anställda och avdelningar kallas utländska nycklar i denna tredje tabell.

Om användaren vill ha en utdata som liknar den, hade vi i 1NF, då måste användaren gå med i alla de tre tabellerna med de primära tangenterna.

Ett exempel på en fråga skulle se ut som visas nedan:

# 3) 3NF (tredje normala form)

Per definition betraktas en tabell som tredje normal om tabellen / entiteten redan är i den andra normala formen och kolumnerna i tabellen / entiteten inte är beroende av den primära nyckeln.

Låt oss förstå icke-transitivt beroende med hjälp av följande exempel.

Säg en tabell med namnet, Kunden har nedanstående kolumner:

Kundnummer - Primär nyckel som identifierar en unik kund
CustomerZIP - Postnummer för den lokala kunden är bosatt i
CustomerCity - Stad kunden bor i

I ovanstående fall är CustomerCity-kolumnen beroende av CustomerZIP-kolumnen och CustomerZIP-kolumnen är beroende av CustomerID.

Ovanstående scenario kallas övergående beroende av kolumnen CustomerCity på CustomerID, dvs. den primära nyckeln. Efter att ha förstått övergående beroende, låt oss nu diskutera problemet med detta beroende.

Det kan finnas ett möjligt scenario där en oönskad uppdatering görs i tabellen för att uppdatera CustomerZIP till ett postnummer från en annan stad utan att uppdatera CustomerCity och därmed lämna databasen i ett inkonsekvent tillstånd.

För att åtgärda problemet måste vi ta bort det övergående beroendet som kan göras genom att skapa en annan tabell, till exempel CustZIP-tabellen som innehåller två kolumner, dvs CustomerZIP (som primär nyckel) och CustomerCity.

CustomerZIP-kolumnen i kundtabellen är en främmande nyckel till CustomerZIP i CustZIP-tabellen. Denna relation säkerställer att det inte finns någon avvikelse i uppdateringarna där en CustomerZIP uppdateras utan att göra ändringar i CustomerCity.

# 4) Boyce-Codd Normal Form (3,5 Normal Form)

Per definition anses tabellen Boyce-Codd normalform, om den redan finns i den tredje normala formen och för varje funktionellt beroende mellan A och B bör A vara en supernyckel.

Denna definition låter lite komplicerad. Låt oss försöka bryta det för att förstå det bättre.

• Funktionellt beroende: Attributen eller kolumnerna i en tabell sägs vara funktionellt beroende när ett attribut eller kolumn i en tabell unikt identifierar ett annat attribut eller kolumner i samma tabell.
  Till exempel, kolumnen empNum eller anställd nummer identifierar unikt de andra kolumnerna som anställds namn, anställdes lön etc. i tabellen Anställd.
• Super Key: En enda nyckel eller grupp med flera nycklar som unikt kan identifiera en enda rad i en tabell kan betecknas som Super Key. Generellt sett känner vi till sådana tangenter som Composite Keys.

Låt oss överväga följande scenario för att förstå när det finns ett problem med Third Normal Form och hur kommer Boyce-Codd Normal Form att rädda.

I exemplet ovan arbetar anställda med empNum 1001 och 1007 i två olika avdelningar. Varje avdelning har en avdelningschef. Det kan finnas flera avdelningschefer för varje avdelning. Precis som för avdelningen för konton är Raymond och Samara de två avdelningscheferna.

I det här fallet är empNum och deptName supernycklar, vilket innebär att deptName är ett primärt attribut. Baserat på dessa två kolumner kan vi identifiera varje enskild rad unikt.

DeptName beror också på deptHead, vilket innebär att deptHead är ett icke-primärt attribut. Detta kriterium diskvalificerar tabellen från att vara en del av BCNF.

För att lösa detta delar vi upp tabellen i tre olika tabeller som nämns nedan:

Anställdas tabell:

Avdelningstabell:

# 5) Fjärde normalform (4 normalform)

Per definition finns en tabell i fjärde normalform, om den inte har två eller flera oberoende data som beskriver den relevanta enheten.

# 6) Femte normalform (5 normalform)

En tabell kan endast övervägas i femte normala formen om den uppfyller villkoren för fjärde normalform och kan delas upp i flera tabeller utan förlust av data.

Vanliga frågor och svar

F # 1) Vad är normalisering i en databas?

Svar: Databas Normalisering är en designteknik. Med hjälp av detta kan vi utforma eller omforma scheman i databasen för att minska överflödig data och beroendet av data genom att dela upp data i mindre och mer relevanta tabeller.

F # 2) Vilka är de olika typerna av normalisering?

Svar: Nedan följer de olika typerna av normaliseringstekniker som kan användas för att utforma databasscheman:

• Första normala formen (1NF)
• Andra normala formen (2NF)
• Tredje normala formen (3NF)
• Boyce-Codd Normal Form (3.5NF)
• Fjärde normalform (4NF)
• Femte normalform (5NF)

F # 3) Vad är syftet med normalisering?

Svar: Det primära syftet med normaliseringen är att minska dataredundansen, dvs. data ska bara lagras en gång. Detta för att undvika eventuella dataavvikelser som kan uppstå när vi försöker lagra samma data i två olika tabeller, men ändringar tillämpas endast på den ena och inte på den andra.

F # 4) Vad är denormalisering?

Svar: Denormalisering är en teknik för att öka databasens prestanda. Denna teknik lägger till överflödig data i databasen, i motsats till den normaliserade databasen som tar bort redundansen för data.

Detta görs i stora databaser där det är en dyr affär att köra en JOIN för att få data från flera tabeller. Således lagras redundanta data i flera tabeller för att undvika JOIN-operationer.

Slutsats

Hittills har vi alla gått igenom tre databasnormaliseringsformulär.

intervjufrågor och svar för affärsanalytiker

Teoretiskt sett finns det högre former av databasnormaliseringar som Boyce-Codd Normal Form, 4NF, 5NF. 3NF är dock den allmänt använda normaliseringsformen i produktionsdatabaserna.

Glad läsning!!

Rekommenderad läsning

• Databastestning med JMeter
• MongoDB Skapa säkerhetskopia av databas
• MongoDB Skapa databashandledning
• Topp 10 databasdesignverktyg för att bygga komplexa datamodeller
• MongoDB-prestanda: Låsning av prestanda, sidfel och databasprofilering
• Altibase Open Source Relational Database Review
• MongoDB databasprofil för övervakning av frågor och prestanda
• Hur man testar Oracle Database