我正在创建一个概念图[是的，我知道我已经包括了属性和键-但这只是为了巩固我在学习时正在做的事情] –因此，请把它视为概念图，重点放在关系和表而不是如何绘制;）

我的想法障碍是： 我正在尝试确定对个人档案，位置和组织关系进行建模的最佳方法。

首先，规则：

• 一个或多个个人资料可以是一个或多个组织的成员/朋友；反之亦然。
• 一个或多个个人资料可以是其他个人资料的成员/朋友。
• 一个或多个组织可以是其他组织的成员/朋友。

朋友和会员的不同之处在于，朋友就像只读的，而会员（取决于级别）具有完全的修改权限。

为了进一步使事情复杂化，场所具有自己的一组“更进一步”的可完善规则，例如，一个组织拥有两个场所，但是根据场所规则，该组织的成员[ 个人资料 ]可能在一个场所具有完全访问权限，但在该场所具有受限访问权限其他。[抱歉：您可能必须在另一个窗口中打开图像才能获得更好的查看尺寸。]

因此，正如您所看到的，“个人档案”和“组织”的概念几乎相同，而“ Friends and Members” [...]这个尚未建模的概念[...我想它将像设置Owner /的当前中介表一样处理记录中的管理员/成员/朋友等]。因此，为什么我要考虑以下概念：

请参见上图中的Option.2：它将删除当前的Organization和Organization_Locations表及其关系，将其替换为Option.2 Organization Table作为与Profile的某种递归关系。

我想问题的症结在于我是否在编程方面对多态性过于介意，以至于损害了其简单性和灵活性，使自己在整个过程中陷入混乱；）

谢谢您的提前考虑，非常感谢-M :)。

修改后的图：

针对MDCCL的问题：

1. 是的，Profile是由一个Person组成的，并且具有相同的含义-尽管您的理论依据是-我相信您是正确的：Organization和Person可以是Profile的子类型；因此，概要由一个人或一个组织组成。
2. 每个配置文件一个电子邮件地址。
3. 是。如上所述，组织的至少应具有一个电子邮件地址。
4. 正确，一个固定地址。
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[因此，如您先前的推测；简而言之，个人资料可以是零个或多个位置的所有者。

7. 是的，作为位置所有者的配置文件将假定所有角色权限[超级用户]；作为管理员的个人资料可以修改位置的某些详细信息，但主要是帮助/编辑通过所有其他个人资料提供的详细信息/数据-这将主要由所述位置的“基本成员”提供；这让普通会员，谁能够只读所有相关的位置信息，并且必须用一个scrutineered供应数据管理员/所有者。除此之外，任何个人资料[机构/人]很像普通会员 “只读” -他们让我们的长期客户 -但前提是位置设置为公共 [和没有私人 ]，尽管他们不能像电源输入端普通会员可以。

8. 正确。
9. 您的直觉太神奇了！是的，it is foreseen that a single Location could contain one to many LocationTypes为了使事情进一步复杂化，可以预期这些单独的LocationType对与“父代”位置相关联的个人资料可能具有不同的权限；其中，权限会从位置过滤到LocationType / s（非常类似于OS文件夹安全权限）。我注意到通过您的图表，您可能会更多地将类型作为描述？
10. 是。
11. 见12。
12. 正确，Profile1 [人员或组织]对Profile2 [人员或组织]拥有的位置采取行动的能力[如果它们是具有正确权限的朋友/成员]是至关重要的。
13. 非常合理-a ）同意。b）同意。c）是的，嗯？...也许应该与Profile [person]到Profile [person] = Friends大致相同。无论如何描述，它都将围绕Location展开，因为组织将对其他组织 位置采取行动；尽管从语义上讲，我怀疑任何组织都希望将其作为该位置组织的“成员”显示为从属，才能“不管原因有多好”。

[6]。对我而言，这仍然是一点点灰色，但是……可能对我不利的是，成员/朋友关系之间的相似性如此之近，以至于我想将它们结合起来。事后查看您的图表和解释，您似乎可以将它们分开[ 我打算通过枚举属性来区分单一关系：所有者/管理员/成员/朋友 ]。您的概念例如：一个组织拥有的位置将对其执行零个到多个概要文件[人员或组织]，尽管概要文件通过其关系[成员或朋友]对位置采取的行动之间应该有明显的区别]（通过角色表示）。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.

很高兴您能抽出宝贵的时间来理解，分类和建模要处理的数据，因为从我个人的经验来看，所有这些都使整个开发过程变得更加容易且非常灵活，以适应将来的更改。我很确定您也已经意识到这一点。

初步数据模型和假定的业务规则

阅读您的问题并仔细检查您的图表后，我定义了一个业务规则列表，以描述我对您的规格的理解。定义了此类列表之后，我派生了一个IDEF1X ^[1]数据模型，我决定将其作为.PDF文档上传到外部平台（Dropbox）中，因为由于其格式，该数据模型不太适合嵌入图像。这两种工具将作为一些重要点的参考，这些点我将在下面标题为“要解决的方面”以继续前进的部分中列举。

首先，这里是…

• 组织和档案初步数据模型。

因为只有这样，所以初步考虑将其视为帮助我们完成所需最终数据模型的一种手段。

假定的业务规则

所述初步数据模型来自业务规则集合（从您的问题推论得出），我将列举如下：

组织和简介

请注意，Profile当前将其理解为的同义词Person。

• 安Organization是一对多 的朋友Profiles。
• 安Organization是一对多 的朋友Organizations。
• An Organization是一对多 的成员Organizations。
• A Profile是一对多的成员Organizations。
• A Profile是一对多 的朋友Profiles。
• A Profile是一对多 的成员Profiles。

地点和地址

• 一个Organization拥有一对多 Locations。
• A Location通过一对多 分类LocationTypes（在给定的时间点仅一个）。
• 一个Location可以有一个一对多的 Addresses（一个 Physical，一个对Shipping，一个用于Billing，或一个服务于所有说的目的，或一个结合了两个目的，并另一种服务只有一个人）。

• An Address可以一对多 保留，Profiles或者换句话说，一对多Profile保留。 Addresses

• 具体Address可通过使用一到多 Profiles（用作Physical用于一个 Profile，被用于Billing由不同的一个，等等）。因此，Address与Locations和的工作方式相似Profiles。

  • 因此，个体Address可以是，在同一时间，类型Physical，Shipping 和 Billing。

位置和角色

• 一Location打开一个一对多 Roles。
• A Role可以一对多执行 Locations。
• 甲Profile（一旦它已经被设置为Member一个Organization）可以执行一个对多 Roles，在一对许多 Locations（但只有一个特定Role于每个Location在特定的时间点，即，无法在两个或多个 Roles在同一时间）。

要解决的方面，以便继续前进

为了不断提高您的数据模型的分辨率，以下列出了一些相关点，一旦我们进行了研究，它们将有助于我们实现这一目标：

1. 我假设您所使用的术语Profile与的含义相似（或相同）Person，但可能有所不同。这样，您是否可以说在您的方案中，实体Organization和Person是的子类型Profile？

2. 一个Profile（或Person）可以一对多拥有 EmailAddresses，还是一个Profile（或Person）固定为正好一个 EmailAddress？

3. 您是否想提供Organization通过Telephone和与进行联系的可能性Email，或者您想限制仅对Profile（或Person）进行联系？

4. 我假设a Location固定地恰好 Address是type之一Physical，这是正确的吗？

5. 是否有可能为一个Location由共享一个一对多的不同Organizations 或者，否则，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。
   • 正如您在数据模型中看到的那样，我认为Roleof Owner仅对Organizationand和有效，对我而言，对are 和而言Roles对Profile（或Person）有效。您如何看待这一切？由于您与适用于您情况的业务规则直接联系，因此您需要告诉我我的假设是否正确。LocationAdminMember

7. 一个Profile（或Person）Roles在同一内部可以发挥不同的作用Location吗？即，可以Person同时是Admin和Member一样Location吗？这方面的规则是什么？

8. 我认为同一Profile（或Person）可以Roles在不同方面发挥不同的作用Locations。例如：一个特定的Profile（或Person）同时是Location“ 1”中的“ Admin” ，而同一Profile（或Person）则同时是“ 2” Member中的Location“”。我对吗？

9. 一个人可能Location同时拥有不同LocationTypes的人，还是一个Location固定的人恰好持有一个人LocationType？

10. 该属性是否Organization.Website代表特定组织的网站地址，例如“ dba.stackexchange.com”？

11. 如果Profile“1”（理解为Person）是Member（或Friend）的Profile“2”，是有可能为Profile“1”，以进行Role在Location所拥有Profile“2”？我认为这样的场景仅对一个Organization和一个Member Person这样的关系有效，您怎么看？

12. 以类似的方式，如果Organization“1”是一个Member（或Friend）的Organization“2”，是有可能为Organization“1”，以进行Role在Location所拥有Organization“2”？同样，我认为这种情况仅对an Organization和a 之间的关系有效，这Member Person是正确的吗？

13. 在这方面（当我写这个问题时），我认为可以合理地说，只有三种不同的关系涉及Organizations和Persons，我们可以定义：

    • （a）an Organization和a 之间的关系Person为“ Membership”。
    • （b）a Person与另一个之间的关系Person为“ Friendhip”。
    • （c）我们还没有找到一个有意义的名字来描述一个人Organization与另一个不同人之间的关系Organization。
    • 所以，让我知道您对（a），（b）和（c）的看法。

14. 一个Organization同时可能是一对多的Friend（或Member）不同？或者，一个人只能与一个完全不同的人建立关系OrganizationsOrganizationOrganization?

描述先行进展的连续数据模型

为了关注您对我上面列出的未决方面的回应和解决方案，我创建了以下内容：

• 组织和档案初步数据模型-第一次进展。

尽管我对此还不太满意，但是这个新的数据模型表达了以下业务规则：

• 阿Profile是要么一个Organization 或一个Person。^[2]
• 阿Profile可的供朋友一个一对多 FriendProfiles，和一个Profile可以是所述接受朋友一个一对多 FriendProfiles。^[3]
• A Location可以由一对多组成 Locations。^[4]

对您随后的特定评论的答案

对我来说，注意/复合关注点的分离非常有趣（例如LocationAddress和ProfileAddress）-因为我显然想匆匆忙忙地持有所有这些对象而没有正确的关系[有趣的是，我的原始ERD感觉不合适。

是的，这是一个很好的比较，尽管我不会称其为关注点分离（这当然是应用程序编程和设计的基本原理），因为该术语通常与应用程序开发阶段有关，我们目前发现自己处于理解数据并设计其逻辑结构的阶段。

根据我的亲身经历，我认为此阶段与将重要事物放入其整个上下文有关，这与查看与特定兴趣场景相关的不同实体之间存在的关联有关，然后在数据模型中描述这些东西。在您要评论的特定情况下，该Address实体可能与其他实体具有不同类型的连接，一个与Profile，另一个与与Location。

而且，是的，当某些事情不正确或不自然时，这很可能表明人们需要付出更多的努力才能理解相关数据。以这种方式，Address实体是我认为需要更多注意的事情之一，因为我认为a Profile和an 之间的关系Address 可以通过Location实体来处理（因为每个人都Location必须至少拥有一个实体Address），因此我们可以取消ProfileAddress最新模型中描述的关联实体，但是您应该继续分析这些观点，并让我知道您的想法。

另外，在IDEF1X中是否经常更改实体中的PK / FK符号以提高可读性[例如ProfileId-LocationOwnerProfileId]？

是的，这是您的非常聪明的话，因为IDEF1X建议使用角色名称来表示FOREIGN KEYS，以便根据使用它的实体来捕获此类属性的含义。还值得注意的是，这也与主键迁移的概念密切相关。事实上，角色名称的使用先于IDEF1X，因为它最初是由EF Codd博士在1970年的开创性著作中提出的。以这种方式，可以清楚地看到IDEF1X标准对关系模型的忠诚度。

对于解决方案中/中的问题，我会很感兴趣，以了解您不喜欢/不喜欢的东西吗？

除了上述关于已经描述的细节Address实体，我不知道，如果Roles由给定进行Profile特定Location等价于一个Organization或一个Person。从我的角度来看，Person首先需要将与关联Organization，然后Organization将其指定Person为Role在特定Location的条件下执行，但是您更了解这种情况，因此此规则可能是不必要的。在这方面，我要坚持的事实，那将是非常有益的，我知道上下文说明或意义，这种数据结构给未来的用户Organization，Profile以及Location，但我知道这可能被视为机密信息，因此这是一个限制。

在当前结构下，似乎每个人（Organization或Person）都可以与任何人（再次Organization或Person）相关联，并且可以/在任何Role地方（Location）进行任何操作（），但实际上，这正是您和用户对数据库的期望当然，您会为此提供明确定义的约束。如果是这种情况，那么我们几乎可以提供最终解决方案。由于您自然会在这种情况下起决定性作用，因此您还应该分析一下这些想法，然后让我知道您的结论，以便我们采取最终步骤。

可行的第二次推进

不幸的是，交流是在几周前停止的，我想是因为您必须履行工作承诺，这是完全合理的。如果我们开发了一个更稳定，更可靠的模型，我会更加满意，但是由于我们之前的互动，我可以假设我已经为您指明了正确的方向。

除了在此问答过程中已经介绍过的内容之外，我认为提供先前数据模型的新进展可能对其他有类似问题的求职者也有所帮助。因此，我创建了...

组织和配置文件初步数据模型-二次进阶

从这种数据模型中可以看出，我删除了前面模型中和之间的多对多关系，因为给定已经通过其所拥有的与多对多相关。ProfileAddressProfile AddressesLocations

此新进展中说明的另一个变化是，它现在包括给定Location可以由一对多 拥有的可能性Profiles。因此，我已经改变了LocationPRIMARY KEY（由驳回LocationOwnerProfileId属性），然后加入缔实体（多到许多其涉及）Profile用Location。

笔记

_{1. IDEF1X是高度推荐的数据建模技术，1993年12月被美国国家标准技术研究院（NIST）定义为标准。}

_{2.这是（super）type-subtype集群的出现。如果您有兴趣，这里有一个答案，我将在这种答案中更详细地介绍这种关系。}

_{3.一个多对多层次关系的示例，它与为“零件开发问题”提供最终解决方案的结构非常相似。当然，这种解决方案是由Edgar Frank Codd博士在1970年极具影响力的论文“大型共享数据库的数据关系模型”中提出的。}

_{4.因此，这是一对多（或多对一）层次关系的实例。}

我认为您正在尝试将对象建模中的概念与数据建模中的概念混合在一起，而这不会帮助您澄清自己对问题的理解。我希望我可以在不引起过多混乱的情况下稍微消除混乱。

因此，关系模型不支持继承，更不用说多态了。这意味着在对现实情况进行建模时必须使用相当专业的设计模式，而在对象模型中通过继承和多态性可以轻松地处理这种现实情况。稍后将进一步介绍该特殊设计模式。

最初开发ER模型时，它被认为是关系建模的不可知论替代。起初，它也没有像继承这样的东西。但是在1980年代或1990年代的某个时候，该模型得到了扩展，以提供与继承相同的表达能力。这被称为“扩展的ER模型”，但是出于所有实际目的，当今的ER模型包含EER功能。

一种EER功能被称为“通用化/专业化”。您可以在网上搜索和阅读该概念。Gen-spec提供了与对象模型中的类和子类相同的表达能力。但是，Gen-spec并未处理有关gen-spec情况的关系表设计的问题。以后再说。

在ER建模中，关系始终涉及相同的实体。因此，组织和个人资料之间的朋友关系与个人资料和另一个个人资料之间的朋友关系不同。这两个关系需要不同的名称。如果您不遵循此规则，则只会使自己陷入困境。

要么，要么您需要提出一个广义的实体，其中“组织”，“个人档案”以及“位置”全都是专业。我不太了解您的情况，无法为您提供帮助。

继续，我注意到您正在将关系模型和ER模型组合到一个模型中。大多数经验丰富的数据库架构师都会这样做。但我建议您将两种模型分开（尽管彼此协调），直到您熟练为止。

最后，如何设计一个表示一般规格情况的关系表？尝试查找这两个设计模式“类表继承”和“单表继承”。Stackoverflow中有两个用于这些标记的标记。网络上也有一些很好的模式演示。我特别喜欢马丁·福勒的待遇。他似乎知道对象建模者的想法。希望这可以帮助。