Baza traceability

0

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.

1

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ą.

0
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'
...

0

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.

0

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

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0