Vždy byste měli začít navrhováním svých tabulek ve třetí normální formě (3NF). Je docela přijatelné vrátit se k menším formám (obvykle z důvodů výkonu), pokud rozumíte a zmírníte dopad, ale začněte s 3NF.
(Poněkud zjednodušené) pravidlo, které je třeba si zapamatovat, je, že každý neklíčový sloupec v tabulce by měl záviset na:
- klíč,
- celý klíč,
- a nic než klíč,
- "tak mi pomoz, Codde" - trocha humoru DBA (a myslím "málo").
První otázka je poměrně jednoduchá.
Vztahy one-to-many jsou nejlépe reprezentovány jako cizí klíč v tabulce "many". Takže to, co navrhuješ, je rozumné. Umožňuje automaticky omezit vztah. Pokud byste měli samostatnou spojovací tabulku (používá se pro many-to-many), museli byste se uchýlit k „podvodu“, abyste prosadili vztah one-to-many.
Pokud jde o vaši druhou otázku, musíte se podívat na výše uvedené pravidlo „Codd“ a zamyslet se nad sebou:co přesně tyto řádky v každé tabulce představují? Pokud je akce pracovní položky odlišným objektem od pracovní položky (mohou spolu souviset ale pokud nepředstavují stejný objekt, jsou odlišné), měly by být v různých tabulkách.
Navíc se zdá, že tam máte vztah jedna k mnoha (jedna položka může mít mnoho akcí), takže by měly být v různých tabulkách už jen z tohoto důvodu.
Pokud jde o váš dotaz na nadbytečné informace:pokud skutečně jsou nadbytečné, měly by být opraveny.
Pomocí step_num jako příklad, co přesně to představuje? Pokud se jedná o atribut pracovní položky, nemělo by to být v pracovní akci tabulky vůbec.
Odtud byste se ho zbavili a pokud byste chtěli znát číslo kroku pro řádek v tabulce pracovních akcí, spojili byste se s tabulkou pracovních položek pomocí cizího klíče.
Pokud je to místo toho atribut pracovní akce, měli byste jej odstranit z tabulky pracovních položek, protože to nedává smysl. Můžete mít dvě akce, každou s jiným číslem kroku, takže jaké by bylo v tomto případě číslo kroku nadřazené položky?
Samozřejmě můžete mít výrazné číslo kroku pro obě položky a akce – v tom případě bych zvážil přejmenování, aby byl záměr jasný, něco jako item_step_num a action_step_num .
Sečteno a podtrženo je začít s 3NF. Pokud v určitém okamžiku vaše databáze běží příliš pomalu, pak zvážit návrat k menší formě. Poté se můžete zeptat dalšího zde si položte otázku, jak rozpoznat a zmírnit problémy, které z toho vyplývají (například možnost nekonzistentních dat na dvou místech a použití spouštěčů, které tomu mají zabránit).