データベース内の部品表（BOM）構造の識別

部品表（BOM）のデザインパターンは一見シンプルですが、信じられないほど強力です。歴史的に、これは製品構造のモデル化に使用されてきましたが、パターンは単に階層を定義する以上のことを行うために使用できます。この記事では、自分のプロジェクトのパターンを認識するのに役立つ3つの非常に異なる例を紹介します。

部品表（BOM）とは何ですか？

部品表 製造業にルーツがあります。これは、原材料、サブアセンブリ、中間アセンブリ、サブコンポーネント、部品、および最終製品の製造に必要なそれぞれの数量のリストです。これは、製品の階層的な分解と見なすことができます。同じことの他の用語は、製品構造、部品表、および関連リストです。

BOMを説明するために、以下の概念モデルを見てください。それはトップレベルの製品であるCarから始まります 。大まかに言えば、Car Engineがあります およびBody 。この例では、V6とV8のさまざまなタイプのエンジンがあります。ボディには、3ドア、5ドア、エステート（ワゴンまたはステーションワゴンとも呼ばれます）のさまざまなタイプがあります。分解のプロセスは、最後のナットとボルト、または接着剤の軽くたたくまで下がることがありますが、全体像を把握できます。

最も単純なレベルでは、階層の最上部から最下部まで、2つの部分を階層の形で結合します（親部分から子部分）。最も基本的な製造BOMモデルは次のようになります：

これは従来のBOM構造です 、ここで、単一の[親]テーブルには[子]ジャンクションテーブルとの2つの関係があります。

車の例の簡単な製品階層は次のとおりです。

製造業のBOMは、同じ種類の主要な特性を持つ傾向があります：

• アセンブリ、サブアセンブリ、および個々のコンポーネントは再利用できます 。たとえば、同じ種類のボルトをさまざまな種類のアセンブリで使用できます。
• 多くの場合、階層固有の数量が必要です。 。たとえば、1つのアセンブリには10本のボルトが必要ですが、別のアセンブリには同じ仕様の15本のボルトが必要になる場合があることを知っておくことが重要です。

アセンブリを定義すると、その構造は、それを使用する他のアセンブリに自動的にインポートされます。したがって、そのアセンブリが変更された場合、それを使用する他のすべてのBOMは自動的に更新されます。このようなサブアセンブリを記述するBOMは、モジュラーBOMと呼ばれます。 。

製造業者にとって、BOMは製品情報の重要な部分であり、製品の製造に必要なすべてのものをリストするレコードです。 構成可能を処理するには、高度なモデリング手法が必要です 製品、コンポーネントバリエーション 、または代替 コンポーネント。製品のごく一部を変更すると、他の製品BOMに複数の影響を与える可能性があります。これらを考慮しないと、BOM管理が非常に管理不能になる可能性があります。

ただし、この専門分野はこの記事の範囲を超えています。代わりに、データベース設計でBOM構造が発生する可能性のある場所の例に焦点を当てます。 BOMを認識できるようになると、この強力なデザインパターンを利用できるようになります。

一般的な例から始めましょう。フライトと空港の間の多対多の関係です。

部品表パターンはフライトと何の関係がありますか？

概念モデルは次のとおりです。

世界のどの空港でも想像してみてください。そこから、他の目的地に向けて離陸する飛行機を見ることができます。また、他の目的地から着陸する飛行機も表示されます。したがって、出発空港と到着空港の間には多対多の関係があります。

通常、ジャンクションテーブルを使用してこの多対多の関係を解決します。

Flight クラスには、flightNumberなどの独自の属性があります 、scheduledDepartureTime 、およびscheduledArrivalTime 。

モデルを振り返ると、小さな問題が見つかる可能性があります。 DepartureAirport またはArrivalAirport 。どちらも、フライトの出発地と到着地の空港にすぎません。

そこで、DepartureAirport およびArrivalAirport 単一のairport このようなテーブル：

繰り返しますが、これは従来のBOM構造に従います。 、ここで、単一の[親]テーブルには[子]ジャンクションテーブルとの2つの関係があります。

ただし、概念的には、これと製造BOMには大きな違いがあります。このBOMには真の階層構造はありません。完全に平らです。なぜ私はこれを言うのですか？

例として最もよく説明されています。

まず、このBOMのサンプルデータについて考えてみましょう。

次に、例を見ていきます。マンチェスターからチェンナイまで飛行機で行く必要があると想像してみてください。直行便はありません。しかし、あなたはマンチェスターからドバイまで飛ぶことができます。それはあなたの旅の最初の行程です。その後、ドバイからチェンナイへの別のフライトに乗ることができます。これは、旅の2番目の区間です。 2つのレッグが旅程を形成しますが、2番目のレッグが最初のレッグのサブコンポーネントのようなものではありません。したがって、この構造はフラットです。

ただし、1：1のデータの対応に注意してください 部品とフライトの例の間：車→マンチェスター;エンジン→ドバイ;チェンナイ→V6。

車の例では、パーツは密結合の階層を形成します。 。空港の例では、フライトをトラバースして、より多くの緩く結合された接続を形成できます。 フライト間。マンチェスターからチェンナイに飛ぶ乗客の場合、旅程を作成する必要があります。これは、接続を構成するものを考慮に入れたクエリの結果です。フライト間の最小時間と最大時間。同じ航空会社を使用する必要があるかどうか、または異なる航空会社が許可されているかどうか。

次に、BOMを使用してデータモデリングの関係を記述する方法を見てみましょう。

BOM構造の関係

これは、人と人との関係、組織と人と人との関係を意味します。これらは、誰かが会社の従業員またはチームのメンバーである、あるいは別の会社を所有している会社のような、現実の関係です。概念モデルは次のようになります：

これを物理モデルに直接マッピングする場合は、多対多の関係ごとにジャンクションテーブルがあります。これは少し雑然となる可能性があり、クエリの実行には役立ちません。たとえば、すべての関係をPerson 持っています。

したがって、Person およびOrganization さまざまな種類のParty 。これにより、3つの多対多の関係を1つの関係に単純化できます。

要件が単純な場合は、これで十分な場合があります。しかし、現実の世界では、物事はそれほど単純ではない傾向があります。たとえば、従業員が会社を辞めて、しばらくの間世界中を旅行する場合があります。彼が旅行から戻ったとき、彼は仕事を探し、彼が去った会社によって再雇用されます。 （それは起こります！）したがって、従業員には、この雇用主との関係の2つの別個のインスタンスがあり、それぞれが異なる発効日を持ち、場合によっては異なる従業員IDを持ちます。

したがって、関係自体には属性が必要です。これは、別のエンティティ、Relationship 、それらを含める必要があります：

繰り返しますが、これは従来のBOM構造に従います。 、ここで、単一の[親]テーブルには[子]ジャンクションテーブルとの2つの関係があります。

慣例により、このモデルでは1 インタラクターは優れたParty Relationship 従業員ではなく雇用主、またはチームメンバーではなくチームリーダーなど。

このパーティ関係のBOMパターンを使用して、すべての従業員を一覧表示できます（2 interactor ）組織内（1 interactor ）契約 あなたがそうするならレベル。これはフラットな単一レベルの階層です。 同時に使用することもできます 管理レポート構造全体を定義する （または階層）同じ組織で、任意の数のレベルを持つことができます。たとえば、従業員は1つの契約の下で何年も働いていても、その期間中はさまざまなマネージャーで働いていることに気付く場合があります（1人のインタラクター=責任者、2人のインタラクター=報告先）。彼は複数のマネージャーのために同時に働くことさえあります。

データは次のようになります（括弧内にそれぞれの役割があります）：

BOMを理解する

部品表の構造 製造業にルーツがあり、さまざまな目的に使用できます 、厳密に階層的で緊密に結合されたものから、かなり平坦でより緩く結合されたものまでさまざまです。

これらの例が、プロジェクトにBOMパターンが存在する場合にそれを認識するのに役立つことを願っています。パターンを認識すると、それをどのように実装する必要があるかがわかります。ホイールを毎回再発明する必要はありません。特定の要件に合わせて調整する必要があります。