"パーティーモデル"の背後にある原理とそのメリットは何ですか？

Question

「パーティモデル」は、リレーショナルデータベース設計のための「パターン」です。少なくともその一部には、顧客、従業員、パートナーなどの多くのエンティティ間の共通性を見出し、それをいくつかの「抽象的な」データベーステーブルに組み込むことが含まれます。

私は次のように自分の考えを知りたいのです：

1. パーティモデルの背後にある基本原則とやる気力は何ですか？
2. データモデルにはどのようなことが規定されていますか？ （私の上のビットはかなり高レベルであり、ある意味では間違っている可能性があります。私はそれを使ったプロジェクトを行っていましたが、他の問題に焦点を当てた別のチームと一緒に作業していました）
3. あなたの経験から、あなたはそれについて気づかれましたか？あなたはそれを使いましたか？もしそうなら、もう一度やりますか？長所と短所は何ですか？
4. パーティモデルがあなたのORMの選択を制限しましたか？たとえば、ドメインオブジェクトと物理データモデルの間に十分な "抽象レイヤー"がないため、特定のORMを排除する必要がありましたか？

私はすべての回答がこれらの質問のすべてに対処しないと確信しています...しかし、それらの1つ以上に触れるものは私が直面しているいくつかの決定をするのを助けるでしょう。

ありがとうございました。

Answer 1

1. パーティ モデルの背後にある基本原則とやる気力は何ですか？私はそれを使用しました程度に

が、それは主にコードの再利用性と柔軟性についてです。以前はguest/user/adminモデルで使用していましたが、ユーザーをあるグループから別のグループに移動させる必要がある場合には、その価値が確かに証明されます。これをユーザーの下にいる組織や企業にまで広げてください。これは実際にSQLに特有の抽象概念を提供しています。

2. データモデルにはどのような処理が行われますか？ （私の上のビットは かなり高いレベルで、おそらく はいくつかの点で間違っています。私は プロジェクトを使っていましたが、 は別のチームで作業していました ）。

あなたのビットはかなり正しいですが、詳細はもう少し必要です。データベースのエンティティ（党と呼んでいる）が別の党に契約を結ぶ状況を想像することができます。この状況では、作業を外注することができます。当事者は、従業員、契約者、または会社、すべてのサブクラスの党であるかもしれません。私の理解から、あなたはPartyテーブルと、各サブクラスのためのより具体的なテーブルを持っています。さらにサブクラス化することができます（Party - > Person - > Contractor）。

3. あなたの経験から、あなたはそれについて気づかれましたか？あなたはそれを使用しましたか？もし なら、もう一度やりますか？賛否両論は でしたか？

、あなたのシステムに新しいタイプを追加し、新しいレベルに移動する（ユーザーに始まり、建築家に期待していなかったタイプの間の関係を作成するために柔軟に必要がある場合には、雇用企業、その利点を持っています他の会社など）。また、単一のクエリを実行し、複数のタイプのパーティ（企業、従業員、請負業者）のデータを取得する利点があります。一方で、必要なデータにアクセスするための抽象レイヤーを追加し、特定のタイプのクエリを実行するときにデータベースの負荷（または少なくとも結合数）を増やしています。抽象度が高すぎると、複雑さが読みやすさとデータベースの負荷に悪影響を及ぼし始めるため、データを取得するために複数のクエリを実行する必要があります。

4. パーティモデルがORMの選択を制限しましたか？たとえば、 ドメインオブジェクトと物理データ モデルの間に「抽象レイヤー」が十分にありませんでしたので、特定のORMを削除する必要がありましたか？

これは、私は確かでは少し弱いですエリアですが、私は、アプリケーション層でのビューとミラーリング抽象化を使用すると、この問題のあまりなされていないことがわかりました。私にとって本当の問題は、データソースを直接読みたいときに、常に「データXの部分がどこにあるか」ということでした（システム上の新しい開発者にとっても直感的なことではありません）。

Answer 2

私は分かりませんが、パーティモデルは一般化特化パターンの特殊なケースのように聞こえます。 「汎化特化リレーショナルモデリング」を検索すると、興味深い記事が見つかります。

Answer 3

これは膨大なトピックですが、The Data Model Resource Book Volume 3 - Universal Patterns for Data ModelingをLen SilverstonとPaul Agnewが読むことをお勧めします。

私はちょうど私のコピーを受け取りました。それはかなり良いです - それは、ハイブリッドコンテキストロールパターンなどを含むデータモデリングへの多くのアプローチの見落としを提供します。それはあらゆるアプローチのための詳細なPROとCONを持っています。

パーティーの関係と役割をすべてメリットとデメリットでモデル化する方法があります。回答として受け入れられた質問は、「パーティーモデル」の1つのインスタンスをカバーしています。

たとえば、「従業員」、「プロジェクトマネージャ」などの概念は、ロールという特定のコンテキスト内で再生できるという概念です。私は家に帰ると、あなたに良い内訳を与えようとします。

Answer 4

私が1980年代初めにこれらのアイデアを実装しているチームの一員だったとき、まだ発明されていなかったのでORMの選択肢が制限されませんでした。

私はこれまでのところ、「革命的な」アイデア（確か当時のもの）を見た最も説得力のある証明の1つだったので、いつでもそれらのアイデアを取り返したいと思います。

あなたは何もしません。そして、それは何かからあなたを止めません（間違いから、私は意味する）。自分の情報モデルを定義するのはあなたです。

すべての当事者は共通のプロパティを多数持っています。彼らが名前とそのようなものを持っているという事実（私たちはそれらを「シグナル伝達学」と呼んでいます）。主要な/主要な場所が「アドレス」と呼ばれるという事実。彼らがすべて、ある意味で、ビジネスの契約に関わっているという事実。

Answer 5

パーティモデル（別名エンティティスキーマ）の背後にあるアイデアは、スキーマフリーデータベースのスケーラビリティの利点のいくつかを活用するデータベースを定義することです。パーティモデルは、エンティティをエンティティごとに1つのテーブルとは対照的に、パーティタイプレコードとして定義することによってそれを行います。結果は非常に正規化されたデータベースであり、テーブルがほとんどなく、保存するデータの意味的意味についての知識はほとんどありません。その知識はすべてコード内のデータアクセスにプッシュされます。スキーマは決して変更されないため、パーティモデルを使用したデータベースのアップグレードは最小限に抑えられます。これは本質的に、魅力的なキーと値のペアのデータモデル構造で、いくつかの素晴らしい名前と2つの追加の属性を備えています。

長所：

• キックのお尻の水平スケーラビリティ。エンティティモデルで5-6のテーブルを定義したら、ビーチに行き、マーガリータを飲むことができます。このデータベースは、最小限の労力で必要なだけ実際にスケールアウトすることができます。
• データベースは、あなたがそれにスローする任意のデータ構造をサポートしています。アプリケーションに影響を与えずに、データ構造とパーティ/エンティティの定義を即時に変更することもできます。これは非常に強力です。
• スキーマを変更するのではなく、レコードを追加して任意のデータエンティティをモデル化できます。スキーマ移行スクリプトに別れを告げることができます。
• これはプログラマの楽園です。彼らが書いたコードは、コードで使用する実際のエンティティを定義し、オブジェクトからテーブルなどのマッピングはありません。あなたは選択のあなたのフレームワーク（.NET用のSystem.Object）

短所のベースオブジェクトとしてパーティーテーブルと考えることができます：

• パーティー/エンティティモデルオームズとうまくないので、忘れませんEFまたはNHibernateを使用して、意味的に意味のあるエンティティをエンティティデータベースから取得する方法について説明します。
• 多くの結合。パフォーマンスチューニングの課題この「詐欺」は、エンティティを定義するために使用するプラクティスに関連していますが、夜間に悪夢をもたらすような心配するクエリをもっとたくさんすると言えるでしょう。
• 難燃剤。ビジネスに精通していない開発者やDB担当者は、これらのモデルで公開されているエンティティに慣れるのに時間がかかります。すべてが抽象的なので、ダイアグラムやビジュアライゼーションはデータベースの上に構築して、何が他の人に格納されているかを説明することはできません。
• 重いデータアクセスモデルまたはビジネスルールエンジンが必要です。基本的には、ある時点でデータベースから何が必要なのかを理解する作業を行う必要があります。データベースモデルは今度はあなたを助けません。

リレーショナルデータベースでパーティーやエンティティのスキーマを検討している場合は、おそらくNoSqlデータストア、BigTableやKVストアなどの他のソリューションを見てください。この動きを開拓したMongoDB、DynamoDB、Cassandraなど、大規模な展開とトラクションがある優れた製品がいくつかあります。

Answer 6

私の理解からの簡単な話として、パーティーモデリングは柔軟性を提供し、実装するT-SQLジョイントなどのより多くの作業が必要です。
私はパーティモデリング（シリアライゼーション/一般化）を使用すると、FK-Relationを他のテーブルに持つことができます。たとえば：さまざまなタイプのユーザー（管理者、ユーザー、など）を考える）はUserテーブルに一般化されており、テーブルにUserIDを持つことができます。