我应该如何在SQL中实现以下实体关系图所示的方案？ 如图所示，每个A实体类型出现都必须与至少一个 B对应项（由双连接线指示）相关，反之亦然。我知道我应该创建以下三个表： CREATE TABLE A ( a INT NOT NULL, CONSTRAINT A_PK PRIMARY KEY (a) ); CREATE TABLE B ( b INT NOT NULL, CONSTRAINT B_PK PRIMARY KEY (b) ); CREATE TABLE R ( a INT NOT NULL, b INT NOT NULL, CONSTRAINT R_PK PRIMARY KEY (a, b), CONSTRAINT …
我正在创建一个概念图[是的，我知道我已经包括了属性和键-但这只是为了巩固我在学习时正在做的事情] –因此，请把它视为概念图，重点放在关系和表而不是如何绘制;） 我的想法障碍是： 我正在尝试确定对个人档案，位置和组织关系进行建模的最佳方法。 首先，规则： 一个或多个个人资料可以是一个或多个组织的成员/朋友；反之亦然。 一个或多个个人资料可以是其他个人资料的成员/朋友。 一个或多个组织可以是其他组织的成员/朋友。 朋友和会员的不同之处在于，朋友就像只读的，而会员（取决于级别）具有完全的修改权限。 为了进一步使事情复杂化，场所具有自己的一组“更进一步”的可完善规则，例如，一个组织拥有两个场所，但是根据场所规则，该组织的成员[ 个人资料 ]可能在一个场所具有完全访问权限，但在该场所具有受限访问权限其他。[抱歉：您可能必须在另一个窗口中打开图像才能获得更好的查看尺寸。] 因此，正如您所看到的，“个人档案”和“组织”的概念几乎相同，而“ Friends and Members” [...]这个尚未建模的概念[...我想它将像设置Owner /的当前中介表一样处理记录中的管理员/成员/朋友等]。因此，为什么我要考虑以下概念： 请参见上图中的Option.2：它将删除当前的Organization和Organization_Locations表及其关系，将其替换为Option.2 Organization Table作为与Profile的某种递归关系。 我想问题的症结在于我是否在编程方面对多态性过于介意，以至于损害了其简单性和灵活性，使自己在整个过程中陷入混乱；） 谢谢您的提前考虑，非常感谢-M :)。 修改后的图： 针对MDCCL的问题： 是的，Profile是由一个Person组成的，并且具有相同的含义-尽管您的理论依据是-我相信您是正确的：Organization和Person可以是Profile的子类型；因此，概要由一个人或一个组织组成。 每个配置文件一个电子邮件地址。 是。如上所述，组织的至少应具有一个电子邮件地址。 正确，一个固定地址。 这是一种可能性，但是很罕见-尽管从我的经验中学到了-因此应该为将来的寿命等建模，并且为了确认，一个位置因此可以由多个人拥有。 位置绝对是大多数其他位置之间不可或缺的实体。也许我会在这里澄清一下可以做什么，然后让您阅读我的其他答案，希望这些答案可以先对该问题进行有益的补充[ 然后再查看我对＃6的答案 ];）Re：角色所有者。 An **Organization** can be an Owner of zero or more **Locations**. A Person can be an …