タグベースの組織で構造を定義する方法は？

StackOverflow https://stackoverflow.com/questions/287839

質問

[旧称：タグベースの組織方法論に関係構造を強制する方法はありますか？]

いくつかのエンティティがあり、それらには一連の属性があります。一部の属性は、エンティティが持つことができる他の属性に影響を与えます。属性の多くはグループに編成され、特定のグループの特定の数の属性、または特定のグループの属性の範囲を持つためにエンティティが必要になる場合があります。

データベースを使用して、要件、グループ化、除外など、これらの種類のタグ間関係をモデル化する方法はありますか、またはプログラムされた「ビジネスルール」でのみ可能ですか？理想的には、可能なタグとそれらの関係を簡単に構成でき、したがって柔軟性が高いことを望んでいます。

私が検討した方法の1つは、タグと可能な関係を持ち、タグとタグを適用した関係の表を取得することですが、これはかなりもろいアプローチのようです。

それで、これはより厳密な方法で可能ですか、もしそうなら、どうすればそれを始められますか？

役に立ちましたか？

解決

編集：他の属性の値にのみ依存して適用される変数属性の説明は、非リレーショナル、非正規化設計です。 RDBMSは、この種のデータを保存するのに最適なソリューションではない場合があります。おそらく、RDFはこのレベルの柔軟性を必要とするデータの優れたソリューションになるでしょう。

RDBMSソリューションに関する以前の回答は次のとおりです。

Entity-Attribute-Value デザインで柔軟な属性をモデル化する人もいます、しかし、これはあまりにも構造化されていないことが多く、データの整合性の問題と戦うことになります。これは、実質的に無限の数のエンティティサブタイプが必要な場合にのみ使用してください。

他の人は単一のテーブル継承を使用します。ここでは、すべてのサブが使用するすべての属性列を配置します-typesを1つの非常に幅の広いテーブルにし、属性がサブタイプに関係のない行ではNULLのままにします。ただし、テーブルの幅が広すぎる可能性があり、すべての属性をNULL可能にする必要があるため、属性を必須にすることができなくなるため、これには制限があります。

エンティティサブタイプの数が比較的少ない場合は、必要な属性のグループごとに依存テーブルを作成することをお勧めします。従属テーブルの主キーを親テーブルへの外部キーとして定義し、1対1の関係を取得します。

CREATE TABLE Vehicles (
  vehicle_id INT PRIMARY KEY
  ...attributes common to all vehicles...
);

CREATE TABLE Automobiles (
  vehicle_id INT PRIMARY KEY,
  ...attributes specific to autos...
  FOREIGN KEY (vehicle_id) REFERENCES Vehicles(vehicle_id)
);

親テーブルの主キーのサブタイプをエンコードすることで、データの整合性をもう少し高めることもできます。これは、 Automobiles の行が Vehicles のオートバイを参照できないようにするためです。

CREATE TABLE Vehicles (
  vehicle_id INT,
  vehicle_type VARCHAR(10),
  ...attributes common to all vehicles...
  PRIMARY KEY (vehicle_id, vehicle_type),
  FOREIGN KEY (vehicle_type) REFERENCES VehicleTypes (vehicle_type)
);

CREATE TABLE Automobiles (
  vehicle_id INT,
  vehicle_type VARCHAR(10) CHECK (vehicle_type = 'Automobile'),
  ...attributes specific to autos...
  FOREIGN KEY (vehicle_id, vehicle_type) 
    REFERENCES Vehicles(vehicle_id, vehicle_type)
);

もちろん、新しいサブタイプを定義するたびに新しい従属テーブルを作成する必要がありますが、この設計では、データの整合性、NOT NULL属性などを強制するためのより多くの構造が提供されます。

アプリケーションロジックで実施する必要がある唯一の部分は、 vehicle_type Vehicles の各行に対して Automobiles の行を作成することです。 code> = 'Automobile'。

他のヒント

ルールを適用するためにデータベースを使用するか、他の場所でソースコードを使用するかに違いはありません。コードはデータです。それが難解なLispの答えです。

あなたが尋ねている本当の質問は、これがリレーショナルデータベースのほうが簡単なのか、それともアルゴル族の言語のほうが簡単かと思います。 RDBMSを指定しなかったため、ANSIを想定します。これが難しくなります。

ところで、これはPrologでは簡単です。しかし、それはここにもそこにもありません。

すべてにチェック制約を使用すると言います。このアプローチに必要な精神的な変化は、UIがこれらのタグ関係を定義する方法を必要とすることを認識することです。従来、UIからDBにCRUDステートメントを発行していました。代わりに、ALTER TABLEステートメントを発行して、CRUDチェック制約を発行する必要があります。

このアプローチには2つの問題があります：

  • このようなステートメントは、ほとんどのRDBMSでパラメーター化できません。 SQLインジェクションについて考えます。
  • 実装は、完全なANSIチェック制約のサポートが異なります。サブクエリがサポートされていない場合は、忘れてください。

特定のRDBMSを使用して質問を明確にできれば、より適切な回答を提供できます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top