概念図を作成しています[そうです、属性とキーが含まれていることは知っていますが、これは、学習中に行っていることを統合するためだけのものです]-したがって、関係と図表の方法ではなく表;）

私の心のハードルは次のとおりです。 私は、プロファイル、場所、および組織の関係をモデル化する最良の方法を確認しようとしています。

まず、ルール：

• 1つ以上のプロファイルは、1つ以上の組織のメンバー/友達になることができます。およびその逆。
• 1つまたは複数のプロフィールを他のプロフィールのメンバー/友達にすることができます。
• 1つ以上の組織が他の組織のメンバー/フレンドになることができます。

FriendとMemberは異なります。Friendsは読み取り専用のようなものであり、[レベルに応じて]メンバーは変更するためのフルアクセス権を持っています。

さらに複雑なことに、ロケーションには独自の「さらに」洗練されたルールのセットがあります。たとえば、組織は2つのロケーションを所有しますが、ロケーションルールによっては、その組織のメンバー[ プロファイル ]が1つのロケーションでフルアクセスできますが、その他。[申し訳ありませんが、表示サイズを上げるには、別のウィンドウで画像を開く必要があります。]

ご覧のように、プロファイルと組織の概念はほとんど同じです。これは、モデル化されていない友達とメンバーの概念です。[...オーナー/レコード内の管理者/メンバー/友達など]。したがって、なぜ私は次の概念を考えているのですか？

上の画像のOption.2を参照してください。これは、現在の組織とOrganization_Locationsテーブルとそれらの関係を削除し、プロファイルとのやや再帰的な関係としてOption.2組織テーブルに置き換えます。

問題の核心は、私が多態性をプログラム的に気にしすぎて、単純さと柔軟性を損ない、プロセスで完全に混乱しているのかどうかだと思います;）

事前にあなたの考えをありがとう、大いに感謝-M :)。

改訂された図：

MDCCLの質問への回答：

1. はい、プロフィールは1人の人物で構成され、同じ意味を持っています-あなたの理論的根拠が向かっているところに-私はあなたが正しいと信じています：組織と人物はプロフィールのサブタイプである可能性があります。したがって、プロファイルは1人または1つの組織で構成されます。
2. プロファイルごとに1つのメールアドレス。
3. はい。上記のように、組織には少なくともメールアドレスが必要です。
4. 正しい、1つの固定アドレス。
5. それは可能性ですが、まれです-私が学んでいることから-したがって、将来の寿命などのためにそのようなモデルを作成する必要があります。したがって、確認のために、ロケーションは複数の人が所有することができます。

6. 場所は間違いなく他のほとんどの間の不可欠なエンティティです。おそらく私はここで簡潔に何ができるかを明確にし、次にこの質問への有益な追加にうまくいけば私の他の答えを最初に読んでみましょう[ そして最後に＃6への私の答えを見てください ];）Re：役割の所有者 An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[したがって、以前に推測したとおり。簡単に言えば、プロファイルは0個以上のロケーションの所有者になることができます。

7. はい、ロケーションの所有者であるプロファイルは、すべてのロール権限[スーパーユーザー]を想定しています。プロファイルで管理者は、特定の細部修正できる場所が、主に他のすべてを介して供給された詳細/データ編集/助けプロファイルを/ S -これは主によって供給される「基本メンバー/ s」が言ったの場所 /秒; これにより、Basic Memberが残り、関連するすべての場所の詳細を読み取り専用にして、管理者/所有者が精査する必要のあるデータを提供できます。これを超えて、任意のプロファイル[組織/人]よく似ている基本的なメンバーの「読み取り専用」 - LETの任期それらユーザーレビュー -しかし、場所は次のように設定されている場合にのみ公開 [なくプライベート彼らのような入力を供給することができないものの、] 基本メンバー缶を。

8. 正しい。
9. あなたの直感は素晴らしいです！はい、it is foreseen that a single Location could contain one to many LocationTypes-さらに複雑にするために-それらの個々のLocationTypeは、「親」の場所に関連付けられたプロファイルに対してさまざまな権限を持つことが予想されます。このうち、アクセス許可はLocationからLocationType / sにフィルターダウンします（OSフォルダーのセキュリティアクセス許可のように）。ダイアグラムを介して、タイプとしてより多くのことを説明として参照している可能性があることに気付きましたか？
10. はい。
11. 12を参照してください。
12. 正しい、のための能力というプロファイルに基づいて行動するために、[個人または組織] プロファイル2 [個人または組織]が所有する場所 [彼らは適切な権限を持つている友達/メンバーがあれば]最も重要です。
13. 非常に合理的-a ）同意する。b）同意する。c）はい、うーん？...おそらく、プロファイル [人]からプロファイル [人] = 友達とほとんど同じである必要があります。どのような説明でも、組織 / sは他の組織の場所 / sに作用するため、場所を中心に展開します。意味的にはですが、「原因がどれほど良いかに関わらず」、組織がその場所の組織の「メンバー」として従属していることを望んでいるとは思えません。

[6]。これは私にはまだ少し灰色ですが、ここに行きます...おそらく私の不利益のために、メンバー/友達の関係の類似性は非常に近いため、それらを組み合わせると考えました。ダイアグラムと解釈を振り返ってみると、それらを分離しておくのが正しいようです[ 列挙型プロパティを介して単一の関係を区別しようとしました：所有者/管理者/メンバー/友達 ]。たとえば、あなたのコンセプト：組織が所有する場所は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.

私の個人的な経験から、これによりすべての開発プロセスが簡単になり、将来の変更に非常に柔軟になるため、扱うデータを理解、分類、モデル化するのに時間をかけていることは素晴らしいことです。そして、あなたもあなたがすでにこれを知っていると確信しています。

予備的なデータモデルと想定されるビジネスルール

私はあなたの仕様を理解するために、あなたの質問を読み、ダイアグラムを綿密に調べた後に想定したビジネスルールのリストを定義しました。そのようなリストを定義した後、外部プラットフォーム（Dropbox）に.PDF文書としてアップロードすることを決めたIDEF1X ^[1]データモデルを派生させました。これは、その形式のため、このデータモデルは埋め込み画像にうまく適合しないためです。これらの2つの手段は、前進を続けるために解決すべき側面というタイトルのセクションで以下に列挙するいくつかの重要なポイントの参照として役立ちます。

まず、これは…

• 組織とプロファイル予備データモデル。

それはあくまでも予備的なものなので、目的の最終データモデルを完成させるための手段として考えてください。

想定されるビジネスルール

上記の予備的なデータモデルは、次のように列挙するビジネスルール（質問から推測）のコレクションから派生したものです。

組織とプロファイル

注Profile現在の同義語として理解されていますPerson。

• アンはOrganizationの友人である一対多 Profiles。
• アンはOrganizationの友人である一対多 Organizations。
• アンはOrganizationのメンバーである一対多 Organizations。
• AはProfileのメンバーである一対多Organizations。
• AはProfileの友人である一対多 Profiles。
• AはProfileのメンバーである一対多 Profiles。

場所と住所

• Organizationは1 対多を所有しLocationsます。
• A Locationは1対多 LocationTypes（特定の時点で1つだけ）で分類されます。
• Location有していてもよい一対多 Addresses（1 Physical、1のためにShipping、1のためにBilling、または1つすべての前記の目的を果たす、または1つをそのコンバイン二つの目的と機能する別の唯一それらのを）。

• Address保持されてもよい1対多 Profilesまたは、別の言い方を、Profile続けて1対多 Addresses。

• 特定をAddressして使用してもよい一対多 Profiles（として機能Physicalするための1 Profileのために使用されているBillingことによって異なるものなど）。したがって、およびのAddress場合Locationsと同様に動作しProfilesます。

  • したがって、個人Addressは、同時に、タイプPhysical、Shipping および である可能性がありBillingます。

場所と役割

• A Locationは1対多で 開きますRoles。
• A Roleは1対多 で実行できますLocations。
• Aは、Profile（それはのようにセットされた後MemberのOrganization）を行うことができる1対多数 Rolesで、一対多 Locations（しかし唯一の特定のRole各々におけるLocation特定の時点で、すなわち、決して二つ以上 Rolesを同時に）。

前進し続けるために解決すべき側面

データモデルの解像度を向上させるために、関連するポイントのリストを以下に示します。これらのポイントは、解決したら、この目標を達成するのに役立ちます。

1. Profileあなたの文脈での用語はの用語と同様（または同じ）の意味を持つと想定しましたPersonが、少し異なる場合があります。このように、あなたのシナリオでは、エンティティOrganizationとPersonサブタイプはProfile何ですか？

2. 缶Profile（またはPerson）独自の一対多 EmailAddresses、またはであるProfile（またはPerson）に固定され、正確に1 EmailAddress？

3. あなたはのための可能性を提供したいと考えOrganization介して接触させるTelephoneとEmail、またはあなたはそれが唯一の可能であることを制限したいProfile（またはPerson）？

4. 私はa Locationがタイプの1つ Addressに固定されていると思いPhysicalますが、これは正しいですか？

5. a Locationを1対多の異なるで共有することは可能ですOrganizations か、そうでなければ、1だけLocationが所有できますか？ Organization

6. a Memberとa であるという事実はFriend同じであるとコメントで述べました。あなたが私の提案の予備的データモデルで見ることができるように、私はあなたに、元の仕様を踏襲し、会員のすべての可能な組み合わせを示したと友情の間OrganizationおよびProfile（またはPerson私はそれが可能な限り最高の定義の努力に役立つことができることを考えているので、異なるエンティティで）シナリオのその部分の構造。この意味で：

   • an Organization is a Member of another Organizationこの声明a Profile (or Person) is a Member of an Organizationは、と呼ばれるエンティティに関する声明とは異なる効果があると思いLocationます。
   • あなたはデータモデルに見ることができるように、私はと思うRoleのは、Ownerのためにのみ有効であるOrganizationと、私には、有効なRolesためProfile（またはPerson）、内側にLocationあるAdminとMember。これについてどう思いますか？あなたはあなたの状況に適用されるビジネスルールに直接接触しているので、私の仮定が正しいかどうか教えてください。

7. Profile（またはPerson）Roles同じ内部で異なるプレイはできますLocationか？つまり、a Personは同時に、AdminaもaもMember同じLocationですか？これに関するルールは何ですか？

8. 同じProfile（またはPerson）が別ので異なっRolesて遊ぶことができると思いますLocations。例えば：特定Profile（またはPerson）で「管理者」であり、Location「1」、及びこの同じProfile（又はPerson）「があるMember」にLocation同時に、「2」。私は正しいですか？

9. 特定の人LocationがLocationTypes同時に別の人を持つことは可能ですか、それとも個人Locationが1人だけを保持するように固定されていLocationTypeますか？

10. 属性Organization.Websiteは、「dba.stackexchange.com」などの特定の組織のWebサイトアドレスを表しますか？

11. 場合Profile（と理解「1」Person）であるMember（又はFriend）のProfile「2」は、それがために可能であるProfile行うために「1」RoleにLocationすることによって所有Profile「2」？そのようなシナリオはan OrganizationとMember Personsoの関係に対してのみ有効だと思いますが、どう思いますか？

12. 同様に、Organization「1」が「2」のMember（またはFriend）である場合、「1」がOrganization「2」が所有OrganizationするRoleで実行することは可能ですか？繰り返しますが、私はシナリオのこの種の間の関係のためにのみ有効であることを考えると、これは正しいでしょうか？LocationOrganizationOrganizationMember Person

13. 私はこのquestions-を書いています-whileこの点で、私は関係するだけで3種類の関係があることを言うのは合理的であると考えるOrganizationsとはPersons、私たちは定義することができます。

    • （a）「」としてのan Organizationとa の関係。PersonMembership
    • （b）a Personと別のPerson「Friendhip」としての関係。
    • （c）個人と別の個人との関係を説明するために、意味のある名前をまだ見つけていません。OrganizationOrganization
    • （a）、（b）、（c）についてのご意見をお聞かせください。

14. が同時に1対多の異なる（または）Organizationになることは可能ですか？または、別の1つとのみ関係を持つことのみが可能です。FriendMemberOrganizationsOrganizationOrganization?

最初の進歩を表す連続データモデル

上記の保留中の側面に対するあなたの回答と解決策に注目して、以下を作成しました…

• 組織とプロファイルの予備データモデル— First Advance。

私はまだそれには慣れていませんが、この新しいデータモデルは次のビジネスルールを表しています。

• AはProfileあるのいずれかOrganization またはPerson。^[2]
• Aは、Profileの提供の友人かもしれ一対多 FriendProfiles、およびProfileの受諾友人かもしれ一対多 FriendProfiles。^[3]
• A Locationは1対多で 構成されますLocations。^[4]

その後の特定のコメントへの回答

関心事の分離[たとえば、LocationAddressとProfileAddress]をメモ/合成することは本当に興味深いです。正しい関係なしに急いですべてを保持したかったのは明らかです[面白いことに、元のERDには問題がありました]。

はい、それは良い比較です。ただし、これは懸念の分離とは言いませんが（これは確かに、アプリケーションのプログラミングと設計の基本原則です）、この用語は一般にアプリケーション開発段階に関係しており、現在、データを理解し、その論理構造を設計する段階。

私の個人的な経験から、このフェーズは、重要なことを全体のコンテキストに入れることと関係があると思います。関心のある特定のシナリオに関連するさまざまなエンティティ間に存在する関連を確認することと関係があります。これらをデータモデルで表現します。あなたはコメントされている特定のケースでは、Addressエンティティがあり、他のエンティティと1との接続の異なる種類の持っているProfileとして別のものをLocation。

そして、はい、何かが正しくない、または自然に感じられない場合、適切なデータを理解するためにさらに努力する必要があることを示している可能性があります。このように、Addressa Profileとanの関係はエンティティーによって処理Address できると思うので、エンティティーはもっと注意する必要があると私が考えるものの1つですLocation（すべてLocationに少なくとも1つの物理的Address）、したがって、最新のモデルに示されている関連エンティティを却下することができProfileAddressますが、これらのポイントの分析を続けて、あなたのアイデアを教えてください。

また、IDEF1Xでは、読みやすさを向上させるためにエンティティのPK / FK表記を変更するのが一般的ですか（例：ProfileId-LocationOwnerProfileId）？

はい。IDEF1Xは、使用されているエンティティに応じてそのような属性の意味を把握するために、FOREIGN KEYSを指定するためにロール名を使用することを推奨しているため、非常に巧妙な意見です。これは主キーの移行の概念にも強く関連していることにも注意してください。実際、役割名の使用はIDEF1Xの前にあります。これは、EF Codd博士が1970年の独創的なテキストで最初に提示したためです。このようにして、IDEF1X標準がリレーショナルモデルに対して忠実に維持していることがはっきりとわかります。

私はあなたが特に好きではない/それがモデル化していないと感じているものをソリューションで/学ぶのに興味がありますか？

Addressエンティティについて既に上記で説明した詳細に加えて、特定の特定のRolesによって実行されたがとのどちらで同等かはわかりません。私の観点では、最初にを関連付ける必要があります。次に、これを特定ので実行するように指定しますが、シナリオをよりよく理解しているため、このルールは必要ない場合があります。この点で、私は私が文脈の説明や知っておくことは非常に参考になるという事実について主張するつもりの意味にこのデータ構造の弾力の将来のユーザーのことを、と、ProfileLocationOrganizationPersonPersonOrganizationOrganizationPersonRoleLocationOrganizationProfileLocation、ただしこれは機密情報と見なされる可能性があることを理解しているため、これは制限となります。

現在の構造では、誰でも（OrganizationまたはPerson）は誰でも（再び、OrganizationまたはPerson）に関連付けることができ、Roleどこでも（Location）何でもできる（）ことができるようですが、これは正確に、あなたとユーザーがこのデータベースに期待していることですもちろん、そのために明確に定義された制約を提供します。その場合は、ほぼ最終的なソリューションを提供しています。当然のことながら、この状況ではあなたの意見が決定的であるため、このアイデアを分析し、結論を知らせて、最終的な手順を実行できるようにする必要があります。

フィージブルセカンドアドバンス

残念ながら、コミュニケーションは数週間前に停止しました。これは、あなたが満たさなければならない仕事の責任のためだと思います。これは完全に合理的です。もっと安定したロバストなモデルを開発できれば、もっと多くのコンテンツが得られたでしょうが、以前の相互作用により、私はあなたを正しい方向に向けることができたと思います。

この質問と回答のプロセスですでに提示されていることに加えて、以前のデータモデルからの新しい進展を提供することは、同様の問題を抱える他の求職者に役立つ可能性があると考えています。それで、私は作成しました…

組織とプロファイルの予備データモデル— 2番目の進歩

このようなデータモデルに見られるように、私が削除されている多対多私は間先行モデルに描かれているという関係ProfileとAddress与えられたがので、Profile既にに関連する一対多 Addressesその所有経由しLocations。

この新しい進歩に示されているもう1つの変更は、特定のLocationユーザーが1対多 で所有できる可能性が含まれていることProfilesです。したがって、私は変更されているLocation（却下によってPRIMARY KEY LocationOwnerProfileId属性）、次いで（連想エンティティ加え多対多関係する）ProfileとをLocation。

ノート

_{1. IDEF1Xは、1993年12月に米国国立標準技術研究所（NIST）によって標準として定義された、非常に推奨されるデータモデリング手法です。}

_{2.これは、（スーパー）タイプ-サブタイプクラスターのオカレンスです。あなたが興味を持っているのであれば、ここに私がこの種の関係をより詳細に扱う答えがあります。}

_{3. 多対多の階層関係の例であり、「部品展開問題」に決定的な解決策を与えた構造に非常に似ています。もちろん、そのような解決策は1970年にエドガーフランクコッド博士によって非常に影響力のある論文「大規模な共有データバンクのデータのリレーショナルモデル」で紹介されました。}

_{4.そのため、これは1対多（または多対1）の階層関係のインスタンスです。}

問題の理解を深めるのに役立たない方法で、オブジェクトモデリングの概念とデータモデリングの概念を融合しようとしていると思います。散らかしすぎずに、混乱を少しでも解消できるといいですね。

そのため、リレーショナルモデルは継承をサポートせず、ポリモーフィズムを気にしません。つまり、オブジェクトモデルの継承とポリモーフィズムによって簡単に処理される実際の状況をモデル化する場合は、かなり特殊な設計パターンを使用する必要があります。この特別なデザインパターンについては、後で詳しく説明します。

ERモデルが最初に開発されたとき、それはリレーショナルモデリングの実装にとらわれない代替手段であると想定されていました。最初は、継承のようなものもありませんでした。しかし、1980年代または1990年代のある時点で、モデルは拡張され、継承で得られるのと同じ表現能力のいくつかを提供します。これは「拡張ERモデル」として知られていましたが、実際の目的のために、今日のERモデルにはEER機能が含まれています。

EER機能の1つに、「一般化/特殊化」という名前があります。Webでこの概念を検索して読むことができます。Gen-specは、クラスとサブクラスがオブジェクトモデルで提供するものとほぼ同じ表現機能を提供します。ただし、Gen仕様では、Gen仕様の状況でのリレーショナルテーブルの設計に関する問題は扱われていません。それについては後で詳しく説明します。

ERモデリングでは、関係には常に同じエンティティが含まれます。したがって、組織とプロファイルの友達関係は、プロファイルと別のプロファイルの友達関係と同じではありません。2つの関係には異なる名前が必要です。この規則に従わない場合は、結び目を作るだけです。

それか、または組織、プロファイル、そして場合によっては場所がすべて特殊化されている一般化されたエンティティを考え出す必要があります。私はあなたを助けるのに十分あなたのケースを理解していません。

次に、リレーショナルモデルとERモデルを1つのモデルに結合していることに気づきました。ほとんどの熟練したデータベースアーキテクトがこれを行います。ただし、熟練するまでは、2つのモデルを別々にしておくことをお勧めします（ただし、互いに調整されます）。

最後に、gen-specの状況を表すリレーショナルテーブルをどのように設計しますか？これら2つのデザインパターン「クラステーブル継承」と「単一テーブル継承」を調べてみてください。Stackoverflowには、これらのタグが2つあります。また、パターンのかなり良いプレゼンテーションがウェブ上にいくつかあります。私は特にマーティン・ファウラーの扱いが好きです。オブジェクトモデラーの考え方を知っているようです。お役に立てれば。