Beskrivning av grunderna i databasnormalisering
I den här artikeln förklaras terminologin för databasnormalisering för nybörjare. En grundläggande förståelse av den här terminologin är användbar när du diskuterar utformningen av en relationsdatabas.
Beskrivning av normaliseringen
Normalisering är processen med att ordna data i en databas. Det omfattar att skapa tabeller och upprätta relationer mellan dessa tabeller enligt regler som utformats både för att skydda data och för att göra databasen mer flexibel genom att eliminera redundans och inkonsekvent beroende.
Redundanta data slösar på diskutrymme och skapar underhållsproblem. Om data som finns på mer än en plats måste ändras måste data ändras på exakt samma sätt på alla platser. En ändring av kundadresser är enklare att implementera om dessa data endast lagras i tabellen Kunder och ingen annanstans i databasen.
Vad är ett "inkonsekvent beroende"? Även om det är intuitivt för en användare att leta efter adressen till en viss kund i tabellen Kunder kanske det inte är meningsfullt att leta efter lönen för den medarbetare som ringer till kunden. Den anställdes lön är relaterad till, eller beroende av, den anställda och bör därför flyttas till tabellen Anställda. Inkonsekventa beroenden kan göra data svåra att komma åt eftersom sökvägen för att hitta data kan saknas eller vara trasig.
Det finns några regler för databasnormalisering. Varje regel kallas för ett "normalt formulär". Om den första regeln observeras sägs databasen vara i "första normala formen". Om de tre första reglerna observeras anses databasen vara i "tredje normal form". Även om andra nivåer av normalisering är möjliga anses den tredje normala formen vara den högsta nivån som krävs för de flesta program.
Precis som med många formella regler och specifikationer tillåter verkliga scenarier inte alltid perfekt efterlevnad. Normalisering kräver i allmänhet ytterligare tabeller och vissa kunder tycker att detta är besvärligt. Om du bestämmer dig för att bryta mot någon av de tre första normaliseringsreglerna ska du se till att programmet förutser eventuella problem som kan uppstå, till exempel redundanta data och inkonsekventa beroenden.
Följande beskrivningar innehåller exempel.
Den första normalformen
- Ta bort grupper som upprepas i enskilda tabeller.
- Skapa en separat tabell för varje uppsättning relaterade data.
- Identifiera varje uppsättning relaterade data med en primärnyckel.
Använd inte flera fält i en enda tabell för att lagra liknande data. Om du till exempel vill spåra en lagerartikel som kan komma från två möjliga källor kan en lagerpost innehålla fält för Leverantörskod 1 och Leverantörskod 2.
Vad händer när du lägger till en tredje leverantör? Att lägga till ett fält är inte svaret. det kräver program- och tabelländringar och rymmer inte ett dynamiskt antal leverantörer på ett smidigt sätt. Placera i stället all leverantörsinformation i en separat tabell med namnet Leverantörer och länka sedan lagret till leverantörer med en artikelnummernyckel eller leverantörer till lager med en leverantörskodnyckel.
Den andra normalformen
- Skapa separata tabeller för uppsättningar med värden som gäller för flera poster.
- Relatera dessa tabeller med en främmande nyckel.
Poster bör inte vara beroende av något annat än en tabells primärnyckel (en sammansatt nyckel om det behövs). Tänk till exempel på en kunds adress i ett redovisningssystem. Adressen krävs i tabellen Kunder, men även av tabellerna Order, Leverans, Fakturor, Kundreskontra och Samlingar. I stället för att lagra kundens adress som en separat post i var och en av dessa tabeller kan du lagra den på ett ställe, antingen i tabellen Kunder eller i en separat Adresstabell.
Den tredje normalformen
- Ta bort fält som inte är beroende av nyckeln.
Värden i en post som inte ingår i postens nyckel hör inte hemma i tabellen. När innehållet i en grupp med fält kan gälla för fler än en post i tabellen kan det generellt sett vara bra att placera dessa fält i en separat tabell.
En kandidats universitetsnamn och adress kan till exempel inkluderas i tabellen Rekrytering av anställda. Men du behöver en fullständig lista över universitet för grupputskick. Om universitetsinformation lagras i tabellen Kandidater finns det inget sätt att lista universitet med inga aktuella kandidater. Skapa en separat Universitetstabell och länka den till tabellen Kandidater med en kodnyckel för universitet.
UNDANTAG: Att följa den tredje normala formen, även om det teoretiskt sett är önskvärt, är inte alltid praktiskt. Om du har tabellen Kunder och du vill ta bort alla möjliga beroenden mellan olika platser, måste du skapa separata tabeller för städer, postnummer, säljrepresentanter, kundklasser och alla andra faktorer som kan dupliceras i flera poster. I teorin är normalisering värt att följa. Många små tabeller kan emellertid försämra prestanda eller överskrida kapaciteterna för öppen fil och minne.
Det kan vara mer praktiskt att bara tillämpa den tredje normalformen på data som ändras ofta. Om vissa beroende fält finns kvar designar du programmet så att användaren måste verifiera alla relaterade fält när något ändras.
Andra normaliseringsformer
Den fjärde normala formen, även kallad Boyce-Codd Normal Form (BCNF), och femte normal form finns, men anses sällan i praktisk design. Om du bortser från dessa regler kan det resultera i mindre än perfekt databasdesign, men bör inte påverka funktionaliteten.
Normalisera en exempeltabell
De här stegen visar hur du normaliserar en fiktiv studenttabell.
Icke-normaliserad tabell:
Elev # Rådgivare Rådgivningsrum Klass 1 Klass 2 Klass 3 1022 Jones 412 101-07 143-01 159-02 4123 Smith 216 101-07 143-01 179-04 Första normalformen: inga upprepade grupper
Tabeller bör bara ha två dimensioner. Eftersom en elev har flera klasser ska de här klasserna anges i en separat tabell. Fälten Klass 1, Klass 2 och Klass 3 i posterna ovan är indikationer på designproblem.
Kalkylblad använder ofta den tredje dimensionen, men tabeller bör inte göra det. Ett annat sätt att se på det här problemet är med en en-till-många-relation, placera inte den ena sidan och de många sidorna i samma tabell. Skapa i stället en annan tabell i första normala format genom att eliminera den upprepande gruppen (Class#), som du ser i följande exempel:
Elev # Rådgivare Rådgivningsrum Klass # 1022 Jones 412 101-07 1022 Jones 412 143-01 1022 Jones 412 159-02 4123 Smith 216 101-07 4123 Smith 216 143-01 4123 Smith 216 179-04 Den andra normalformen: eliminera redundanta data
Observera flera Class#- värden för varje Student#- värde i tabellen ovan. Class# är inte funktionellt beroende av Student# (primär nyckel), så den här relationen är inte i andra normala form.
Följande tabeller visar den andra normalformen:
Studenter:
Elev # Rådgivare Rådgivningsrum 1022 Jones 412 4123 Smith 216 Registrering:
Elev # Klass # 1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04 Tredje normalformen: eliminera data som inte är beroende av nyckeln
I det sista exemplet är Rådgivningsrummet (rådgivarens kontorsnummer) funktionellt beroende av attributet Rådgivare. Lösningen är att flytta attributet från tabellen Studenter till tabellen Fakultet, enligt nedan:
Studenter:
Elev # Rådgivare 1022 Jones 4123 Smith Fakultet:
Namn Rum Avdelning Jones 412 42 Smith 216 42
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för