概念的なERDマルチテーブル多対多、またはおそらく再帰？
概念図を作成しています[そうです、属性とキーが含まれていることは知っていますが、これは、学習中に行っていることを統合するためだけのものです]-したがって、関係と図表の作成方法ではなく表;）
私の心のハードルは次のとおりですプロファイル、場所、および組織の関係をモデル化する最良の方法を確認しようとしています。
まず第一に、ルール：
- 1つ以上のProfileは、1つ以上のメンバー/友達にすることができますOrganizations;およびその逆。
- 1つ以上のProfileは、他のプロファイルのメンバー/フレンドになることができます。
- 1つ以上のOrganizationは、他の組織のメンバー/友達になることができます。
FriendとMemberは異なります。Friendsは読み取り専用のようなものであり、[レベルに応じて]メンバーは修正するためのフルアクセス権を持っています。
さらに物事を複雑にするために、Locationsには、独自の「さらに」洗練されたルールのセットがあります。 Organizationは2つのLocationsを所有しますが、場所のルールによっては、その組織のメンバー[Profile]が1つの場所でフルアクセスを持つことができますが、他でのアクセス制限。 [申し訳ありません。表示サイズを上げるには、別のウィンドウで画像を開く必要があります。]
ご覧のとおり、プロファイルと組織の概念はほとんど同じですが、これはまだモデル化されていない友達とメンバーの概念です（... Ownerを設定した現在の中間テーブルのように処理されると思います）。レコード内の管理者/メンバー/友達など]。したがって、なぜ私は次の概念を考えているのですか。
上の画像のOption.2：を参照すると、現在のOrganizationおよびOrganization_Locationsテーブルとその関係が削除され、Option.2に置き換えられます。 Profileとのやや再帰的な関係としての組織テーブル。
問題の核心は、私が多態性をプログラム的に気にしすぎて、単純さと柔軟性を損ない、プロセスで完全に混乱しているのかどうかだと思います;）
事前にあなたの考えをありがとう、大いに感謝-M :)。
改訂された図： 
MDCCLの質問への回答：
- はい、Profileは1人の人物で構成され、同じ意味を持っています-あなたの理論的根拠はどこに向かっています-私はあなたが正しいと信じています：Organization and PersonはProfileのサブタイプである可能性があります。したがって、プロファイルは1人または1つの組織で構成されます。
- プロファイルごとに1つのメールアドレス。
- はい。上記のように、組織には少なくともメールアドレスが必要です。
- 正しい、1つの固定アドレス。
- それは可能性ですが、希少性-私が学んでいることから-したがって、将来の寿命などのためにそのようなモデルを作成する必要があります。したがって、確認するだけで、ロケーションは複数の人によって所有される可能性があります。
場所は間違いなく他のほとんどの間の不可欠なエンティティです。おそらく、ここで簡潔に何ができるかを明確にして、この質問への有益な追加に最初に関係する可能性のある他の回答を最初に読んでから、[、最後に＃6への私の回答を見てみましょう];）Re：役割の所有者
An **Organization** can be an Owner of zero or more **Locations**.A Person can be an owner of zero of more Locations[したがって、以前に推測したとおり。簡単に言えば、Profileは0個以上のLocation/sの所有者になることができます。はい、場所の所有者であるプロファイルは、すべての役割パーミッション[スーパーユーザー]; a Profileつまり、AdminはLocationの特定の詳細を修正できますが、主に役立ちます/他のすべてを介して提供される詳細/データを編集しますProfile/s-これは主に 'Basic Member/s'によって提供されます上記の場所/s;これにより、基本メンバーが残り、関連するすべてのLocation詳細を読み取り専用にして、Admin/Owner。これを超えて、任意のProfile [Organization/Person]は、Basic Member 'read-only'によく似ています-それらを用語にしましょうaGuest-ただし、場所がPublicとして設定されている場合のみ[およびPrivate]ではありませんが、Basic Member できる。
- 正しい。
- あなたの直感は素晴らしいです！はい、
it is foreseen that a single Location could contain one to many LocationTypes-さらに物事を複雑にするために-それらの個々のLocationTypeは、「親」の場所に関連付けられたプロファイルに対してさまざまな権限を持つことが予想されます。このうち、権限はLocationからLocationType/sにフィルターダウンします（OSフォルダーのセキュリティ権限と同様）。あなたの図では、説明としてタイプをもっと参照しているかもしれませんが、 - はい。
- 12を参照してください。
- 正解です。Profile1 [個人または組織]が行動する能力Profile2 [個人または組織]が所有場所 [友達/正しい権限を持つメンバー]が最も重要です。
- 非常に合理的-a）同意する。 b）同意します。 c）はい、うーん？...おそらくProfile [person] to Profile [person] =-とほぼ同じになるはずです友達。 Organization/sは他のOrganizationLocation/sに作用するため、説明が何であれ、それはLocationを中心に展開します。 ;意味論的には、組織がその場所の組織の「メンバー」として従属して見えるようにしたいと思うのではないかと思います。「原因がどれほど良いかに関係なく」
[6]。これはまだ私には少し灰色ですが、ここに行きます...おそらく私の不利益のために、メンバー/友達の関係の類似性は非常に近いため、それらを組み合わせると考えました。ダイアグラムと解釈を振り返って、それらを分離しておくのが正しいように思われる[enumプロパティを介して単一の関係を区別するつもりだった：Owner/Admin/Member/Friend]。たとえば、あなたのコンセプト：組織が所有する場所は0から多くのプロファイル[個人または組織]に作用しますが、プロファイルが関係[メンバーまたは友人]を介して位置に作用する方法には明確な違いがあるはずです] Rolesで示されます。 So perhaps, the default relation between any Profile is Friend [much like Guest at Answer#7], enabling them to view the read-only Location data and msg/email the Location Owner/Admin - but not allow them to receive Location updates, news, etc., as a Member would.
問題の理解を深めるのに役立たない方法で、オブジェクトモデリングの概念とデータモデリングの概念を混ぜ合わせようとしていると思います。散らかしすぎずに、混乱を少しでも解消できるといいのですが。
リレーショナルモデル自体は継承をサポートしていないため、ポリモーフィズムは考慮されません。つまり、オブジェクトモデルの継承とポリモーフィズムによって簡単に処理できる実際の状況をモデル化するときには、かなり特殊な設計パターンを使用する必要があります。この特別なデザインパターンについては、後で詳しく説明します。
ERモデルが最初に開発されたとき、それはリレーショナルモデリングの実装にとらわれない代替手段であると想定されていました。最初は、継承のようなものもありませんでした。しかし、1980年代または1990年代のある時点で、モデルは継承によって得られるのと同じ表現能力のいくつかを提供するように拡張されました。これは「拡張ERモデル」として知られていましたが、実際の目的のために、今日のERモデルにはEER機能が含まれています。
EER機能の1つに、「一般化/特殊化」という名前があります。 Webでこの概念を検索して読むことができます。 Gen-specは、クラスとサブクラスがオブジェクトモデルで提供するものとほぼ同じ表現機能を提供します。ただし、Gen仕様では、Gen仕様の状況でのリレーショナルテーブルの設計に関する問題は扱われていません。詳細は後ほど。
ERモデリングでは、関係には常に同じエンティティが含まれます。したがって、組織とプロファイルの間の友達関係は、プロファイルと別のプロファイルの間の友達関係と同じではありません。 2つの関係には異なる名前が必要です。このルールに従わない場合は、結び目を作るだけです。
または、組織、プロファイル、そして場合によっては場所がすべて特殊化されている一般化されたエンティティを考え出す必要があります。私はあなたを助けるのに十分あなたのケースを理解していません。
次に、リレーショナルモデルとERモデルを1つのモデルに結合していることに気づきました。ほとんどの熟練したデータベースアーキテクトがこれを行います。ただし、熟練するまでは、2つのモデルを別々にしておくことをお勧めします（ただし、互いに調整されます）。
最後に、gen-specの状況を表すリレーショナルテーブルをどのように設計しますか？これらの2つの設計パターン「クラステーブル継承」と「単一テーブル継承」を調べてみてください。 Stackoverflowには、これらのタグが2つあります。また、パターンのかなり良いプレゼンテーションがウェブ上にいくつかあります。私は特にマーティン・ファウラーの扱いが好きです。オブジェクトモデラーの考え方を知っているようです。お役に立てれば。