Identifizieren der Stücklistenstruktur (BOM) in Datenbanken

Das Entwurfsmuster für die Stückliste (BOM) ist täuschend einfach, aber unglaublich leistungsfähig. In der Vergangenheit wurde es verwendet, um Produktstrukturen zu modellieren, aber das Muster kann verwendet werden, um viel mehr zu tun, als nur eine Hierarchie zu definieren. Dieser Artikel stellt drei sehr unterschiedliche Beispiele vor, die Ihnen helfen sollen, das Muster in Ihren eigenen Projekten zu erkennen.

Was ist eine Stückliste oder BOM?

Eine Stückliste hat seine Wurzeln in der Fertigung. Es ist eine Liste der Rohmaterialien, Unterbaugruppen, Zwischenbaugruppen, Unterkomponenten, Teile und der Mengen, die jeweils zur Herstellung eines Endprodukts benötigt werden. Sie können es als hierarchische Zerlegung eines Produkts betrachten. Andere Begriffe für dasselbe sind Produktstruktur, Stückliste und zugehörige Liste.

Um eine Stückliste zu veranschaulichen, sehen Sie sich das konzeptionelle Modell unten an. Es beginnt mit dem Top-Level-Produkt Car . Im Großen und Ganzen ein Car hat eine Engine und einen Body . In diesem Beispiel gibt es verschiedene Arten von Motoren:V6 und V8. Es gibt verschiedene Arten von Karosserien:3-Türer, 5-Türer und Kombi (auch bekannt als Kombi oder Kombi). Der Zersetzungsprozess kann bis zur allerletzten Mutter und Schraube – oder sogar bis zum letzten Leimklecks – reichen, aber Sie bekommen ein Bild.

Auf der einfachsten Ebene verbinden Sie zwei Teile in Form einer Hierarchie – einen Elternteil mit einem Kindteil – von der Spitze der Hierarchie bis ganz nach unten. Das einfachste Fertigungsstücklistenmodell sieht so aus:

Dies ist die klassische Stücklistenstruktur , wobei eine einzelne [übergeordnete] Tabelle zwei Beziehungen zu einer [untergeordneten] Junction-Tabelle hat.

Hier ist die einfache Produkthierarchie aus dem Autobeispiel:

Stücklisten in der Fertigung haben in der Regel die gleichen Haupteigenschaften:

• Baugruppen, Unterbaugruppen und einzelne Komponenten können wiederverwendet werden . Beispielsweise kann die gleiche Art von Bolzen in verschiedenen Montagearten verwendet werden.
• Oft muss eine hierarchiespezifische Menge vorhanden sein . Es ist beispielsweise wichtig zu wissen, dass eine Baugruppe 10 Schrauben benötigt, eine andere Baugruppe jedoch möglicherweise 15 Schrauben derselben Spezifikation benötigt.

Nachdem Sie eine Assembly definiert haben, wird ihre Struktur automatisch in alle anderen Assemblys importiert, die sie verwenden. Wenn sich also diese Baugruppe ändert, werden alle anderen Stücklisten, die sie verwenden, automatisch aktualisiert. Stücklisten, die solche Unterbaugruppen beschreiben, werden als modulare Stücklisten bezeichnet .

Für Hersteller ist eine Stückliste eine wichtige Produktinformation, eine Aufzeichnung, die alles auflistet, was zur Herstellung eines Produkts benötigt wird. Fortgeschrittene Modellierungstechniken sind erforderlich, um mit configurable umzugehen Produkte, Komponenten Variationen , oder substituieren Komponenten. Das Ändern eines kleinen Teils eines Produkts kann mehrere Auswirkungen auf andere Produktstücklisten haben. Ohne diese zu berücksichtigen, kann die Stücklistenverwaltung ziemlich unüberschaubar werden.

Aber dieses Spezialgebiet würde den Rahmen dieses Artikels sprengen. Stattdessen konzentrieren wir uns auf Beispiele dafür, wo BOM-Strukturen im Datenbankdesign auftreten können. Sobald Sie eine Stückliste erkennen können, können Sie dieses leistungsstarke Designmuster nutzen.

Wir beginnen mit einem allgemeinen Beispiel:der Viele-zu-Viele-Beziehung zwischen Flügen und Flughäfen.

Was hat das Stücklistenmuster mit Flügen zu tun?

Hier ist das konzeptionelle Modell:

Stellen Sie sich vor, Sie befinden sich an einem beliebigen Flughafen der Welt. Von dort aus können Sie Flugzeuge zu anderen Zielen starten sehen. Sie werden auch Flugzeuge sehen, die von anderen Zielen landen. Es besteht also eine Viele-zu-Viele-Beziehung zwischen Abflug- und Ankunftsflughäfen.

Normalerweise lösen wir diese Viele-zu-Viele-Beziehung mithilfe einer Verbindungstabelle auf:

Der Flight Klasse hat ihre eigenen Attribute, einschließlich flightNumber , scheduledDepartureTime und scheduledArrivalTime .

Wenn wir auf unser Modell zurückblicken, entdecken wir möglicherweise ein kleines Problem. Wir wissen, dass es so etwas wie einen DepartureAirport oder ein ArrivalAirport . Sie sind beide nur Flughäfen, von denen Flüge abfliegen und an denen Flüge ankommen.

Also führen wir DepartureAirport und ArrivalAirport zu einem einzigen airport Tabelle wie folgt:

Auch dies folgt der klassischen Stücklistenstruktur , wobei eine einzelne [übergeordnete] Tabelle zwei Beziehungen zu einer [untergeordneten] Junction-Tabelle hat.

Konzeptionell besteht jedoch ein großer Unterschied zwischen dieser und einer Fertigungsstückliste. Diese Stückliste hat keine echte hierarchische Struktur. Es ist völlig flach. Warum sage ich das?

Es lässt sich am besten anhand eines Beispiels beschreiben.

Sehen wir uns zunächst einige Beispieldaten für diese Stückliste an:

Jetzt arbeiten wir ein Beispiel durch. Stellen Sie sich vor, Sie müssten von Manchester nach Chennai fliegen. Es gibt keine Direktflüge. Aber Sie können von Manchester nach Dubai fliegen, der ersten Etappe Ihrer Reise. Sie können dann einen weiteren Flug von Dubai nach Chennai nehmen, die zweite Etappe Ihrer Reise. Während die beiden Etappen Ihre Reiseroute bilden, ist die zweite Etappe in keiner Weise eine Art Teilkomponente der ersten Etappe! Daher ist diese Struktur flach.

Beachten Sie aber die 1:1 Übereinstimmung der Daten zwischen den Teilen und Flügen Beispiele:Auto → Manchester; Motor → Dubai; Chennai → V6.

Im Autobeispiel bilden die Teile eine eng gekoppelte Hierarchie . Im Flughafenbeispiel können Flüge durchquert werden, um mehr locker gekoppelte Verbindungen zu bilden zwischen Flügen. Für einen Passagier, der von Manchester nach Chennai fliegt, muss eine Reiseroute erstellt werden. Dies ist das Ergebnis einer Abfrage, die berücksichtigt, was eine Verbindung ausmacht – z. die minimale und maximale Zeit zwischen den Flügen; ob dieselbe Fluggesellschaft verwendet werden muss oder ob unterschiedliche Fluggesellschaften zulässig sind.

Sehen wir uns als Nächstes an, wie BOM verwendet werden kann, um Beziehungen in der Datenmodellierung zu beschreiben.

Beziehungen in der Stücklistenstruktur

Damit meine ich Beziehungen zwischen Menschen, zwischen Organisationen und zwischen Organisationen und Menschen. Dies sind reale Beziehungen, z. B. wenn jemand Mitarbeiter eines Unternehmens oder Mitglied eines Teams ist oder ein Unternehmen ein anderes Unternehmen besitzt. Das konzeptionelle Modell sieht folgendermaßen aus:

Wenn Sie dies direkt einem physikalischen Modell zuordnen würden, hätten Sie Verbindungstabellen für jede der Viele-zu-viele-Beziehungen. Dies kann etwas unübersichtlich werden und hilft nicht beim Ausführen von Abfragen – zum Beispiel beim Finden aller Beziehungen einer Person hat.

Daher ist es wahrscheinlich besser, diese Person und Organization sind verschiedene Arten von Party . Dadurch können wir die drei Viele-zu-Viele-Beziehungen zu einer einzigen vereinfachen:

Wenn Ihre Anforderungen einfach sind, kann dies ausreichend sein. Aber in der realen Welt sind die Dinge in der Regel nicht so einfach. Beispielsweise kann ein Mitarbeiter ein Unternehmen verlassen, um für einige Zeit um die Welt zu reisen. Als er von seinen Reisen zurückkehrt, sucht er Arbeit und wird von der Firma, die er verlassen hat, wieder eingestellt. (Es kommt vor!) Der Arbeitnehmer hat also zwei separate Instanzen einer Beziehung mit diesem Arbeitgeber, jeweils mit unterschiedlichen Wirksamkeitsdaten und möglicherweise mit einer anderen Mitarbeiter-ID.

Die Beziehung selbst erfordert also Attribute. Dies bedeutet eine andere Entität, Relationship , muss sie enthalten:

Auch dies folgt der klassischen Stücklistenstruktur , wobei eine einzelne [übergeordnete] Tabelle zwei Beziehungen zu einer [untergeordneten] Junction-Tabelle hat.

Per Konvention ist in diesem Modell die 1 Der Interagierende ist in der Regel die überlegene Party in der Relationship B. der Arbeitgeber statt des Arbeitnehmers oder der Teamleiter statt des Teammitglieds.

Dieses Parteibeziehungs-Stücklistenmuster kann verwendet werden, um alle Mitarbeiter aufzulisten (2 interactor ) in einer Organisation (1 interactor ) zum vertraglichen Ebene, wenn Sie so wollen. Dies ist eine flache, einstufige Hierarchie. Es kann auch gleichzeitig verwendet werden um die gesamte Management-Berichtsstruktur zu definieren (oder Hierarchie) in derselben Organisation, die beliebig viele Ebenen haben kann. Zum Beispiel:Ein Mitarbeiter kann mehrere Jahre unter einem Vertrag arbeiten, aber in diesem Zeitraum möglicherweise für verschiedene Manager arbeiten (1 Interaktionspartner =verantwortlich für; 2 Interaktionspartner =unterstellt). Er kann sogar gleichzeitig für mehr als einen Manager arbeiten.

So könnten die Daten aussehen (mit ihren jeweiligen Rollen in Klammern):

Lernen Sie die Stückliste kennen

Während die Stückliste strukturiert wird hat seine Wurzeln in der Fertigung, es kann für verschiedene Zwecke verwendet werden , die von streng hierarchisch und eng gekoppelt bis zu ziemlich flach und locker gekoppelt reichen kann.

Ich hoffe, dass diese Beispiele Ihnen helfen, das Stücklistenmuster zu erkennen, falls es in Ihren Projekten vorhanden ist. Sobald Sie das Muster erkennen, werden Sie verstehen, wie es implementiert werden sollte. Sie müssen das Rad nicht jedes Mal neu erfinden – Sie müssen es nur an Ihre spezifischen Anforderungen anpassen.