哪一个是ER图

Question

当我浏览ER图教程时，我开始研究ER图，我发现了如图1所示的内容，我学到了

图1

​

然后我尝试在mysql工作台中创建一个示例ER图，我得到了如下所示的组件

图2

​

然后我浏览了谷歌图片作为ER图我得到了两种类型的图像..。我不知道这两幅图的相似之处。

你能不能帮我了解一下细节，并进一步了解.提前谢谢..。

Answer 1

然后我浏览了谷歌图片作为ER图我得到了两种类型的图像..。我不知道这两幅图的相似之处。 你能不能帮我了解一下细节，并进一步了解.提前谢谢..。

通过开发数据库，DBA (或其他人)可以使用称为数据建模的实体-关系图技术。

这种技术(如其他答案中提到的)是由一个美国人(?)命名为陈彼得，被广泛应用于数据库结构的开发，如表和表之间的关系。

所示的第一幅图像代表了一个关于适当问题/情况的概念模型。第二个图像是一个问题/情况的物理模型。这两个模型都是由Peter (实体-关系图)的数据建模概念的一部分.

它们(模型)代表问题/情况过程中的各个阶段。当您了解到问题/情况的描述时，就开始开发它的概念模型。一旦准备就绪，模型就会被分解成一个新的模型，称为逻辑模型。

逻辑模型随后也被分解，导致物理模型，包含字段名、它们的数据类型、表之间的关系、主键、外键等的数据库表的结构的最终表示。

分解过程遵循陈彼得提出的严格规则。这说明你不能胡说八道。你做了一个模型，需要遵循规则来分解它，这样你就可以进入下一个阶段了。

您可以将实体关系图视为帮助您开发强大而简洁的数据库结构的工具或技术。使用这种技术，您可以创建一个模型(实际上是3)来表示系统/web应用程序所需的业务规则。但是，请记住以下几点：

• 甚至在概念模型存在之前，我们就必须在纸(或文档)上描述问题(业务规则的需要)。在这里，您将生成/启动一个概念模型。本文档甚至可能是概念模型之前的一个新阶段，称为描述模型( Peter并不正式)。那就是你将拥有一切背景的地方。
• 应该只为应该持久化的内容(在数据库中)提供上下文。没有必要描述没有持久化的东西。您的描述模型不应包含不必要的内容。
• 在概念模型的开发过程中，您必须完全忘记什么是表和外键。在这个发展阶段，这些事情只会减缓你的速度。它们应在稍后阶段，在下一个阶段中看到。

我建议您了解更多关于实体-关系模型(A.K.A.实体-关系图)，并对其进行研究。有关于这个主题的很酷的书，和很多的材料在互联网上。相信我，掌握了这一点之后，数据库的开发将变得更加容易和愉快。

如果你有重大问题，请发表意见，我会回答。来加入社区吧。跟随实体-关系标签。有许多有趣的问题可以帮助你学习。还有，继续问，继续参与。我们是来交流知识的！

哦还有一件事。不同的专业人员使用了某些不同的符号。例如，有些人将基数表示为N.1，表示为其他N1，其他表示为(N,1).这些特性不会改变最终结果。

编辑

我感谢给我看这的人。

Answer 2

您的第一个图表是一个正确的ER图，使用Peter在他的论文The Entity-Relationship Model - Toward a Unified View of Data中开发的概念和符号。这个表示法描述了实体(矩形)和关系(钻石)。三元关系和更高的关系在这个表示法中很容易表示和可见。

您的第二个图表通常称为ER图。它并不区分实体和关系，而是生成这些关系图的应用程序往往会混淆表与实体，以及与外键约束的关系。这些图表与网络数据模型有更多的共同点，而不是实体-关系模型，因为它们只描述表之间的二进制关系，而不是实体之间的n元关系。

Answer 3

图1是一个实体关系图，它显示了实体之间的抽象关系和属性。

图2是一个关系模式图，它更进一步，指定外键、属性的数据类型以及一对多/多到多的关系。

两者都是数据库的概念设计，老实说，每个数据库都添加和删除了一些方面。