Dovresti sempre iniziare progettando le tue tabelle in terza forma normale (3NF). È abbastanza accettabile tornare a forme minori (di solito per motivi di prestazioni) a condizione che tu comprenda e mitighi l'impatto, ma inizia con 3NF.
La regola (leggermente semplificata) da ricordare è che ogni colonna non chiave in una tabella dovrebbe dipendere da:
- la chiave,
- l'intera chiave
- e nient'altro che la chiave,
- "Allora aiutami, Codd" - un po' di umorismo da DBA (e intendo "poco").
La prima domanda è abbastanza semplice.
Le relazioni uno-a-molti sono meglio rappresentate come chiave esterna nella tabella "molti". Quindi quello che proponi è sensato. Ti consente di limitare automaticamente la relazione. Se avessi una tabella di unione separata (usata per molti-a-molti), dovresti ricorrere a "inganni" per rafforzare la relazione uno-a-molti.
Per quanto riguarda la tua seconda domanda, devi guardare alla regola "Codd" sopra e pensare a te stesso:cosa rappresentano esattamente queste righe in ogni tabella? Se un'azione di un elemento di lavoro è un oggetto distinto da un elemento di lavoro (potrebbero essere correlati ma, se non rappresentano lo stesso oggetto, sono distinti), dovrebbero trovarsi in tabelle diverse.
Inoltre, sembra che tu abbia una relazione uno-a-molti lì (un elemento può avere molte azioni), quindi dovrebbero trovarsi in tabelle diverse solo per questo motivo.
Per quanto riguarda la tua domanda sulle informazioni ridondanti:se davvero sono ridondanti, dovrebbero essere riparati.
Usando il step_num ad esempio, cosa rappresenta esattamente questo? Se è un attributo dell'oggetto di lavoro non dovrebbe essere nell'azione del lavoro tavolo a tutti.
Da lì lo elimineresti e, se volessi conoscere il numero di passaggio per una riga nella tabella delle azioni di lavoro, ti uniresti alla tabella degli elementi di lavoro utilizzando la chiave esterna.
Se invece è un attributo dell'azione di lavoro, dovresti rimuoverlo dalla tabella degli elementi di lavoro poiché non ha senso. Potresti avere due azioni ciascuna con un numero di passaggio diverso, quindi quale sarebbe il numero di passaggio dell'elemento principale in quel caso?
Certo, potresti avere un distinto numero di passaggio per entrambi gli elementi e azioni - in tal caso, prenderei in considerazione la possibilità di rinominare per chiarire l'intento, qualcosa come item_step_num e action_step_num .
La conclusione è iniziare con 3NF. Se a un certo punto il tuo database funziona troppo lentamente, allora considerare il ritorno a una forma minore. Puoi quindi chiedere a un altro domanda qui su come riconoscere e mitigare i problemi che ne derivano (ad esempio, la possibilità di dati incoerenti in due punti e l'utilizzo di trigger per prevenirlo).
