Baza traceability

Cześć wszystkim!
Jestem w trakcie projektowania bazy traceability (baza która pomaga śledzić użyte komponenty do konkretnego wyrobu).

Obecnie mam tabele:

*Finalny wyrób (składa się z części składowych - nie stricte komponentów)

*Części składowe (Tutaj mam problem, gdyż używam wiele typów składowych i jak sądzę do każdego typu powinienem posiadać osobną tabelę)

*Komponenty (Komponenty, których używamy do produkcji części składowych - do każdej części składowej inny zestaw komponentów)

*Dostawca (Tutaj wszystko chyba jasne)

Prosiłbym o sugestię jak rozwiązać części składowe, żeby to miało ręce i nogi.
Jeśli potrzebujecie więcej informacji to dawajcie znać.
PS
Szukałem podobnego tematu, nie znalazłem. Myślę, że temat w miarę popularny, więc ma on sens.

nikt nic nie wie co tam planujesz trzymać więc nikt nic nie powie. Bazę się zawsze projektuje tak samo - najpierw robisz wywiad środowiskowy i określasz jakie dane będą przechowywane, następnie po kolei przechodzisz od danych nieznormalizowanych do 3PN (ew. do 2.5PN). Potem jeszcze trzeba przemyśleć czy gdzieś nadmiarowe dane nie będą dobrym rozwiązaniem i masz.

Jak dla mnie to Finalny wyrób, Części składowe oraz Komponenty powinny być w jednej (drzewka można też robić w dwóch tabelach aby przyśpieszyć dostęp do danych) tabeli w formie drzewka. Ale ja nie mam pojęcia czym się one od siebie różnią.

Kitras napisał(a):

...

*Części składowe (Tutaj mam problem, gdyż używam wiele typów składowych i jak sądzę do każdego typu powinienem posiadać osobną tabelę)

Słaby pomysł. Co jak pojawi się nowy komponent, trzeba będzie dopisać coś do systemu, żeby wspierał kolejną tabelkę?

Z tego co zrozumiałem to masz:

                  1:N                                   M:N
Finalny_Wyrob ---złożony z ---  Czesc_Skladowa  --- zbudowana z --  Komponent 

Ten związek M:N rozbijasz na 1:N za pomocą relacji, która połączy Ci "Cześć skłdową" z "Komponentami", nie wiem jak to w Twoim przypadku nazwać, "Zestaw" ? MiIałbyś więc model złożony z 4 relacji:

• Finalny_Wyrob
• Czesc_Skladowa
• Komponent
• Zestaw (mówi o tym z jakich komponentów zbudowana jest Czesc_Skladowa)

Możesz też zrobić tak jak Ci @abrakadaber napisał, tj. użyć jednej tabelki na przedstawienie hierarchii. Nie wiem jak sensownie ją nazwać, bo nie mam pojęcia o Twojej domenie.
np. tabelka hierarchy:

   ID (PK)
   ENTRY_TYPE (FK albo constraint typu check: F - finalny, C - komponent, P - part )
   PARENT_ID (FK do HIERARCHY - wskazanie poziomu nadrzędnego, NULL oznacza korzeń drzewka)
   DESCRIPTION

I np. dla Produktu, składającego się z 2 części, a każda z nich 2 komponentów, miałby wpisy typu:

1,F,null,'Produkt finalny'
2,P,1,'Czesc 1'
3,P,1,'Czesc 2'
4,C,2,'KomponentA dla czesci 1'
5,C,2,'KomponentB dla czesci 1'
6,C,3,'KomponentC dla czesci 2'
7,C,3,'KomponentD dla czesci 2'
...

Dzięki za odpowiedzi.
Już tłumaczę.
Mam produkt końcowy (posiada unikalny serial number [PK]), który się składa - z około 40 półproduktów składowych, które również posiadają własny unikalny Serial Number - Każda z tych składowych jest zrobiona z X komponentów mogących się powtarzać
Cały sens tej bazy jest taki:
Chcę mieć możliwość wyciągnięcia szczegółowych informacji o komponencie użytym w danym półprodukcie/składowej, użytym w określonym serial numberze produktu końcowego.
Sprawa jest troszkę pokręcona. Jeśli jest potrzeba to mogę to rozpisać. :)
Działam na SQL Express i później samą bazę przerzucę do C# pod apkę umożliwiającą manipulacje danymi.

ja nadal nie widzę sensu rozbijać to na osobne tabele