Identyfikacja struktury zestawienia komponentów (BOM) w bazach danych

Wzorzec projektowy zestawienia komponentów (BOM) jest zwodniczo prosty, ale niezwykle potężny. Historycznie był używany do modelowania struktur produktów, ale wzorzec może służyć do znacznie więcej niż tylko zdefiniowania hierarchii. W tym artykule przedstawimy trzy bardzo różne przykłady, które pomogą Ci rozpoznać wzór we własnych projektach.

Co to jest zestawienie materiałów lub BOM?

zestawienie materiałów ma swoje korzenie w produkcji. Jest to lista surowców, podzespołów, zespołów pośrednich, podzespołów, części oraz ilości każdego z nich potrzebnego do wytworzenia produktu końcowego. Można na to spojrzeć jak na hierarchiczną dekompozycję produktu. Inne terminy dotyczące tego samego to struktura produktu, zestawienie materiałów i powiązana lista.

Aby zilustrować zestawienie komponentów, spójrz na poniższy model koncepcyjny. Zaczyna się od produktu najwyższego poziomu, Car . Ogólnie rzecz biorąc, Car ma Engine i Body . W tym przykładzie występują różne typy silników:V6 i V8. Istnieją różne rodzaje nadwozi:trzydrzwiowe, pięciodrzwiowe i kombi (znane również jako kombi lub kombi). Proces rozkładu może sprowadzić się do ostatniej nakrętki i śruby – a nawet odrobiny kleju – ale masz obraz.

Na najprostszym poziomie łączysz ze sobą dwie części w formie hierarchii – część nadrzędną z częścią podrzędną – od szczytu hierarchii aż do samego dołu. Najbardziej podstawowy model produkcyjny BOM wygląda tak:

To jest klasyczna struktura BOM , gdzie pojedyncza tabela [nadrzędna] ma dwie relacje z [podrzędną] tabelą skrzyżowań.

Oto prosta hierarchia produktów z przykładu Car:

BOM w produkcji mają zwykle te same główne właściwości:

• Zespoły, podzespoły i poszczególne komponenty mogą być ponownie użyte . Na przykład ten sam rodzaj śruby może być użyty w różnych typach zespołów.
• Często musi istnieć ilość specyficzna dla hierarchii . Na przykład ważne jest, aby wiedzieć, że jeden zespół wymaga 10 śrub, ale inny zespół może potrzebować 15 śrub o tej samej specyfikacji.

Po zdefiniowaniu zespołu jego struktura jest automatycznie importowana do innych zespołów, które z niego korzystają. Więc jeśli ten zespół miałby się zmienić, wszystkie inne BOM, które go używają, zostaną automatycznie zaktualizowane. Zestawienia komponentów opisujące takie podzespoły są określane jako modułowe zestawienia komponentów .

Dla producentów BOM jest kluczową informacją o produkcie, zapisem zawierającym wszystko, co jest potrzebne do wytworzenia produktu. Do obsługi konfigurowalności wymagane są zaawansowane techniki modelowania produkty, odmiany komponentów lub zastąp składniki. Zmiana niewielkiej części produktu może mieć wieloraki wpływ na inne BOM-y produktów. Bez uwzględnienia tego, zarządzanie BOM może stać się niewykonalne.

Ale ta specjalistyczna dziedzina wykracza poza zakres tego artykułu. Zamiast tego skupimy się na przykładach, w których struktury BOM mogą występować w projekcie bazy danych. Gdy rozpoznasz zestawienie komponentów, będziesz mógł skorzystać z tego potężnego wzorca projektowego.

Zaczniemy od wspólnego przykładu:relacji wiele-do-wielu między lotami a lotniskami.

Co wzór wykazu materiałów ma wspólnego z lotami?

Oto model koncepcyjny:

Wyobraź sobie siebie na dowolnym lotnisku na świecie. Stamtąd będziesz mógł zobaczyć samoloty startujące do innych miejsc. Zobaczysz także samoloty lądujące z innych miejsc. Tak więc istnieje relacja „wiele do wielu” między lotniskami wylotu i przylotu.

Zazwyczaj tę relację wiele-do-wielu rozwiązujemy za pomocą tabeli skrzyżowań:

Flight klasa będzie miała swoje własne atrybuty, w tym flightNumber , scheduledDepartureTime i scheduledArrivalTime .

Patrząc wstecz na nasz model, możemy zauważyć drobny problem. Wiemy, że nie ma czegoś takiego jak DepartureAirport lub ArrivalAirport . Oba są tylko lotniskami, z których odlatują i do których przylatują.

Więc łączymy DepartureAirport i ArrivalAirport do jednego airport tabela w ten sposób:

Ponownie jest to zgodne z klasyczną strukturą BOM , gdzie pojedyncza tabela [nadrzędna] ma dwie relacje z [podrzędną] tabelą skrzyżowań.

Jednak koncepcyjnie istnieje duża różnica między tym a produkcyjnym BOM. To zestawienie komponentów nie ma prawdziwej struktury hierarchicznej. Jest całkowicie płaski. Dlaczego to mówię?

Najlepiej to opisać na przykładzie.

Najpierw rozważmy kilka przykładowych danych dla tego BOM:

Teraz omówimy przykład. Wyobraź sobie, że musisz lecieć z Manchesteru do Chennai. Nie ma bezpośrednich lotów. Ale możesz polecieć z Manchesteru do Dubaju, pierwszy etap Twojej podróży. Następnie możesz wziąć kolejny lot z Dubaju do Chennai, drugi etap podróży. Podczas gdy obie odnogi tworzą twoją trasę, druga odnoga w żadnym wypadku nie jest jakimś podkomponentem pierwszego odcinka! Dlatego ta struktura jest płaska.

Ale zwróć uwagę na korespondencję danych w skali 1:1 między częściami i przykładami lotów:Samochód → Manchester; Silnik → Dubaj; Ćennaj → V6.

W przykładzie z samochodem części tworzą ścisłą hierarchię . W przykładzie z lotniskiem loty można przemierzać, aby utworzyć więcej połączonych luźno połączeń między lotami. Dla pasażera lecącego z Manchesteru do Chennai należy stworzyć plan podróży. Jest to wynik zapytania, które bierze pod uwagę to, co stanowi połączenie – m.in. minimalny i maksymalny czas między lotami; czy ta sama linia lotnicza musi być używana, czy też dozwolone są różne linie lotnicze.

Następnie przyjrzyjmy się, jak BOM można wykorzystać do opisania relacji w modelowaniu danych.

Relacje w strukturze BOM

Mam tu na myśli relacje między ludźmi, między organizacjami oraz między organizacjami i ludźmi. Są to relacje w świecie rzeczywistym, takie jak osoba będąca pracownikiem firmy lub członkiem zespołu lub firmy będącej właścicielem innej firmy. Model koncepcyjny wygląda tak:

Gdybyś miał zmapować to bezpośrednio do modelu fizycznego, miałbyś tabele skrzyżowań dla każdej z relacji wiele-do-wielu. Może to być nieco zaśmiecone i nie pomaga w uruchamianiu zapytań – na przykład w znalezieniu wszystkich relacji Person ma.

Więc prawdopodobnie lepiej jest rozpoznać tę Person i Organization są różne rodzaje Party . To pozwala nam uprościć trzy relacje wiele-do-wielu w jedną:

Jeśli Twoje wymagania są proste, może to wystarczyć. Ale w prawdziwym świecie sprawy nie wydają się takie proste. Na przykład pracownik może opuścić firmę, aby przez jakiś czas podróżować po świecie. Kiedy wraca z podróży, szuka pracy i zostaje ponownie zatrudniony przez firmę, którą opuścił. (To się zdarza!) Pracownik ma zatem dwa oddzielne przypadki relacji z tym pracodawcą, każdy z różnymi datami wejścia w życie i prawdopodobnie z innym identyfikatorem pracownika.

Tak więc sam związek wymaga atrybutów. Oznacza to inny podmiot, Relationship , musi je zawierać:

Ponownie jest to zgodne z klasyczną strukturą BOM , gdzie pojedyncza tabela [nadrzędna] ma dwie relacje z [podrzędną] tabelą skrzyżowań.

Zgodnie z konwencją w tym modelu 1 Interaktor ma tendencję do bycia lepszą Party w Relationship takich jak pracodawca, a nie pracownik, lub lider zespołu, a nie członek zespołu.

Ten wzorzec BOM powiązania z podmiotami może być użyty do wyświetlenia listy wszystkich pracowników (2 interactor ) w organizacji (1 interactor ) w umowie poziom, jeśli chcesz. Jest to płaska, jednopoziomowa hierarchia. Może być również używany jednocześnie aby zdefiniować całą strukturę raportowania zarządzania (lub hierarchii) w tej samej organizacji, która może mieć dowolną liczbę poziomów. Na przykład:pracownik może pracować na podstawie jednej umowy przez kilka lat, ale w tym czasie może pracować dla różnych menedżerów (1 współpracownik =odpowiedzialny za; 2 współpracownik =podlega). Może nawet pracować jednocześnie dla więcej niż jednego menedżera.

Oto, jak mogą wyglądać dane (z ich rolami w nawiasach):

Poznaj zestawienie komponentów

Podczas gdy zestawienie materiałów struktura ma swoje korzenie w produkcji, może być używany do różnych celów , który może wahać się od czegoś ściśle hierarchicznego i ściśle powiązanego do czegoś dość płaskiego i luźniej powiązanego.

Mam nadzieję, że te przykłady pomogą Ci rozpoznać wzorzec BOM, jeśli istnieje w Twoich projektach. Gdy rozpoznasz wzór, zrozumiesz, jak powinien być zaimplementowany. Nie musisz za każdym razem wymyślać koła na nowo – wystarczy dostosować je do swoich konkretnych wymagań.