Du bör alltid börja med att designa dina tabeller i tredje normalform (3NF). Det är helt acceptabelt att återgå till mindre former (av prestationsskäl vanligtvis) förutsatt att du förstår och mildrar effekten, men börjar med 3NF.
Den (något förenklade) regeln att komma ihåg är att varje icke-nyckelkolumn i en tabell bör bero på:
- nyckeln,
- hela nyckeln,
- och inget annat än nyckeln,
- "så hjälp mig, Codd" - lite DBA-humor (och jag menar "lite").
Den första frågan är ganska enkel.
En-till-många-relationer representeras bäst som en främmande nyckel i tabellen "många". Så det du föreslår är vettigt. Det låter dig begränsa relationen automatiskt. Om du hade ett separat sammanfogningsbord (används för många-till-många), skulle du behöva ta till "trick" för att upprätthålla en-till-många-relationen.
När det gäller din andra fråga, måste du titta på "Codd"-regeln ovan och tänka för dig själv:vad exakt representerar dessa rader i varje tabell? Om en arbetsobjektsåtgärd är ett distinkt objekt från ett arbetsobjekt (de kan vara relaterade men om de inte representerar samma objekt är de distinkta), bör de finnas i olika tabeller.
Dessutom verkar det som att du har en en-till-många-relation där (ett objekt kan ha många åtgärder) så de borde finnas i olika tabeller bara av den anledningen.
När det gäller din fråga om redundant information:om de verkligen är överflödiga, bör de repareras.
Använd step_num som ett exempel, vad exakt representerar detta? Om det är ett attribut för arbetet, det ska inte vara med i arbetet bord överhuvudtaget.
Du skulle bli av med den därifrån och, om du ville veta stegnumret för en rad i arbetshandlingstabellen, skulle du gå med i arbetsobjekttabellen med hjälp av den främmande nyckeln.
Om det istället är ett attribut för arbetsåtgärden, bör du ta bort det från arbetsobjektstabellen eftersom det inte är meningsfullt. Du kanske har två åtgärder var och en med olika stegnummer så vad skulle stegnumret för det överordnade objektet vara i så fall?
Naturligtvis kan du ha en distinkt stegnummer för både objekt och åtgärder - i så fall skulle jag överväga att byta namn för att göra avsikten tydlig, något som item_step_num och action_step_num .
Slutsatsen är att börja med 3NF. Om din databas vid något tillfälle går för långsamt, då överväga återgång till en mindre form. Du kan sedan fråga en annan fråga här om hur man känner igen och mildrar de problem som uppstår därav (till exempel möjligheten till inkonsekventa data på två ställen och att använda triggers för att förhindra det).