Zawsze powinieneś zacząć od zaprojektowania swoich tabel w trzeciej postaci normalnej (3NF). Przywracanie mniejszych formularzy (zwykle ze względu na wydajność) jest całkiem akceptowalne, pod warunkiem, że rozumiesz i łagodzisz wpływ, ale zacznij z 3NF.
Należy pamiętać (nieco uproszczoną) regułą, że każda kolumna niebędąca kluczem w tabeli powinna zależeć od:
- klucz,
- cały klucz,
- i tylko klucz,
- „tak mi pomóż, Codd” – trochę humoru DBA (mam na myśli „mały”).
Pierwsze pytanie jest dość proste.
Relacje jeden-do-wielu najlepiej reprezentować jako klucz obcy w tabeli „wiele”. Więc to, co proponujesz, jest rozsądne. Pozwala na automatyczne ograniczenie relacji. Jeśli masz osobną tabelę łączenia (używaną dla wielu do wielu), musisz uciec się do „oszustwa”, aby wymusić relację jeden do wielu.
Jeśli chodzi o drugie pytanie, musisz spojrzeć na powyższą zasadę „Dorsz” i zastanowić się:co dokładnie reprezentują te wiersze w każdej tabeli? Jeśli akcja elementu pracy jest odrębnym obiektem niż element pracy (mogą być powiązane ale jeśli nie reprezentują tego samego obiektu, są różne), powinny znajdować się w różnych tabelach.
Ponadto wygląda na to, że masz tam relację jeden-do-wielu (jeden element może mieć wiele akcji), więc powinny znajdować się w różnych tabelach tylko z tego powodu.
Jeśli chodzi o Twoje zapytanie dotyczące zbędnych informacji:jeśli naprawdę są zbędne, należy je naprawić.
Korzystanie z step_num na przykład, co to dokładnie oznacza? Jeśli jest to atrybut przedmiotu pracy, nie powinno być w pracy działanie w ogóle.
Pozbędziesz się tego stamtąd, a jeśli chcesz znać numer kroku dla wiersza w tabeli działań roboczych, połączysz się z tabelą elementów roboczych za pomocą klucza obcego.
Jeśli zamiast tego jest to atrybut akcji pracy, powinieneś usunąć go z tabeli elementów pracy, ponieważ nie ma to sensu. Możesz mieć dwie akcje, z których każda ma inny numer kroku, więc jaki byłby w takim przypadku numer kroku elementu nadrzędnego?
Oczywiście możesz mieć odrębną numer kroku dla obu pozycji i akcje - w takim przypadku rozważyłbym zmianę nazwy, aby intencja była jasna, coś w stylu item_step_num i action_step_num .
Najważniejsze jest rozpoczęcie od 3NF. Jeśli w pewnym momencie Twoja baza danych będzie działać zbyt wolno, to rozważ powrót do mniejszej formy. Następnie możesz zapytać innego pytanie o to, jak rozpoznać i złagodzić wynikające z tego problemy (na przykład możliwość niespójnych danych w dwóch miejscach i użycie wyzwalaczy, aby temu zapobiec).
