カテゴリ間で決定するスーパータイプ/サブタイプ：完全にばらばらまたは不完全な重なり

デスクトップコンピュータ、ラップトップ、スイッチ、ルーター、携帯電話などのITハードウェアを格納するインベントリデータベースを構築しています。すべてのデバイスが単一のテーブルに格納されているスーパータイプ/サブタイプパターンと特定の情報を使用しています。サブタイプのテーブルに入れられます。私のジレンマは、次の2つのデザインから選択しています。

上の図では、すべてのデバイスが共通のサブタイプを共有しています。たとえば、デスクトップコンピューターとラップトップは、次のテーブルのレコードを持ちます：デバイス、ネットワークデバイス。スイッチには、デバイス、ネットワークデバイスのレコードがあります。ルーターは、Device、NetworkDevice、WANDeviceにレコードを持っています。位置情報を追跡するデバイスには、位置情報の記録があります。このセットアップについて私が考えたいくつかの長所と短所：

• 長所：HostnameやLocationIDなどの共通フィールドに基づいてレコードを選択する方が簡単です。
• プロ：nullフィールドはありません。
• 欠点：特定のデバイスのCRUD操作に含める必要があるテーブルは明確ではなく、将来のDBAを混乱させる可能性があります。

下の図では、すべてのデバイスに独自のサブタイプがあります（ここには表示されていないデバイスのクラスがさらにあります）。この状況では、どのテーブルレコードが挿入または選択されるかは明らかです。デスクトップコンピューターとラップトップはコンピューターなどに行きます。このセットアップについて私が考えたいくつかの長所と短所：

• メリット：サブタイプのCRUD操作に使用するテーブルはすぐにわかります。
• メリット：CRUD操作には1つのテーブルのみを使用する必要があります。
• 欠点：共通のサブタイプフィールドに基づいてレコードをSELECTするには、すべてのテーブルを組み合わせる必要があります。たとえば、HostnameやLocationIDによる検索などです。

どちらの状況でも、ClassDiscriminatorフィールドは、CHECK制約で使用できるようにサブタイプテーブルに配置され、挿入できるタイプを制御します。

設計が優れている推奨事項はありますか、それとも完全に意見の問題であり、データベースの意図した目的に依存していますか？

編集：私が持っている特定の質問は、「NetworkDevice」テーブルの重複する性質についてです。このテーブルは、コンピュータ、スイッチ、ルーターなど、ホスト名やIPアドレスを持つデバイスのネットワーク情報を保持するためのものです。このテーブルの重複する性質は問題を引き起こす可能性があるものですか、それともこの方法で実装しても問題ありませんか？

提供された入力について、事前にありがとうございます。追加情報が必要かどうか尋ねてください。

データベースでのサブタイピングの物理的な実装は複雑な問題です。それが説得力のある利点を提供する状況がない限り（1つまたは2つの例については以下を参照）、比較的小さな価値を提供しながら、実装に複雑さを追加します。

これを本当に複雑なサブタイピング（訴訟事件管理システムの適用と判決、異種の複合リスク商業保険契約構造）で行ったので、これについていくつかの観察があると思います。重要なコーナーケースは次のとおりです。

• サブタイプ全体のデータベースフィールドの総数が比較的少ない（たとえば、100未満）場合、またはサブタイプ間にかなりの共通性がある場合、サブタイプを個別の物理テーブルに分割しても、ほとんど価値がありません。レポートのクエリと検索に大きなオーバーヘッドが追加されます。ほとんどの場合、単一のテーブルを用意し、アプリケーション内でサブタイプを管理するのが最善です。 （おそらくあなたの問題に最も近い）

• サブタイプが非常にばらばらであり、さまざまなサブタイプにタイプ依存のデータ構造が付随している場合（つまり、子テーブルまたはより複雑な構造）、サブタイプテーブルは理にかなっています。この場合、各サブタイプのアプリケーション内での共通性は比較的小さいと考えられます（つまり、アプリケーション内には、そのサブタイプ専用のサブシステム全体が存在する可能性があります）。ほとんどのレポートおよびクエリは、特定のサブタイプ内で行われる可能性が高く、クロスタイプクエリは主に少数の共通フィールドに制限されます。 （裁判例管理システム）

• 異種の属性を持つサブタイプが多数ある場合や、これを構成可能にする必要がある場合は、一般的な構造と補足メタデータの方が適切な場合があります。可能なアプローチの概要については、このSOの投稿を参照してください。 （保険契約管理システム）

• サブタイプ間での共通性がほとんどなく、サブタイプテーブル全体でクエリを実行する要件がほとんどない非常に多数のフィールドがある場合（つまり、サブタイプテーブルに対する多方向外部結合の方法では何もない）、サブタイプテーブルは、列のスプロールの管理に役立つ場合があります。 （問題の病理学的に複雑なバージョン）

• 一部のO / Rマッパーは、サブクラスを管理する特定のアプローチのみをサポートする場合があります。

ほとんどの場合、DBスキーマの物理的なサブタイプのテーブルは、望ましくない副作用が発生する可能性があるため、問題を探すための少しの解決策です。

あなたの場合、私はあなたが比較的控えめな数のサブタイプと管理可能な数の属性を持っていると思います。ダイアグラムと質問は、子テーブルをレコードから外すつもりの意図を示していません。上記の最初のオプションを使用して、1つのテーブルを維持し、アプリケーション内でサブタイピングを管理することを検討することをお勧めします。

最初に、David Hay著のEnterprise Model Patternsにあるデータモデリング分類階層のルールを使用して、適切な論理データモデルを開発することを検討してください。分類階層を作成するとき、各オカレンス（行）は1つだけのサブタイプでなければなりません。つまり、サブタイプは相互に排他的です。分類は、単一の基本的な不変の特性に基づく必要があります。この基本的なルールを使用すると、モデルが大幅に明確になります。あなたが持っているモデルでは、分類する単一の特性はデバイスの目的です-電話、ネットワークスイッチ、コンピューター、ルーターなど。各デバイスはこれらのタイプの1つだけである必要があります。たとえば、場所はサブタイプにはなりません。IPアドレスなどの属性はスーパータイプに属します。

別の回答で述べたように、デバイスタイプの数はEAVパターンを保証するのに十分な数になると思います。私が参照しているDavid Hayの本は、このパターンを非常に効果的にカバーしています。ただし、サブタイプの数が少ない場合は、経験則として、null許容列が多数あるスーパータイプテーブルのみ、重複する列があるサブタイプテーブルのみ、またはその両方を実装することを決定できます。各サブタイプの属性が大きく異なり、スーパータイプレベルで関係がない場合は、サブタイプテーブルのみを使用する場合があります。逆のことが当てはまる場合は、スーパータイプのテーブルのみを使用する可能性があります。混在している場合は、両方を実装します。

最後に、EAVパターンをベーステーブルスキーマとして常に実装し、データをスーパーおよびサブタイプのテーブルとしてアプリケーションに提示するビュー抽象化レイヤーを作成できることに注意してください。これにより、ストレージレイヤーでは柔軟性が得られますが、アプリケーションビューレイヤーでは理解しやすくなります。

商品は在庫ではありません。在庫と製品は異なります。

製品は実際には製品の仕様であり、物理的なものではありません。

物理的なものは、会社が所有（または保管）する資産です。シリアル番号で追跡する資産（個別の資産）または数量のみで追跡する資産（在庫資産）を使用できます。

SilverstonのData Model Resource Book Vol 1を見てみましょう。それはあなたに多くの時間を節約します。

私が尋ねる質問の1つは、なぜ在庫アイテムのさまざまな属性を追跡するのですか？-または、より具体的には、この属性情報をどのように処理していますか？

特定の属性の特定の意味を持つ多くのレポートまたはフォームがある場合は、ConcernedOfTunbridgeWellが推奨するアプローチを使用する必要があります。一方、これらの属性は、それらを一覧表示するため、または類似のデバイスの同様の属性と比較するために記録されている場合、実際にはEAVを使用する（まれな）良い言い訳がある可能性があります。「EAVは純粋な悪」であることは知っていますが、特定のアプリケーションでこれらの理由が問題にならない非常にまれなケースは除きます。あなたのようなアプリケーションかもしれません。

設計に関するこの答えを見て、デバイスの在庫システムとの設計に関するこの回答の製品カタログシステム EAVアプローチは、EAVのリスクがある、まさにの議論で、どのように沿ってあなたのアプリケーションを簡素化する方法を参照するにはこれらのリスクが特定のアプリケーションに当てはまらないかどうかを判断します。