对具有古怪行为的数据库 (ERD) 进行建模
我正在处理的数据库之一有一些奇怪的行为，我想在实体关系图中解释这些行为。
其中一个行为是有一个“预订”表和一个“发票”表。当“预订”开具发票时，记录将插入“发票”表中，然后从“预订”表中删除。
但是，仍然保留预订号码的参考信息。
我们如何建模？表格之间的大箭头和旁边的一些文字描述了发生了什么？
不，目前无法更改数据库架构
编辑：这是我想要使用的图表类型： 替代文本 http://img813.imageshack.us/img813/5601/erdartistperformssong.png< /a> 链接
One of the databases that I'm working on has some quirky behavior that I want to account for in the entity-relationship diagram.
One of the behaviors is that there is a 'booking' table and a 'invoice' table. When a 'booking' is invoiced, then the record is inserted into the 'invoice' table and then deleted from the 'booking' table.
However, a reference is still kept of the booking number.
How do we model this? Big arrow between the tables and some text beside it describing what happens?
No, changing the database schema is not possible at this point in time
Edit: This is the type of diagram that I want to use:
alt text http://img813.imageshack.us/img813/5601/erdartistperformssong.png
Link
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果 ERD 指的是原始的“Chen”图，其中关系是用菱形写的文字，那么 Booking 和 Invoice 之间就有关系。这是一种特殊的关系，不是用简单的外键实现的；它是通过复杂的移动和约束来实现的。
如果您所说的 ERD 是指 ERwin 绘制的图表，那么您就没有一种简单的方法来做到这一点。它往往会让你专注于绘制 PK-FK 关系。这些事物之间存在非PK-FK关系。您所能做的就是某种带有文本的线条。
顺便说一句，箭头并不合适，因为 ERD 显示数据库的“状态”。流动的数据不是 ERD 的一部分。你们确实有关系，只是不是典型的PK-FK关系。这是一种非典型关系，基于某些地方存在而其他地方不存在的行。
在 UML 中，您可以轻松地将其绘制为关系之间的“约束”。
If, by ERD, you mean the original "Chen" diagrams where the relationship was words written in a diamond, then you have a relationship between between Booking and Invoice. It's a special kind of relationship that's NOT implemented with a simple foreign key; it's implemented via a complicated move and a constraint.
If, by ERD, you mean the diagrams that ERwin draws, then you don't have an easy way to do this. It tends to focus you on drawing PK-FK relationships. You have a non-PK-FK relationship between these things. Some kind of line with text is about all you can do.
Arrows, BTW, aren't appropriate because the ERD shows the "state" of the database. Data flowing around isn't part of an ERD. You do have a relationship, it's just not a typical PK-FK relationship. It's an atypical relationship based on rows existing in some places and not existing in others.
In the UML you can easily draw this as a "constraint" among the relationships.
我不知道这些人在说什么。
实体关系图没有完全描述数据；是的，当然，它只显示实体和关系，不显示属性。这就是为什么它被称为 ERD 而不是数据模型。显然这里很多人都分不清其中的区别。
数据模型应该尽可能多地显示。但这取决于 (a) 您使用的标准 [如果有] 和 (b) 表示法。有些人比其他人表现得更多。 IDEF1X 是唯一的关系建模标准（NIST 184 of 1993）。它是最完整的，并且显示了其他符号所没有显示的复杂性。最近，MS 和其他人推出了“简化”符号，当然，“ERD”中丢失了很多内容。
它不是“流程”，它是数据库中的关系。
UML 完全不适合对数据进行建模，尤其是当至少有一个标准加上几个非标准但常用的数据建模符号时。没有什么可以在 UML 中显示而不能在 IDEF1X 中显示。但这里的大多数开发人员从未听说过它（开发人员不应该建模，除非他们已经获得了建模技能，但那是另一回事了）..
ERwin 是唯一实现 IDEF1X 的建模（而非图表）工具，因此拥有 IDEF1X 表示法的完整补充。
当然，标准、建模能力，都在头脑中，而不在工具中。我使用简单的绘图工具绘制符合 IDEF1X 标准的数据模型。
我发现一些开发人员对子类型符号犹豫不决，因此我在 IDEF1X 模型中展示了一个简化版本（左）；它的目的是传达排他性的感觉，而在父端保留单行表明它是一个子类型。
洛特：点击此处▶链接到数据模型◀Lott：单击此处
IDEF1X 表示法链接，适合那些不熟悉关系建模标准的人。
I don't know what these people are talking about.
The Entity Relation Diagram doesn't describe the data fully; yes of course, it only shows Entities and Relations, it doesn't show Attributes. That's why it is called an ERD and not a Data Model. Evidently many people here can't tell the difference.
The Data Model is supposed to show as much as possible. But it depends on (a) the standard [if any] that you use and (b) the Notation. Some show more than others. IDEF1X which is the only Relational modelling Standard (NIST 184 of 1993). It is the most complete, and shows intricacies and complexities that other notations do not show. Recently MS and others have come out with "simplified" notations, of course, much is lost in the "ERDs".
It is not "process flow", it is a relation in a database.
UML is completely inappropriate for modelling data, especially when there is at least one Standard plus several non-standard but commonly used data modelling notations. There is nothing that can be shown in UML that can't be shown in IDEF1X. But most developers here have never heard of it (developers should not be modelling unless they have acquired modelling skills, but that is another story)..
This is a perfectly legal; it may not be commonly known, but it is legal and named. It is a Supertype-Subtype relation, except that the Cardinality is 1::0-n instead of 1::0-1. The IDEF1X Notation (right) has a Subtype symbol. Note there is only one relation at the parent end; and one each at the child end. And of course the crows feet show the cardinality. These relations can be Exclusive or Non-exclusive; yours is Exclusive; that is what the X through the half-circle means.
ERwin is the only modelling (not diagramming) tool that implements IDEF1X, and thus has the full complement of the IDEF1X Notation.
Of course, the Standard, the modelling capability, are all in the mind, not in the tool. I draw Data Models that are IDEF1X-compliant using a simple drawing tool.
I find that some developers baulk at the Subtype symbol, so I show a simplified version (left) in my IDEF1X models; it is intended to convey the sense of exclusivity, while the retention of the single line at the parent end indicates it is a subtype.
Lott: Click here▶Link to Data Model◀Lott: Click here
Link to IDEF1X Notation for those who are unfamiliar with the Relational Modelling Standard.
听起来像是一个流程，而不是实体关系。如果当时将条目添加到发票中，并将条目从预订中删除，则两者之间永远不存在关系。永远不存在可以遍历该关系的情况，因为两个地方都不存在可以关联在一起的记录。
ERD 没有完整地描述数据库。还有其他内容，例如流程和用例，详细介绍了系统的其他方面。
这有点类似于软件的 UML。类图不会向您显示类交互的所有不同方式。一个类可能在本地初始化并调用另一个类的函数，但由于不存在将这两个类关联起来的组合或继承，因此类图不会显示这种关系。只有当您使用所有各种类型的图表完整记录系统时，您才能看到其运行方式的所有方面。
Sounds like a process flow, not an entity relationship. If at the time the entry is added to invoice, and the entry is deleted from booking, then there is never a relationship between the two. There is never a situation where you can traverse that relationship because there is never a record in both places that can be related together.
ERD don't describe the database fully. There are other things like process flow and use cases that detail other facets of the system.
This is kind of an analogy to UML for software. A class diagram doesn't show you all the different ways classes interact. One class might initialize locally and call functions of another class, but because there is not composition or inheritance that relates those two classes, then the class diagram doesn't show this relationship. Only when you fully document the system with all the various types of diagrams can you see all the facets of how it operates.