14

私は現在、在庫管理と最終製品を組み立てるための購入に役立つプロジェクトに取り組んでいます.

データベースのモデリング段階にあり、要件の 1 つは BOM (部品表) を生成することです。

このスレッドを読み、BOM のデータ モデルの例を見つけました。

概念データ モデルと 物理データ モデル

ここに画像の説明を入力

しかし、完全に理解しているかどうかはわかりません。

最終製品はいくつかのサブアセンブリで構成されているため、各サブアセンブリはproduct_hierarchyテーブルの行であり、最終製品もそのテーブルの行です。各サブアセンブリは個別の (アトミック) パーツから作成され、各パーツはテーブルで識別されますtpart(各パーツにはメーカー フィールド、最小再注文数量、およびその他の特定のフィールドがあります)。

BOM を生成するときは、すべての個別のパーツも含める必要があるため、データベースをモデル化する方法が完全にはわかりません。

  1. 別の部分は、「親」になることのない行ですproduct_hierarchy(テーブル tpart は不要になりました)。
  2. product_hierarchyとの間の N:M 関係tpart: 各ユニットにはいくつかの部分があります。各パーツは複数のユニットに属することができます

部品は基本的にまったく異なるエンティティ (価格、いくつかの可能なサプライヤーなど) であるのに対し、組み立てられたエンティティには外部 (当社の外部など) のプロパティがないため、私は 2 番目の選択肢に傾いています。

どんな入力でも大歓迎です！ありがとう！

4

2 に答える 2

2

2 種類の製品があるようです。1 つは「原子」部分で、もう 1 つは「複合」最終製品です。どちらも異なる情報を必要とするため、これらを 2 つの別々のテーブルに格納します。

CompoundProduct テーブルには、部品を最終製品にリンクする子テーブルも必要です。

必要に応じて、すべての製品 (部品と最終製品) を含む「抽象的な」製品テーブルを作成することもできます。このテーブルには、コードと名前を格納できます。注文または請求書で購入して表示できる製品のテーブルが 1 つあると便利です。次に、Part テーブルと CompoundProduct テーブルの両方が、抽象的な製品テーブルへの外部キーである製品 ID を持つことができますが、Part と CompoundProduct でも一意です。

したがって、一般的に、このデータベース スキームは強力で柔軟性がありますが、十分に完成されていないか、必要に応じて柔軟性が高すぎると思います。

于 2013-07-15T10:05:02.003 に答える