ER图是哪一张

Question

当我浏览 ER 图教程时，我开始研究 ER 图，我发现了类似图 1 的内容，并且我学到了

图1

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

图2

然后我在 Google 图像中浏览了 ER 图，我得到了两种类型的图像...我不知道这两种图之间的相似点和区别..

你能帮助我详细了解并进一步推进吗...提前致谢...

Answer 1

然后我在 Google 图像中浏览了 ER 图，我得到了两种类型的图像...我不知道这两种图之间的相似点和区别..

你能帮助我详细了解并进一步推进吗...提前致谢...

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

这项技术（如其他答案中提到的）是由一位名叫Peter Chen的美国人（？）开发的，如今被广泛用于开发数据库结构（例如表）以及它们之间的关系。

显示的第一张图像代表了相应问题/情况的概念模型。第二张图像是问题/情况的物理模型。这两个模型都是 Peter Chen 的数据建模整体概念（实体关系图）的一部分。

它们（模型）代表问题/情况过程中的阶段。当您获得问题/情况的描述时，您开始开发它的概念模型。准备就绪后，模型将被分解为称为逻辑模型的新模型。

逻辑模型随后也被分解，产生物理模型，这是数据库表结构的最终表示，其中包含字段名称、数据类型、表之间的关系、主键、外键等。

分解过程遵循 Peter Chen 提出的严格规则。这说明你不画废话。你制作了一个模型，需要遵循规则来分解它，以便进入下一个阶段。

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

• 甚至在概念模型存在之前，我们就必须在论文（或文档）上描述问题（业务规则的需求）。您将在这里生成/启动概念模型。该文档甚至可能是概念模型之前的一个新阶段，称为描述模型（这不是 Peter Chen 的官方说法）。在那里你将了解一切的背景。
• 上下文应该仅针对应保留的内容（在数据库中）给出。没有必要去描述没有持久化的东西。您的描述性模型不应包含不必要的内容。
• 在概念模型的开发过程中，完全忘记什么是表和外键是至关重要的。这些事情只会在这个发展阶段减慢你的速度。他们应该稍后在接下来的阶段被看到。

我建议您了解更多有关实体关系模型（又名实体关系图）的信息，并进行研究。有关于这个主题的很酷的书籍，互联网上也有很多材料。相信我，掌握了这一点后，数据库的开发将变得更加容易和愉快。

如果您有重大问题，请发表评论，我会解答。快来加入社区吧。遵循实体关系标签。有许多有趣的问题可以帮助您的学习。另外，继续询问，继续参与。我们来这里是为了交流知识！

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

编辑

我感谢谁给我看了这个。

Answer 2

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

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

Answer 3

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

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

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