概念 ERD 多表多对多，或者可能是递归的？

Question

我正在创建一个概念图 [是的，我知道我已经包含了属性和键 - 但这只是让我在学习的同时巩固我正在做的事情] - 所以请把它当作概念性的，重点是关系和表格而不是如何绘制图表；)

我的障碍是： 我正在尝试确定对配置文件、位置和组织关系进行建模的最佳方式。

首先，规则：

• One or more Profile's can be a Member/Friend of one or more Organizations; and vice versa.
• One or more Profile's can be a Member/Friend of other Profiles.
• One or more Organization's can be a Member/Friend of other Organizations.

Friend and Member differ, in that, Friends are like read-only and Members [depending on level] have full access to amend things.

更复杂的是，位置有自己的一套“进一步”细化规则，例如一个组织拥有两个位置，但根据位置规则，该组织的成员 [个人资料] 可能在一个位置具有完全访问权限，但在其他。[抱歉：您很可能需要在另一个窗口中打开图像以获得更好的查看尺寸。]

因此，正如您所看到的，Profiles 和 Organizations 的概念非常相似，还有尚待建模的 Friends 和 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 的答案] ;)回复：角色所有者。 An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[因此，正如你之前所猜测的那样；简而言之，个人资料可以是零个或多个位置的所有者。

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

8. 正确的。
9. 你的直觉是惊人的！是的it is foreseen that a single Location could contain one to many LocationTypes- 更复杂的是- 预计这些单独的 LocationType 可能对与“父”位置关联的配置文件具有不同的权限；其中，权限将从 Location 过滤到 LocationType/s [很像 OS 文件夹安全权限]。我通过你的图表注意到你可能指的是键入更多作为描述？
10. 是的。
11. 见 12。
12. 正确，Profile1 [Person or Organization] 对Profile2 [Person or Organization] 拥有的位置[如果他们是具有正确权限的朋友/成员] 采取行动的能力是最重要的。
13. 非常合理 - a)同意。b)同意。c)是的，嗯？...也许它应该与Profile [person] 到Profile [person] = Friends大致相同。无论描述如何，它都会围绕Location，因为Organization /s 将作用于其他Organization Location /s；尽管从语义上讲，我怀疑任何组织都希望作为该地点组织的“成员”表现出屈从，“无论事业有多好”。

[6]。这对我来说仍然有点灰色，但这里是......可能对我不利的是，会员/朋友关系之间的相似性非常接近，我想将它们结合起来；事后看你的图表和解释，看起来你把它们分开可能是正确的[我将通过枚举属性区分单一关系：Owner/Admin/Member/Friend ]。您的概念例如：组织拥有的位置将有零到多个配置文件 [个人或组织] 对其进行操作，尽管配置文件如何通过其关系 [成员或朋友] 通过角色表示。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.

Answer 1

很高兴您能花时间理解、分类和建模您正在处理的数据，因为根据我的个人经验，所有这些都使整个开发过程变得更容易，并且对于未来的变化非常灵活。我很确定您也已经意识到这一点。

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

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

首先，这里是…

• 组织和资料初步数据模型。

由于它只是初步的，将其视为帮助我们完成所需的最终数据模型的一种手段。

假设的业务规则

所述初步数据模型源自一组业务规则（从您的问题中推断出来），我将列举如下：

组织和简介

请注意，Profile目前被理解为 的同义词Person。

• AnOrganization是一对多 的朋友Profiles。
• AnOrganization是一对多 的朋友Organizations。
• AnOrganization是一对多 的成员Organizations。
• AProfile是一对多的成员Organizations。
• AProfile是一对多 的朋友Profiles。
• AProfile是一对多 的成员Profiles。

地点和地址

• AnOrganization拥有一对多的 Locations.

• ALocation按一对多 分类LocationTypes（在给定的时间点只有一个）。

• ALocation可能有一对多 Addresses（一个 Physical、一个用于Shipping、一个用于Billing、或一个用于所有上述目的，或者一个组合两个目的而另一个仅用于其中一个目的）。

• 一个Address可以通过保持一个一对多 Profiles或者，换一种方式，Profile保持一个一对多 Addresses。

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

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

地点和角色

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

需要解决的方面才能继续前进

为了不断提高数据模型的分辨率，以下是相关要点列表，一旦我们解决它们，将帮助我们实现这一目标：

1. 我假设Profile您上下文中的术语与 具有相似（或相同）的含义Person，但可能会有所不同。这样，您会说，在您的场景中，实体Organization和Person是 的子类型Profile吗？

2. a Profile(or Person) 可以拥有一对多 EmailAddresses，还是a Profile(or Person) 固定为一个 EmailAddress？

3. 您想提供Organization通过Telephone和联系an 的可能性Email，还是想限制只能对 a Profile（或Person）进行联系？

4. 我认为一个Location固定到只有一个 Address类型的Physical，这是正确的？

5. 是否有可能为一个Location由共享一个一对多的不同Organizations 或者，否则，Location由可拥有的只有一个 Organization？

6. 您已经通过评论声明作为 aMember和 a的事实Friend是相同的。正如您在我提议的初步数据模型中看到的那样，我遵循了您的原始规范，并描绘了不同实体中Organization和Profile（或Person）之间的所有可能的成员资格和友谊组合，因为我认为这有助于定义最佳可能方案的那部分的结构。在这个意义上：

   • 我假设该语句的an Organization is a Member of another Organization效果与该语句a Profile (or Person) is a Member of an Organization关于名为 的实体的效果不同Location。
   • 正如您在数据模型中看到的那样，我认为RoleofOwner仅对 an 有效Organization，对我而言，Roles对 a Profile（或Person）有效，在 a Locationare Adminand 中Member。你怎么看这一切？由于您直接接触适用于您情况的业务规则，您需要告诉我我的假设是否正确。

7. a Profile（或Person）可以Roles在同一个里面玩不同的游戏Location吗？即，可以在Person是，在同一时间，Admin也是一个Member相同的Location？这方面的规则是什么？

8. 我认为相同的Profile（或Person）可以Roles在不同的Locations. 例如：一个特定的Profile（或Person）是Location“1”中的“管理员” ，同时这个Profile（或Person）是“2”Member中的Location“ ”。我对吗？

9. 一个特定的人是否有可能Location同时拥有不同LocationTypes的东西，或者一个人是否Location固定持有一个LocationType？

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

11. 如果Profile“1”（理解为Person）是“2”的Member（或Friend），Profile“1”是否有可能在“2”所拥有的ProfileaRole中执行 a ？我认为这样的场景只对 an和 a so之间的关系有效，你怎么看？LocationProfileOrganizationMember Person

12. 类似地，如果Organization“1”是“2”的a Member（或Friend），Organization“1”是否有可能在“2”拥有的OrganizationaRole中执行a ？再次，我认为这种场景只对 an和 a之间的关系有效，这是正确的吗？LocationOrganizationOrganizationMember Person

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

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

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

描述第一次推进的连续数据模型

考虑到您对我上面列出的未决方面的回应和解决方案，我创建了以下内容……

• 组织和配置文件初步数据模型 - First Advance。

虽然我还不太适应，但这个新的数据模型表达了以下业务规则：

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

对您随后的具体评论的答复

对我来说，注意到/复合关注点的分离[例如 LocationAddress 和 ProfileAddress] 真的很有趣 - 因为我显然想冲进去并在没有正确关系的情况下保留它们 [有趣的是，我原来的 ERD 感觉不对]。

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

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

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

此外，在 IDEF1X 中更改实体中的 PK/FK 表示以提高可读性是否是常见做法 [例如 ProfileId - LocationOwnerProfileId]？

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

我很想知道你不特别喜欢/感觉它没有建模，有/在解决方案中？

除了上面已经描述的关于Address实体的细节之外，我不确定特定中Roles给定的执行是否等同于 an或 an 。从我的角度来看， a首先需要与 an 相关联，然后 this将指定表示在特定的 中执行 a ，但您更了解场景，因此此规则可能是不必要的。在这方面，我将坚持这样一个事实，即了解这种数据结构的未来用户给予的上下文描述或含义对我来说非常有帮助，ProfileLocationOrganizationPersonPersonOrganizationOrganizationPersonRoleLocationOrganizationProfile以及Location，但我知道这可能被视为机密信息，因此这将是一个限制。

使用当前的结构，似乎每个人（Organization或Person）都可以与任何人（再次，Organization或Person）相关，并且可以在任何Role地方（Location）做任何事情（）但是，perharps，这正是您和用户对该数据库的期望，当然，您将提供明确定义的约束。如果是这种情况，那么我们几乎可以提供最终解决方案。既然在这种情况下你的意见自然是决定性的，你也应该分析这个想法，然后让我知道你的结论，以便我们可以采取最后的步骤。

可行的二次推进

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

除了在这个问答过程中已经提出的内容之外，我认为从以前的数据模型提供新的进展可能对其他有类似问题的寻求者有所帮助。所以，我创建了…

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

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

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

笔记

_{1. IDEF1X是一种非常值得推荐的数据建模技术，于1993 年 12 月被美国国家标准与技术研究院 ( NIST )定义为标准。}

_{2. 这是一个（超）类型-子类型集群的出现。如果您有兴趣，这里有一个答案，我以更详细的方式处理这种关系。}

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

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