カテゴリ間で決定するスーパータイプ/サブタイプ：完全にばらばらまたは不完全な重なり
デスクトップコンピュータ、ラップトップ、スイッチ、ルーター、携帯電話などのITハードウェアを格納するインベントリデータベースを構築しています。すべてのデバイスが単一のテーブルに格納されているスーパータイプ/サブタイプパターンと特定の情報を使用しています。サブタイプテーブルに配置されます。私のジレンマは、次の2つのデザインから選択しています。
上の図では、すべてのデバイスが共通のサブタイプを共有しています。たとえば、デスクトップコンピューターとラップトップは、次のテーブルのレコードを持ちます：デバイス、ネットワークデバイス。スイッチには、Device、NetworkDeviceのレコードがあります。ルーターは、Device、NetworkDevice、WANDeviceにレコードを持っています。場所を追跡するデバイスはすべて、場所に記録されます。このセットアップについて私が考えたいくつかの長所と短所：
- 長所：HostnameやLocationIDなどの共通フィールドに基づいてレコードを選択する方が簡単です。
- プロ：nullフィールドはありません。
- 欠点：特定のデバイスのCRUD操作に含める必要があるテーブルは明確ではなく、将来のDBAを混乱させる可能性があります。
下の図では、すべてのデバイスに独自のサブタイプがあります（ここには表示されていないデバイスのクラスがさらにあります）。この状況では、どのテーブルレコードが挿入または選択されるかは明らかです。デスクトップコンピューターとラップトップはコンピューターなどに入ります。このセットアップで考えたいくつかの長所と短所：
- メリット：サブタイプのCRUD操作に使用するテーブルはすぐにわかります。
- メリット：CRUD操作に使用する必要があるテーブルは1つだけです。
- 欠点：一般的なサブタイプフィールドに基づいてレコードをSELECTするには、すべてのテーブルを組み合わせる必要があります。たとえば、HostnameやLocationIDによる検索などです。
どちらの場合も、ClassDiscriminatorフィールドは、CHECK制約で使用できるようにサブタイプテーブルに配置され、挿入できるタイプを制御します。
設計が優れている推奨事項はありますか、それとも完全に意見の問題であり、データベースの使用目的に依存していますか？
編集：テーブル「NetworkDevice」の重複する性質に関して私が特定の質問をしました。このテーブルは、コンピューター、スイッチ、ルーターなど、ホスト名やIPアドレスを持つデバイスのネットワーク情報を保持するためのものです。このテーブルの重複する性質は問題を引き起こす可能性があるものですか、それともこの方法で実装しても問題ありませんか？
提供された入力について、事前に感謝します。追加情報が必要かどうか尋ねてください。
データベースでのサブタイピングの物理的な実装は複雑な問題です。説得力のある利点を提供する状況（以下の1つまたは2つの例を参照）がない限り、実装はより複雑になりますが、価値はほとんどありません。
これを本当に複雑なサブタイピング（訴訟事件管理システムの適用と判決、異種の複合リスク商業保険契約構造）で行ったので、これについていくつかの観察があると思います。重要なコーナーケースは次のとおりです。
サブタイプ全体のデータベースフィールドの総数が比較的少ない（たとえば、100未満）場合、またはサブタイプ間にかなりの共通性がある場合、サブタイプを個別の物理テーブルに分割しても、ほとんど価値がありません。レポートのクエリと検索に大きなオーバーヘッドが追加されます。ほとんどの場合、単一のテーブルを用意し、アプリケーション内でサブタイプを管理するのが最善です。 （おそらくあなたの問題に最も近い）
サブタイプが非常にばらばらであり、さまざまなサブタイプにタイプ依存のデータ構造が付随している場合（つまり、子テーブルまたはより複雑な構造）、サブタイプテーブルは意味があります。この場合、各サブタイプは、アプリケーション内での共通性が比較的少ない可能性があります（つまり、アプリケーション内には、そのサブタイプ専用のサブシステム全体が存在する可能性があります）。ほとんどのレポートとクエリは、特定のサブタイプ内で行われる可能性が高く、クロスタイプクエリは主に少数の共通フィールドに制限されます。 （裁判管理システム）
異種の属性を持つサブタイプが多数ある場合や、これを構成可能にする必要がある場合は、一般的な構造と補足メタデータがより適切な場合があります。いくつかの可能なアプローチの詳細については this SO posting を参照してください。（保険ポリシー管理システム）
サブタイプ間での共通性がほとんどなく、サブタイプテーブル全体でクエリを実行する要件がほとんどない非常に多数のフィールドがある場合（つまり、サブタイプテーブルに対する多方向外部結合の方法では何もない）、サブタイプテーブルは、列のスプロールの管理に役立ちます。 （問題の病理学的に複雑なバージョン）
一部のO/Rマッパーは、サブクラスを管理する特定のアプローチのみをサポートする場合があります。
ほとんどの場合、DBスキーマの物理サブタイプテーブルは、望ましくない副作用が生じる可能性があるため、問題を探す上で少し解決策になります。
あなたの場合、私はあなたが比較的控えめな数のサブタイプと扱いやすい数の属性を持っていると思います。ダイアグラムと質問は、子テーブルをレコードから切り離す意図を示していません。上記の最初のオプションを使用して、1つのテーブルを維持し、アプリケーション内でサブタイピングを管理することを検討することをお勧めします。
まず、David Hayの本 Enterprise Model Patterns にあるデータモデリング分類階層のルールを使用して、適切な論理データモデルを開発することを検討してください。分類階層を作成する場合、各オカレンス（行）は1つだけのサブタイプでなければなりません。つまり、サブタイプは相互に排他的です。分類は、単一の基本的な不変の特性に基づく必要があります。この基本的なルールを使用すると、モデルが非常に明確になります。あなたが持っているモデルでは、分類する単一の特性はデバイスの目的です-電話、ネットワークスイッチ、コンピューター、ルーターなど。各デバイスは、これらのタイプの1つだけである必要があります。たとえば、場所はサブタイプではありません。 IPアドレスなどの属性はスーパータイプに属します。
別の回答で述べたように、デバイスタイプの数はEAVパターンを保証するのに十分な数になると思います。私が参照しているDavid Hayの本はこのパターンを非常に効果的にカバーしています。ただし、サブタイプの数が少ない場合は、経験則として、null許容列が多数あるスーパータイプテーブルのみ、列が重複しているサブタイプテーブルのみ、またはその両方を実装することを決定できます。各サブタイプの属性が大きく異なり、スーパータイプレベルで関係がない場合は、サブタイプテーブルのみを使用する場合があります。逆のことが当てはまる場合は、スーパータイプのテーブルのみを使用する可能性があります。混在している場合は、両方を実装します。
最後に、EAVパターンをベーステーブルスキーマとして常に実装し、データをスーパーおよびサブタイプのテーブルとしてアプリケーションに提示するビュー抽象化レイヤーを作成できることに注意してください。これにより、ストレージレイヤーでは柔軟性が得られますが、アプリケーションビューレイヤーでは理解しやすくなります。
商品は在庫ではありません。在庫と製品は異なります。
製品は実際には製品の仕様であり、物理的なものではありません。
物理的なものは、会社が所有（または保管）する資産です。シリアル番号で追跡する資産（個別の資産）または数量のみで追跡する資産（在庫資産）を使用できます。
SilverstonのData Model Resource Book Vol 1を見てみます。彼には、proudcts、機能、価格、在庫についての優れたスキーマがあります。それはあなたに多くの時間を節約します。
私が尋ねる質問の1つは、在庫アイテムのさまざまな属性を追跡する理由です。 -または、より具体的には、この属性情報で何をしていますか？
特定の属性の特定の意味を持つ多くのレポートまたはフォームがある場合は、ConcernedOfTunbridgeWellが推奨するアプローチを使用する必要があります。一方、これらの属性は、それらを一覧表示するため、または類似のデバイスの同様の属性と比較するために記録されている場合、実際にはEAVを使用する（まれな）良い言い訳がある可能性があります。 「EAVは純粋な悪」であることは多くの理由でわかりますが、特定のアプリケーションでこれらの理由が問題にならない非常にまれなケースは除きます。あなたかもしれないそのようなアプリケーションかもしれません。
デバイスインベントリシステム の設計に関するこの回答と 製品カタログシステム の設計に関するこの回答を見て、EAVアプローチによってアプリケーションをどのように簡素化できるかを確認してくださいEAVのリスクが正確に何であるか、およびそれらのリスクが特定のアプリケーションに適用されない可能性があるかどうかを判断する方法について説明します。