Och abnorm form - dummies

Efter att en SQL-databas finns i tredje normala form har du eliminerat de flesta men inte alla chanser att ändra anomalier. Normala former utöver den tredje definieras för att squash de få kvarvarande buggarna.

Domännyckel normal form (DK / NF)

Boyce-Codd normal form (BCNF), fjärde normal form (4NF) och femte normal form (5NF) är exempel på sådana former. Varje formulär eliminerar en eventuell modifieringsanomali men garanterar inte förebyggande av alla möjliga modifieringsanomalier. Domännyckelens normala form ger dock en sådan garanti.

En relation är i domännyckel normal form (DK / NF) om varje begränsning på relationen är en logisk följd av definitionen av nycklar och domäner. En begränsning i denna definition är en regel som är exakt nog att du kan utvärdera om det är sant. En nyckel är en unik identifierare för en rad i en tabell. En domän är uppsättningen tillåtna värden för ett attribut.

Titta på den här databasen, som finns i 1NF, för att se vad du måste göra för att sätta den databasen i DK / NF.

Tabell: FÖRSÄLJNING (Kund_ID, Produkt, Pris)

Nyckel: Kund_ID

Begränsningar:

• Customer_ID bestämmer Produkt

• Produkten bestämmer Pris

• Customer_ID måste vara ett heltal > 1000

För att genomdriva begränsning 3 (att Customer_ID måste vara ett heltal större än 1000) kan du helt enkelt definiera domänen för Customer_ID för att införliva denna begränsning. Det gör begränsningen en logisk följd av domänen i CustomerID-kolumnen. Produkten beror på Customer_ID, och Customer_ID är en nyckel, så du har inga problem med Constraint 1, vilket är en logisk följd av definitionen av nyckeln.

Begränsning 2 är ett problem. Priset beror på (är en logisk följd av) Produkt och Produkt är inte en nyckel. Lösningen är att dela försäljningsbordet i två tabeller. En tabell använder Customer_ID som en nyckel, och den andra använder Produkt som en nyckel. Databasen, förutom att vara i 3NF, finns också i DK / NF.

Designa dina databaser så att de är i DK / NF om möjligt. Om du kan göra det, gör att alla nyckelbegränsningar och domänbegränsningar får alla begränsningar att uppfyllas, och förändringsavvikelser är inte möjliga. Om en databas struktur är utformad för att förhindra att du lägger den in i DK / NF, måste du bygga begränsningarna i det applikationsprogram som använder databasen. Databasen själv garanterar inte att begränsningarna kommer att uppfyllas.

Onormal form

Som i livet, så i databaser: Ibland är det onormalt att betala.Du kan få bäras bort med normalisering och gå för långt. Du kan bryta upp en databas i så många tabeller att hela saken blir ojämn och ineffektiv. Prestanda kan dunkla. Ofta är den optimala strukturen för din databas lite denormaliserad.

Faktum är att praktiska databaser (i allra högsta grad, i alla fall) nästan aldrig normaliseras hela vägen till DK / NF. Du vill dock normalisera de databaser som du utformar så mycket som möjligt, för att eliminera möjligheten till datakorruption som uppstår på grund av modifieringsavvikelser.

Efter att du har normaliserat databasen så långt du kan kan du göra några återvinningar som en torr körning. Om prestanda inte är tillfredsställande, undersök din design för att se huruvida selektiv denormalisering skulle förbättra prestanda utan att offra integritet. Genom att noga lägga till redundans på strategiska platser och denormaliserande just enough , kan du komma fram till en databas som är både effektiv och säker från anomalier.