我正在处理的数据库之一有一些我想在实体关系图中解释的古怪行为。
其中一种行为是有一个“预订”表和一个“发票”表。当为“booking”开具发票时，该记录将插入到“invoice”表中，然后从“booking”表中删除。
但是，仍然保留了预订号的参考。
我们如何建模？表格之间的大箭头和旁边的一些文字描述发生了什么？
不，此时无法更改数据库架构
编辑：这是我想使用的图表类型： alt text http://img813.imageshack.us/img813/5601/erdartistperformssong.png 链接
如果通过 ERD，您的意思是原始的“陈”图，其中关系是用菱形写的单词，那么您在 Booking 和 Invoice 之间存在关系。这是一种特殊的关系，不是用简单的外键实现的；它是通过复杂的移动和约束来实现的。
如果 ERD 是指 ERwin 绘制的图表，那么您没有简单的方法来做到这一点。它倾向于让您专注于绘制 PK-FK 关系。这些事物之间存在非 PK-FK 关系。某种带有文本的线条是您所能做的。
顺便说一句，箭头不合适，因为 ERD 显示了数据库的“状态”。数据流动不是 ERD 的一部分。你们确实有关系，只是不是典型的 PK-FK 关系。这是一种非典型关系，基于某些地方存在而其他地方不存在的行。
在 UML 中，您可以轻松地将其绘制为关系之间的“约束”。
我不知道这些人在说什么。
实体关系图没有完全描述数据；是的，当然，它只显示实体和关系，不显示属性。这就是为什么它被称为 ERD 而不是数据模型的原因。显然这里很多人都分不清。
数据模型应该尽可能多地显示。但这取决于 (a) 您使用的标准 [如果有的话] 和 (b) 符号。有些人比其他人表现得更多。IDEF1X 是唯一的关系建模标准（NIST 184 of 1993）。它是最完整的，并显示了其他符号没有显示的错综复杂和复杂性。最近 MS 和其他人提出了“简化”符号，当然，“ERD”中丢失了很多。
它不是“流程”，它是数据库中的关系。
UML 完全不适合建模数据，尤其是当至少有一个标准加上几个非标准但常用的数据建模符号时。没有什么可以在 UML 中显示而不能在 IDEF1X 中显示。但是这里的大多数开发人员从未听说过它（开发人员不应该建模，除非他们获得了建模技能，但那是另一回事了）..
这是完全合法的；它可能不为人所知，但它是合法的和命名的。它是超类型-子类型关系，除了基数是 1::0-n 而不是 1::0-1。IDEF1X 表示法（右）有一个子类型符号。请注意，父端只有一个关系；在孩子端各一个。当然，鱼尾纹显示了基数。这些关系可以是独占的或非独占的；你的是独家的；这就是通过半圆的 X 的含义。
ERwin 是唯一实现 IDEF1X 的建模（不是图表）工具，因此具有 IDEF1X 表示法的完整补充。
当然，标准，建模能力，都在头脑中，而不是在工具中。我使用简单的绘图工具绘制符合 IDEF1X 的数据模型。
我发现一些开发人员对 Subtype 符号犹豫不决，所以我在我的 IDEF1X 模型中展示了一个简化版本（左）；它旨在传达排他性的感觉，而在父端保留单行表明它是一个子类型。
Lott：点击这里▶<a href="http://www.softwaregems.com.au/Documents/Student%20Resolutions/Nitrodist%20DM.pdf" rel="nofollow">链接到数据模型◀ Lott：点击这里
为不熟悉关系建模标准的人链接到 IDEF1X 表示法。
听起来像是一个流程，而不是实体关系。如果在将条目添加到发票时，将条目从预订中删除，则两者之间永远不会存在关系。从来没有一种情况可以遍历这种关系，因为在这两个地方都没有可以关联在一起的记录。
ERD 没有完全描述数据库。还有其他内容，例如详细说明系统其他方面的流程和用例。
这有点类似于软件的 UML。类图不会向您展示类交互的所有不同方式。一个类可能在本地初始化并调用另一个类的函数，但是因为没有组合或继承将这两个类关联起来，所以类图没有显示这种关系。只有当你用各种类型的图表完整地记录系统时，你才能看到它如何运作的所有方面。
