SQL Första, andra och tredje normala formulär - dummies

Det finns tre källor till modifieringsavvikelser i SQL Dessa definieras som första, andra och tredje normala former (1NF, 2NF, 3NF). Dessa normala former fungerar som hjälpmedel för modifieringsavvikelser.

Första normala formuläret

För att vara i första normala form (1NF) måste ett bord ha följande egenskaper:

• Tabellen är tvådimensionell med rader och kolumner.

• Varje rad innehåller data som gäller vissa saker eller delar av en sak.

• Varje kolumn innehåller data för ett enda attribut av det som beskrivs.

• Varje cell (skärningspunkten i en rad och en kolumn) i tabellen måste bara ha ett enda värde.

• Inlägg i någon kolumn måste alla vara av samma slag. Om till exempel inmatningen i en rad i en kolumn innehåller ett anställningsnamn måste alla andra rader innehålla anställningsnamn i den kolumnen.

• Varje kolumn måste ha ett unikt namn.

• Inga två rader kan vara identiska (det vill säga varje rad måste vara unik).

• Ordningen på kolumnerna och ordningen i raderna är inte signifikanta.

En tabell (relation) i första normala formen är immun mot vissa slags modifieringsavvikelser men är fortfarande föremål för andra. Försäljningsbordet är i första normala form, och bordet är föremål för radering och införande avvikelser. Första normala formen kan vara användbar i vissa applikationer men otillförlitliga hos andra.

Andra normala formuläret

För att uppskatta andra normala formulär måste du förstå tanken på funktionellt beroende. Ett funktionellt beroende är ett förhållande mellan eller bland attribut. Ett attribut är funktionellt beroende av en annan om värdet av det andra attributet bestämmer värdet på det första attributet. Om du vet värdet på det andra attributet kan du bestämma värdet på det första attributet.

Anta exempelvis att en tabell har attribut (kolumner) StandardCharge, NumberOfTests och TotalCharge som hänför sig till följande ekvation:

TotalCharge = StandardCharge * NumberOfTests

TotalCharge är funktionellt beroende av både StandardCharge och NumberOfTests. Om du känner till värdena för StandardCharge och NumberOfTests kan du bestämma värdet på TotalCharge.

Varje tabell i första normalform måste ha en unik primär nyckel. Den nyckeln kan bestå av en eller flera kolumner. En nyckel som består av mer än en kolumn kallas en kompositnyckel. För att vara i andra normala form (2NF) måste alla icke-nyckelattribut vara beroende av hela nyckeln. Således är varje relation som ligger i 1NF med en enda attributnyckel automatiskt i andra normala form.

Om ett förhållande har en sammansatt nyckel, måste alla icke-nyckelattribut vara beroende av alla komponenter i nyckeln. Om du har ett bord där vissa icke-nyckelattribut inte beror på alla komponenter i nyckeln, bryter du upp tabellen i två eller flera tabeller så att alla icke-nyckelattribut i alla nya tabeller beror på alla komponenter av den primära nyckeln.

Ljud förvirrande? Titta på ett exempel för att klargöra saker. Tänk på försäljnings tabellen. Istället för att bara registrera ett inköp för varje kund lägger du till en rad varje gång en kund köper en vara för första gången. En ytterligare skillnad är att charterkunder (de som har Customer_ID-värden på 1001 till 1007) får rabatt på det normala priset.

Customer_ID identifierar inte en rad unikt. I två rader är Customer_ID 1001. I två andra rader är Customer_ID 1010. Kombinationen av kolonnen Customer_ID och Produkt-kolumnen identifierar en rad. Dessa två kolumner tillsammans är en sammansatt nyckel.

Om inte för det faktum att vissa kunder kvalificerar sig för rabatt och andra inte, skulle tabellen inte vara i andra normala format eftersom priset (en icke-nyckelattribut) bara skulle bero på en del av nyckeln (Produkt). Eftersom vissa kunder kvalificerar sig för rabatt, beror priset på både CustomerID och Product, och tabellen är i andra normala format.

Tredje normal form

Tabeller i andra normala formen är särskilt sårbara för vissa typer av modifieringsavvikelser - i synnerhet de som kommer från transitiva beroenden.

A Transitivt beroende inträffar när ett attribut beror på ett andra attribut, vilket beror på ett tredje attribut. Radering i en tabell med ett sådant beroende kan orsaka oönskade informationsförluster. En relation i tredje normalform är en relation i andra normala form utan transitiva beroenden.

Se igen på försäljningsbordet, vilket du vet är i första normala form. Så länge du begränsar poster för att tillåta endast en rad för varje Customer_ID, har du en primär nyckel med en attribut och tabellen är i andra normala format. Tabellen är emellertid fortfarande föremål för avvikelser. Vad händer om kund 1010 inte är missnöjd med klorbleken, och returnerar föremålet för återbetalning?

Du vill ta bort den tredje raden från bordet, vilket visar att kund 1010 köpte klorblekmedel. Du har ett problem: Om du tar bort den raden, förlorar du också det faktum att klorblek har ett pris på $ 4. Denna situation är ett exempel på ett transitivt beroende. Priset beror på Produkt, vilket i sin tur beror på den primära nyckeln Customer_ID.

Att bryta försäljningsbordet i två tabeller löser problemet med transitivt beroende. De två tabellerna utgör en databas som är i tredje normala form.