MySQL 哪个是ER图

Which one is ER diagram

提问by Monicka Akilan

I started to study ER diagram when i browse through ER diagram tutorials i found something like figure 1 and i learned

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

Figure 1

图1

And then i tried to create a sample ER Diagram in mysql workbench i got the components like in below diagram

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

Figure 2

图2

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..

然后我在谷歌图片中浏览了 ER Diagram 我得到了两种类型的图像......我不知道这两种图表之间的异同......

Can u please help me to understand in detail and to move further... Thanks in Advance...

能否请您帮我详细了解并进一步...提前致谢...

采纳答案by Loa

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...

然后我在谷歌图片中浏览了 ER Diagram 我得到了两种类型的图像......我不知道这两种图表之间的异同......

能否请您帮我详细了解并进一步...提前致谢...

By developing databases, a DBA (or someone else) can use a Data Modelingtechnique known as Entity-Relationship Diagram.

通过开发数据库，​​DBA（或其他人）可以使用称为Entity-Relationship Diagram的数据建模技术。

This technique (as mentioned in other answers) was developed by an American (?) named Peter Chenand it is widely used today for the development of database structures such as tables and present relations between them.

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

The first image shown represents a Conceptual Model of a due problem/situation. The second image is a Physical Model of a problem/situation. Both models are part of the whole concept of data modeling by Peter Chen, the Entity-Relationship Diagram.

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

They (the models) represent stages in the course of a problem/situation. As you get a description of the problem/situation, you begin to develop the Conceptual Model of it. Once ready, the model is decomposed to become a new model called the Logical Model.

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

The Logical Model is also subsequently decomposed, resulting in the Physical Model, a final representation of the structures of the tables of a database containing the field names, their data types, relationships between tables, primary keys, foreign keys , and so on.

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

The decomposition process follows strict rules proposed by Peter Chen. This says that you do not draw nonsense. You make a model and need to follow rules to break it down so that you pass to the next stage.

分解过程遵循 Peter Chen 提出的严格规则。这说明你不要胡说八道。您制作了一个模型，需要遵循规则将其分解，以便进入下一阶段。

You can see the Entity-Relationship Diagram as a tool or technique that helps you to develop a strong and concise database structure. With this technique, you can create a Model (3 actually) expressing business rules needed in a system/web application. However, remember the following things:

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

• Even before the existence of the Conceptual Model, we have to describe the problem (the needs of business rules) on a paper (or a document). It is here that you will generate/start a Conceptual Model. This document may even be a new phase, prior to the Conceptual Model, called Descriptive Model (this is not official by Peter Chen). That's where you will have the context of everything.
• The context should be given only for what should be persisted (in a database). There is no need to describe things that are not persisted. Your Descriptive Model should not contain unnecessary things.
• During the development of the Conceptual Model, it is crucial that you forget completely what are tables and foreign keys. These things will only slow you down during this phase of development. They should be seen later, during the next stages.

• 甚至在概念模型存在之前，我们就必须在纸（或文档）上描述问题（业务规则的需求）。您将在此处生成/启动概念模型。该文档甚至可能是概念模型之前的一个新阶段，称为描述模型（这不是 Peter Chen 的官方文件）。这就是您将拥有所有内容的地方。
• 应该只为应该持久化的内容（在数据库中）提供上下文。没有持久化的东西就不用描述了。您的描述性模型不应包含不必要的东西。
• 在概念模型的开发过程中，完全忘记什么是表和外键是至关重要的。在这个开发阶段，这些事情只会减慢你的速度。他们应该在以后的阶段看到。

I advise you to find out more about the Entity-Relationship Model (A.K.A. Entity-Relationship Diagram), and study about it. There are cool books on the subject, and a lot of material on the Internet. Having grasped this, believe me, the development of databases will become something much easier and enjoyable.

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

If you have major questions, please make a comment and I will answer. Come join the community. Follow the entity-relationship tag. There are many interesting questions that can help you in your studies. Also, keep asking, keep participating. We are here to exchange knowledge!

如果您有重大问题，请发表评论，我会回答。快来加入社区吧。遵循实体关系标签。有很多有趣的问题可以帮助你学习。另外，不断提问，不断参与。我们是来交流知识的！

Oh, one more thing. There are certain different notations used by different professionals. For example, some people represents cardinalities as N...1, as other N-1, other as (N,1). These characteristics do not change the end result.

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

EDIT

编辑

I thank who showed me this.

我感谢谁向我展示了这个。

回答by reaanb

Your first diagram is a proper ER diagram, using the concepts and notation developed by Peter Chen in his paper The Entity-Relationship Model - Toward a Unified View of Data. This notation depicts both entities (rectangles) and relationships (diamonds). Ternary and higher relationships are easily represented and visible in this notation.

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

Your second diagram is commonly called an ER diagram. It doesn't distinguish entities from relationships, rather the applications that produce these diagrams tend to confuse tables with entities and relationships with foreign key constraints. These diagrams have more in common with the network data model than with the entity-relationship model, since they depict only binary relationships between tables rather than n-ary relationships between entities.

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

回答by Kyle Strokes

Figure 1 is a Entity Relationship Diagram it shows abstract relationships and attributes between entities.

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

Figure 2 is a Relational Schema Diagram which goes a step further and specifies foreign keys, data types of attributes, and one-to-many/many-to-many relationships.

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

Both are conceptual designs of databases and honestly there are some aspects added and removed from each one.

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

回答by tadman

The first one is an Entity-Relationship diagram, although it's awfully specific and a lot of that cruft can be omitted. There are simple conventions you can use to declare relationships between tables, like arrows that mean "one to one", "one to many", or "many to many" but I've found that most of the time simply knowing the relationship exists is good enough.

第一个是实体关系图，尽管它非常具体并且可以省略很多细节。您可以使用一些简单的约定来声明表之间的关系，例如表示“一对一”、“一对多”或“多对多”的箭头，但我发现大多数时候只是知道存在这种关系足够好。

Here's an example of a very high-level ERD that simply establishes the connection between different parts of your system:

这是一个非常高级的 ERD 示例，它只是在系统的不同部分之间建立连接：

There's usually no need to get into specifics at this point. Anyone not familiar with the project will immediately get a sense of how your data is structured and if they want to know more about implementation they can dig into the database level.

此时通常不需要详细说明。任何不熟悉该项目的人都会立即了解您的数据的结构，如果他们想了解更多有关实施的信息，他们可以深入到数据库级别。

The second artifact there is a database diagramand is generally very specific in terms of details.

第二个工件是数据库图，通常在细节方面非常具体。

It's often easier to design your application starting with a very simple ERD, iterate on that until you're happy, then implement it in terms of database tables, fields and relationships later. This is when you'd use a database design tool to implement it if you prefer.

从一个非常简单的 ERD 开始设计您的应用程序通常更容易，直到您满意为止，然后再根据数据库表、字段和关系来实现它。如果您愿意，这是您可以使用数据库设计工具来实现它的时候。