ER图是哪一张
Which one is ER diagram
当我浏览 ER 图教程时，我开始研究 ER 图，我发现了类似图 1 的内容并且我学会了
图一
然后我尝试在 mysql 中创建示例 ER 图 workbench 我得到了如下图所示的组件
图2
然后我浏览了 Google 图像作为 ER 图我得到了两种类型的图像...我不知道这两种图之间的异同..
你能帮我详细了解一下并进一步...
提前致谢...
你的第一个图是一个合适的 ER 图，使用了 Peter Chen 在他的论文 The Entity-Relationship Model - Toward a Unified View of Data 中开发的概念和符号。这种符号描述了实体（矩形）和关系（菱形）。在此符号中很容易表示和可见三元和更高的关系。
您的第二张图通常称为 ER 图。它不区分实体和关系，而是生成这些图表的应用程序往往会将表与实体混淆，将关系与外键约束混淆。这些图与网络数据模型的共同点多于与实体关系模型的共同点，因为它们只描述了表之间的二元关系，而不是实体之间的 n 元关系。
第一个是实体关系图，尽管它非常具体并且可以省略很多废话。您可以使用一些简单的约定来声明表之间的关系，例如表示 "one to one"、"one to many" 或 "many to many" 的箭头，但我发现大多数时候只知道存在关系够用了。
这是一个非常高级的 ERD 示例，它只是在系统的不同部分之间建立连接：
此时通常无需详细说明。任何不熟悉该项目的人都会立即了解您的数据是如何构建的，如果他们想了解更多关于实施的信息，他们可以深入到数据库级别。
第二个神器有一个数据库图，一般在细节方面非常具体。
从一个非常简单的 ERD 开始设计您的应用程序通常更容易，然后对其进行迭代直到您满意为止，然后根据数据库表、字段和关系来实现它。如果您愿意，可以在此时使用数据库设计工具来实现它。
Then i browsed in Google images as ER Diagram i got both types of
images... I dont know the similarities and difference between both
diagrams..
Can u please help me to understand in detail and to move further...
Thanks in Advance...
通过开发数据库，DBA（或其他人）可以使用 Data Modeling technique known as Entity-Relationship Diagram。
这项技术（如其他答案中所述）是由一位名叫 Peter Chen 的美国人 (?) 开发的，如今广泛用于开发数据库结构（例如表）以及它们之间的关系。
显示的第一张图片代表应得的概念模型 problem/situation。第二张图片是 problem/situation 的物理模型。这两种模型都是 Peter Chen 的实体关系图数据建模整个概念的一部分。
它们（模型）代表 problem/situation 过程中的各个阶段。当您获得 problem/situation 的描述时，您开始开发它的概念模型。一旦准备就绪，模型将被分解成为一个新模型，称为逻辑模型。
逻辑模型随后也被分解，产生物理模型，它是数据库表结构的最终表示，包含字段名称、它们的数据类型、表之间的关系、主键、外键，等等。
分解过程遵循 Peter Chen 提出的严格规则。这说明你不画废话。你做了一个模型，需要按照规则来分解它，这样你才能进入下一阶段。
您可以将实体关系图视为一种工具或技术，可帮助您开发强大而简洁的数据库结构。使用这种技术，您可以创建一个模型（实际上是 3 个）来表达 system/web 应用程序中所需的业务规则。但是，请记住以下事项：
- 甚至在概念模型存在之前，我们就必须
在纸上（或
文档）。在这里，您将 generate/start 一个概念
模型。该文档甚至可能是概念性文档之前的一个新阶段
模型，称为Descriptive Model（这个不是Peter Chen官方的）。
这就是您将拥有所有内容的地方。
- 只应为应该持久化的内容提供上下文（在
数据库）。没有必要描述不是的东西
坚持。您的描述性模型不应包含不必要的
东西。
- 在概念模型的开发过程中，至关重要的是
你完全忘记了什么是表和外键。这些东西
只会在这个开发阶段减慢你的速度。他们应该
稍后会在下一阶段看到。
我建议你多了解一下实体关系模型（A.K.A。实体关系图），并研究它。有很多关于这个主题的好书，互联网上有很多 material。掌握了这一点，相信我，数据库的开发将会变得更加轻松愉快。
如有重大问题，请发表评论，我会一一解答。快来加入社区吧。遵循实体关系标签。有许多有趣的问题可以帮助您学习。另外，继续提问，继续参与。 我们是来交流知识的！
哦，还有一件事。不同的专业人士使用某些不同的符号。例如，有些人将基数表示为 N...1，其他人表示为 N-1，其他人表示为 (N,1)。这些特征不会改变最终结果。
编辑
谢谢谁给我看了this。
图 1 是一个实体关系图，它显示了实体之间的抽象关系和属性。
图 2 是一个关系架构图，它更进一步并指定了外键、属性的数据类型和 one-to-many/many-to-many 关系。
两者都是数据库的概念设计，老实说，每一个都添加和删除了一些方面。
当我浏览 ER 图教程时，我开始研究 ER 图，我发现了类似图 1 的内容并且我学会了
图一
然后我尝试在 mysql 中创建示例 ER 图 workbench 我得到了如下图所示的组件
图2
然后我浏览了 Google 图像作为 ER 图我得到了两种类型的图像...我不知道这两种图之间的异同..
你能帮我详细了解一下并进一步... 提前致谢...
你的第一个图是一个合适的 ER 图，使用了 Peter Chen 在他的论文 The Entity-Relationship Model - Toward a Unified View of Data 中开发的概念和符号。这种符号描述了实体（矩形）和关系（菱形）。在此符号中很容易表示和可见三元和更高的关系。
您的第二张图通常称为 ER 图。它不区分实体和关系，而是生成这些图表的应用程序往往会将表与实体混淆，将关系与外键约束混淆。这些图与网络数据模型的共同点多于与实体关系模型的共同点，因为它们只描述了表之间的二元关系，而不是实体之间的 n 元关系。
第一个是实体关系图，尽管它非常具体并且可以省略很多废话。您可以使用一些简单的约定来声明表之间的关系，例如表示 "one to one"、"one to many" 或 "many to many" 的箭头，但我发现大多数时候只知道存在关系够用了。
这是一个非常高级的 ERD 示例，它只是在系统的不同部分之间建立连接：
此时通常无需详细说明。任何不熟悉该项目的人都会立即了解您的数据是如何构建的，如果他们想了解更多关于实施的信息，他们可以深入到数据库级别。
第二个神器有一个数据库图，一般在细节方面非常具体。
从一个非常简单的 ERD 开始设计您的应用程序通常更容易，然后对其进行迭代直到您满意为止，然后根据数据库表、字段和关系来实现它。如果您愿意，可以在此时使用数据库设计工具来实现它。
Then i browsed in Google images as ER Diagram i got both types of images... I dont know the similarities and difference between both diagrams..
Can u please help me to understand in detail and to move further... Thanks in Advance...
通过开发数据库，DBA（或其他人）可以使用 Data Modeling technique known as Entity-Relationship Diagram。
这项技术（如其他答案中所述）是由一位名叫 Peter Chen 的美国人 (?) 开发的，如今广泛用于开发数据库结构（例如表）以及它们之间的关系。
显示的第一张图片代表应得的概念模型 problem/situation。第二张图片是 problem/situation 的物理模型。这两种模型都是 Peter Chen 的实体关系图数据建模整个概念的一部分。
它们（模型）代表 problem/situation 过程中的各个阶段。当您获得 problem/situation 的描述时，您开始开发它的概念模型。一旦准备就绪，模型将被分解成为一个新模型，称为逻辑模型。
逻辑模型随后也被分解，产生物理模型，它是数据库表结构的最终表示，包含字段名称、它们的数据类型、表之间的关系、主键、外键，等等。
分解过程遵循 Peter Chen 提出的严格规则。这说明你不画废话。你做了一个模型，需要按照规则来分解它，这样你才能进入下一阶段。
您可以将实体关系图视为一种工具或技术，可帮助您开发强大而简洁的数据库结构。使用这种技术，您可以创建一个模型（实际上是 3 个）来表达 system/web 应用程序中所需的业务规则。但是，请记住以下事项：
- 甚至在概念模型存在之前，我们就必须 在纸上（或 文档）。在这里，您将 generate/start 一个概念 模型。该文档甚至可能是概念性文档之前的一个新阶段 模型，称为Descriptive Model（这个不是Peter Chen官方的）。 这就是您将拥有所有内容的地方。
- 只应为应该持久化的内容提供上下文（在 数据库）。没有必要描述不是的东西 坚持。您的描述性模型不应包含不必要的 东西。
- 在概念模型的开发过程中，至关重要的是 你完全忘记了什么是表和外键。这些东西 只会在这个开发阶段减慢你的速度。他们应该 稍后会在下一阶段看到。
我建议你多了解一下实体关系模型（A.K.A。实体关系图），并研究它。有很多关于这个主题的好书，互联网上有很多 material。掌握了这一点，相信我，数据库的开发将会变得更加轻松愉快。
如有重大问题，请发表评论，我会一一解答。快来加入社区吧。遵循实体关系标签。有许多有趣的问题可以帮助您学习。另外，继续提问，继续参与。 我们是来交流知识的！
哦，还有一件事。不同的专业人士使用某些不同的符号。例如，有些人将基数表示为 N...1，其他人表示为 N-1，其他人表示为 (N,1)。这些特征不会改变最终结果。
编辑
谢谢谁给我看了this。
图 1 是一个实体关系图，它显示了实体之间的抽象关系和属性。
图 2 是一个关系架构图，它更进一步并指定了外键、属性的数据类型和 one-to-many/many-to-many 关系。
两者都是数据库的概念设计，老实说，每一个都添加和删除了一些方面。