问代表乌鸦脚ERD中的一个或一个关系

EN

1澄清

代表乌鸦脚ERD中的一个或一个关系

你的图表是一个很好的开始。注意：

• 那不是ERD。这远远超出了ERD所能处理的细节。
• ERD没有乌鸦脚，即IEEE符号

最终，您需要一个具有实现所需细节的数据模型(远大于ERD)。这就是为什么我说你的图表是一个好的开始，它正在朝那个方向移动。然而，我们有一个关系数据建模标准：IDEF1X，这是1993年以来的关系数据库建模标准，在它被提升到一个标准之前，它从1984年就开始使用了。

• 显然，Dr E F Codd的关系模型和关系数据库建模的图解方法都受到了抑制。

关系符号，特别是基数，在IEEE表示法中比IDEF1X更好(更容易理解)，因此大多数人使用它。所有数据建模工具(如ERwin )都实现了IDEF1X，并允许使用IDEF1X或IEEE来表示关系。

2项请求

该图是非法的。为什么？因为你有一段关系要“离开”人，两张桌子。不可能。您正在询问如何在数据模型中表示这种关系(在ERD中是不可能的)。答案是，或是逻辑术语，子类型是关系术语中的。

请查阅这些答案的概述和细节。有关实现细节和代码的链接如下：

• 如何将主键字段与多个表关联？
• 构建数据库关系以跟踪应用程序设置的不同变化
• 我如何避开这种关系数据库设计的味道呢？

子类型可以是：

• 独占( Basetype必须是其中一个子类型)，或者
• Non-Exclusive ( Basetype必须是一个以上的子类型)。

从Role来看，它似乎是排他性的。您所称的Role是IDEF1X中的一个IDEF1X。

这是关系数据库的最佳实践。

关系数据模型

这是用于数据模型的最佳实践(此级别的详细信息仅显示属性名称)。

​

​

• 当然，我所有的数据模型都是用IDEF1X呈现的。
• 我的IDEF1X简介是初学者必不可少的读物。
• ParentId, StudentId, OwnerId都是PersonId的关系词( RoleNames )。这就明确了FK的上下文。

3校正

但我不确定这是否符合最佳实践

既然你很关心，还有另外一个问题。您的模型中有一个错误，它是在每个文件上标记id时发生的常见错误之一。这种做法削弱了建模练习，使其容易出现各种错误。(我知道有人教你那种残废的方法。)

• 由于一个人可以有0或-1的帐户，而Person PK (对一个人来说是唯一的)是一个FK帐户，它可以是PK中的帐户。
• AccountId是不必要的:它是100%的冗余，一个额外的字段和一个额外的索引，可以消除。

​

​