Introduktion till databasnormalisering

Databasnormalisering är en process som används för att organisera en databas i tabeller och kolumner. Huvudidén med detta är att en tabell ska handla om ett specifikt ämne och endast stödämnen som ingår. Ta ett kalkylark med informationen som ett exempel, där informationen innehåller säljare och kunder som har flera syften:

• Identifiera säljare i din organisation
• Lista alla kunder som ditt företag anropar att sälja en produkt
• Identifiera vilka säljare som ringer till specifika kunder.

Genom att begränsa en tabell till ett syfte minskar du antalet dubbletter i din databas. Detta eliminerar vissa problem som härrör från databasändringar.

För att uppnå dessa mål använder vi några etablerade regler. När du tillämpar dessa regler bildas nya tabeller. Progressionen från orolig till optimerad passerar genom flera normala former.

Det finns tre normala former som de flesta databaser följer med. Eftersom tabeller uppfyller varje efterföljande databasnormaliseringsformulär blir de mindre benägna att avvikelser i databasändringar och fokuseras mer mot ett enda syfte eller ämne. Innan vi fortsätter ska du vara säker på att du förstår definitionen av en databastabell.

Anledningar till databasnormalisering

Det finns tre huvudskäl till att normalisera en databas. Den första är att minimera dubblettdata, den andra är att minimera eller undvika problem med datamodifiering, och det tredje är att förenkla frågor.

När vi går igenom olika tillstånd av normalisering kommer vi att diskutera hur varje formulär behandlar dessa problem, men för att börja med, låt oss titta på några data som inte har normaliserats och diskutera några potentiella fallgropar.

Jag tror att när du förstår problemen, uppskattar du bättre normalisering. Tänk på följande tabell:

Det första som ska märkas är att denna tabell tjänar många syften, inklusive:

1. Identifiera organisationens säljare
2. Lista försäljningen kontor och telefonnummer
3. Associera en säljare till ett säljkontor
4. Visa varje säljares kunder

Som DBA lyfter detta en röd flagga. I allmänhet gillar jag att se tabeller som har ett syfte. Att ha bordet tjänar många syften introducerar många av utmaningarna; nämligen dataduplicering, datauppdateringsproblem och ökad ansträngning för att fråga data.

Data duplicering och modifieringsavvikelser

Observera att för varje SalesPerson har vi listat både SalesOffice och OfficeNumber. Det finns dubbletter av säljare. Dubblerad information ger två problem:

1. Det ökar lagring och minskar prestanda.
2. Det blir svårare att upprätthålla dataändringar.

Till exempel:

Överväg om vi flyttar Chicago-kontoret till Evanston, IL. För att korrekt återspegla detta i vår tabell måste vi uppdatera posterna för alla SalesPersons som för närvarande är i Chicago. Vårt bord är ett litet exempel, men du kan se om det var större, att detta potentiellt kan innebära hundratals uppdateringar.

Dessa situationer är modifieringsavvikelser. Databasnormalisering fixar dem. Det finns tre ändringsavvikelser som kan förekomma:

Infoga anomali

Det finns fakta som vi inte kan registrera förrän vi vet information för hela raden. I vårt exempel kan vi inte spela in ett nytt försäljningskontor förrän vi också känner till säljaren. Varför? För att skapa posten behöver vi tillhandahålla en primär nyckel. I vårt fall är detta EmployeeID.

Uppdatera anomali

I det här fallet har vi samma information i flera rader. Till exempel om kontorsnumret ändras finns det flera uppdateringar som måste göras. Om vi inte uppdaterar alla rader visas inkonsekvenser.

Raderingsavvikelse

Radering av en rad orsakar borttagning av mer än en uppsättning fakta. Till exempel, om John Hunt går i pension, kan vi förlora information om New York-kontoret när vi tar bort den raden.

Sök- och sorteringsproblem

Den sista anledningen till att vi överväger är att göra det lättare att söka och sortera dina data. I SalesStaff-tabellen om du vill söka efter en specifik kund som Ford, måste du skriva en fråga som

SELECT SalesOfficeFROM SalesStaffWHERE Customer1 = ‘Ford’ OR Customer2 = ‘Ford’ OR Customer3 = ‘Ford’

Klart om kunden på något sätt i en kolumn skulle vår fråga vara enklare. Tänk också på om du vill köra en fråga och sortera efter kund.

Vår nuvarande tabell gör detta tufft. Du måste använda tre separata UNION-frågor!Du kan eliminera eller minska dessa avvikelser genom att dela in data i olika tabeller. Detta placerar data i tabeller som tjänar ett enda syfte.

Processen för att omforma tabellen är databasnormalisering.

Definition av databasnormalisering

Det finns tre vanliga former av databasnormalisering: 1: a, 2: a och 3: e normalform. De förkortas också som 1NF, 2NF respektive 3NF.

Det finns flera ytterligare former, som BCNF, men jag anser att de är avancerade och inte alltför nödvändiga att lära sig i början.

Formerna är progressiva, vilket innebär att för att kvalificera sig för 3: e normalform måste en tabell först uppfylla reglerna för 2: a normalform, och 2: a normalform måste följa dem för 1: a normalform. Innan vi diskuterar de olika formerna och reglerna i detalj, låt oss sammanfatta de olika formerna:

• First Normal Form – Informationen lagras i en relationstabell med varje kolumn som innehåller atomvärden. Det finns inga upprepande grupper av kolumner.
• Andra normala formen – Tabellen är i första normala formen och alla kolumner beror på tabellens primära nyckel.
• Tredje normala formen – tabellen är i andra normalform och alla dess kolumner är inte beroende av den primära nyckeln

Om reglerna inte ger för mycket mening, oroa dig inte. Jag har länkat till artikeln för att hjälpa dig att förstå dem.

För närvarande är det viktigt att förstå att det finns tre regler för databasnormalisering som gäller varandra. Vissa människor gör att databasnormalisering verkar komplicerad.

men det behöver inte vara, och när du förstår det blir det intuitivt.