Diskussion:Normalform (databaser)

message: Att lägga in en numerisk primärnyckel i tabellen är iofs precis som man brukar göra "i verkligheten", men krånglar inte det till definitionen? 1NF innebär inte nödvändigtvis att man måste ha någon primärnyckel, bara att det inte får finnas dublettrader (med andra ord att det måste finnas en eller flera kolumner som unikt identifierar raden. Sedan är det en annan sak att med en kolumn som "Tillgångar" så kan just det inträffa, dvs man kan få dublettrader om man inte lägger till en unik nyckel: En kund kan samma dag göra två exakt lika stora transaktioner). 
Det här låter krångligt, det märker jag själv. Men vad jag försöker säga är att det är olyckligt, emm, om man ger läsaren uppfattningen att en tabell på 1NF måste ha en teknisk (numerisk) primärnyckel, dvs en primärnyckel som inte bär någon information utöver att den är unik. Kanske det vore en idé att skapa en annan tabell med flera kolumner (och flera beroenden), så att man med hjälp av exempel, hämtade direkt ur tabellen, kan illustrera krångliga termer som "fullständigt funktionellt beroende" och "transitivt funktionellt beroende" (och varför förkorta den första termen "FFB"? Stackas läsare...). Funderar på att göra omdesignen av tabellexemplet själv, när jag får tid. (Fast någon annan får hemskt gärna hinna före...) / LawD 13 januari 2009 kl. 22.25 (CET)
Dessutom (kom jag på senare) så hamnar tabellen automatiskt på andra normalformen om man inför en numerisk primärnyckel. Bra, naturligtvis, för en "riktig" tabell, men kanske mindre lyckat för ett pedagogiskt exempel... / LawD 16 januari 2009 kl. 10.21 (CET)
replies: text: Jag har lagt in exempel på 1NF och 2NF. De följer dessutom, mlm per automatik, också 3NF och BCNF (Boyce-Codds normalform). Vill någon utöka exemplen med tabeller som är på 2NF men inte 3NF, respektive BCNF och 4NF till 6NF, får vederbörande gärna försöka. De flesta tabeller på 2NF brukar också vara på 3NF och BCNF, och högre normalformer används sällan. (Dessutom är jag dålig på dem; 4NF, 5NF och 6NF uppfanns alla efter jag hade gått ut universitetet och börjat mitt yrkesliv, och eftersom de sällan används har jag inte stött på dem). / LawD 18 januari 2009 kl. 01.21 (CET)

message: Jag tycker att primärnyckeln bör ändras från kundens namn till ett kund-id. Dessa tabeller följer inte riktigt normalformerna då det kan uppstå logiska fel. Man kan exempelvis fråga sig vad som händer ifall Peter byter namn till Petra efter ett könsbyte - då måste man byta namnet på ALLA rader i samtliga tabeller där Peter påverkat datat. Eller så byts bara en, och vad händer då om man ställer frågan "Vilka varor har Peter köpt?"
Istället bör det finnas en tabell som heter "Kunder" som innehåller raderna "kund-id" samt "namn" för att kringå detta logiska problem. Accatyyc 12 april 2011 kl. 09.58 (CEST)
replies: text: Det är alldeles riktigt, och det är givetvis så man gör "i verkligheten". Tabellerna är emellertid valda inte för att illustrera god tabelldesign, utan för att tjäna som pedagogiska exempel på de olika normalformerna; jag påpekar redan från början att tabellen är starkt förenklad. Tabellen måste vara på första normalformen initiellt för att man ska kunna illustrera hur man överför den till högre normalformer. Hade jag redan från början lagt in en teknisk (=numerisk) primärnyckel, hade tabellen direkt blivit på andra normalformen. Därför valde jag att behålla en icke-teknisk primärnyckel i huvudtabellen (Försäljning). Annars hade jag inte kunnat illustrera hur man bryter ut "Vara" ur primärnyckeln för att överföra tabellen till andra normalformen. Exemplet är långtifrån perfekt, men problemet är snarare att tabellen är "för bra" redan från början; när jag överför den till andra normalformen genom att bryta ut kolumnen "Vara", blir den direkt på tredje normalformen. Detta är givetvis utmärkt i en riktig situation, men mindre lyckat ur pedagogisk synvinkel.

text: Lägg slutligen märke till att jag faktiskt inför en teknisk nyckel till tabellen "Varor"; användningen av begreppet redovisas alltså. / LawD 12 april 2011 kl. 14.56 (CEST)
replies: text: :När jag tittar närmare på den här diskussionen så har jag redan förklarat varför tabellen ser ut som den gör en gång, överst på den här diskussionssidan: Ursprungligen lade man in en numerisk nyckel när man överförde tabellen till första normalformen. Men detta innebar att tabellen automatiskt hamnade på andra normalformen i stället för första, vilket jag alltså tyckte var olyckligt ur pedagogisk synvinkel. / LawD 12 april 2011 kl. 15.11 (CEST)
thread_title:  Primärnyckeln i tabellerna