实体关系图

【Entity Relationship Diagrams】

实体-关系模型（或 ER 模型）描述了特定知识字段中相互关联的感兴趣事物。一个基本的 ER 模型由实体类型（用于分类感兴趣的事物）组成，并且指定了实体（这些实体类型的实例）之间可以存在的关系 维基百科。

请注意，ER 建模的实践者几乎总是将“实体类型”简单地称为“实体”。例如，CUSTOMER实体类型通常被直接称为CUSTOMER实体。这种用法非常普遍，以至于不建议使用其他方式，但从技术上讲，实体是实体类型的抽象实例，而 ER 图显示的正是这些抽象实例以及它们之间的关系。这也是实体名称总是使用单数名词的原因。

【Note that practitioners of ER modelling almost always refer to entity types simply as entities. For example the CUSTOMER entity type would be referred to simply as the CUSTOMER entity. This is so common it would be inadvisable to do anything else, but technically an entity is an abstract instance of an entity type, and this is what an ER diagram shows - abstract instances, and the relationships between them. This is why entities are always named using singular nouns.】

Mermaid 可以生成 ER 图

【Mermaid can render ER diagrams】

实体名称通常会大写，尽管对此没有公认的标准，而且在 Mermaid 中也不要求这样做。

【Entity names are often capitalised, although there is no accepted standard on this, and it is not required in Mermaid.】

实体之间的关系用带有表示基数的端点标记的线表示。Mermaid 使用最流行的乌鸦脚符号。乌鸦脚直观地表示它所连接的实体可能有多个实例。

【Relationships between entities are represented by lines with end markers representing cardinality. Mermaid uses the most popular crow's foot notation. The crow's foot intuitively conveys the possibility of many instances of the entity that it connects to.】

ER 图可以用于各种用途，从不包含任何实现细节的抽象逻辑模型，到关系数据库表的物理模型。 在 ER 图上包含属性定义有助于理解实体的用途和含义，这通常是有用的。 这些属性定义不必详尽无遗；通常一小部分属性就足够了。 Mermaid 允许以其类型和名称来定义它们。

【ER diagrams can be used for various purposes, ranging from abstract logical models devoid of any implementation details, through to physical models of relational database tables. It can be useful to include attribute definitions on ER diagrams to aid comprehension of the purpose and meaning of entities. These do not necessarily need to be exhaustive; often a small subset of attributes is enough. Mermaid allows them to be defined in terms of their type and name.】

在 ER 图中包含属性时，你必须决定是否将外键作为属性包含。这可能取决于你希望多大程度上表示关系表结构。如果你的图是一个逻辑模型，并不打算暗示关系实现，那么最好不要包含这些属性，因为关联关系已经传达了实体之间的关联方式。例如，JSON 数据结构可以在没有外键属性的情况下使用数组实现一对多关系。类似地，面向对象编程语言可以使用指针或对集合的引用。即使对于那些旨在进行关系实现的模型，你也可能会认为包含外键属性会重复关系已经展示的信息，并且不会给实体增加意义。最终，这取决于你自己。

【When including attributes on ER diagrams, you must decide whether to include foreign keys as attributes. This probably depends on how closely you are trying to represent relational table structures. If your diagram is a logical model which is not meant to imply a relational implementation, then it is better to leave these out because the associative relationships already convey the way that entities are associated. For example, a JSON data structure can implement a one-to-many relationship without the need for foreign key properties, using arrays. Similarly an object-oriented programming language may use pointers or references to collections. Even for models that are intended for relational implementation, you might decide that inclusion of foreign key attributes duplicates information already portrayed by the relationships, and does not add meaning to entities. Ultimately, it's your choice.】

语法

【Syntax】

实体与关系

【Entities and Relationships】

用于 ER 图的 Mermaid 语法与 PlantUML 兼容，并扩展了用于标记关系的功能。每条语句包括以下部分：

【Mermaid syntax for ER diagrams is compatible with PlantUML, with an extension to label the relationship. Each statement consists of the following parts:】

    <first-entity> [<relationship> <second-entity> : <relationship-label>]

地点：

【Where:】

• first-entity 是一个实体的名称。名称支持任何 Unicode 字符，并且如果用双引号括起来，可以包含空格（例如 "name with space"）。
• relationship 描述两个实体之间的关系。详见下文。
• second-entity 是另一个实体的名称。
• relationship-label 从第一个实体的角度描述其与另一个实体的关系。

例如：

【For example:】

    PROPERTY ||--|{ ROOM : contains

这句话可以理解为“一个属性包含一个或多个房间，而一个房间只属于一个属性”。你可以看到，这里的标签是从第一个实体的角度来看：一个属性包含一个房间，但一个房间不包含属性。从第二个实体的角度来看，等效的标签通常很容易推断出来。（一些 ER 图会从两个角度标注关系，但这里不支持，而且通常也是多余的）。

【This statement can be read as a property contains one or more rooms, and a room is part of one and only one property. You can see that the label here is from the first entity's perspective: a property contains a room, but a room does not contain a property. When considered from the perspective of the second entity, the equivalent label is usually very easy to infer. (Some ER diagrams label relationships from both perspectives, but this is not supported here, and is usually superfluous).】

语句中只有 first-entity 部分是必填的。这使得显示没有关系的实体成为可能，这在迭代构建图表时非常有用。如果指定了语句的其他部分，则所有部分都是必填的。

【Only the first-entity part of a statement is mandatory. This makes it possible to show an entity with no relationships, which can be useful during iterative construction of diagrams. If any other parts of a statement are specified, then all parts are mandatory.】

Unicode 文本

【Unicode text】

实体名称、关系和属性都支持 Unicode 文本。

【Entity names, relationships, and attributes all support unicode text.】

Markdown 格式

【Markdown formatting】

也支持 Markdown 格式和文本。

【Markdown formatting and text is also supported.】

关系语法

【Relationship Syntax】

每个陈述中的“relationship”部分可以分解为三个子组件：

【The relationship part of each statement can be broken down into three sub-components:】

• 第一个实体相对于第二个实体的基数
• 关系是否赋予“子”实体身份
• 第二个实体相对于第一个实体的基数

基数是一个属性，用来描述另一个实体可以与所涉及的实体相关联的元素数量。在上面的例子中，一个 PROPERTY 可以关联一个或多个 ROOM 实例，而一个 ROOM 只能关联一个 PROPERTY。在每个基数标记中有两个字符。最外层的字符表示最大值，最内层的字符表示最小值。下表总结了可能的基数。

【Cardinality is a property that describes how many elements of another entity can be related to the entity in question. In the above example a PROPERTY can have one or more ROOM instances associated to it, whereas a ROOM can only be associated with one PROPERTY. In each cardinality marker there are two characters. The outermost character represents a maximum value, and the innermost character represents a minimum value. The table below summarises possible cardinalities.】

数值（左）	数值（右）	含义
|o	o|	零或一
||	||	恰好一个
}o	o{	零个或多个（无限上限）
}|	|{	一个或多个（无限上限）

别名

值（左）	值（右）	别名
一或零	一或零	零或一
零或一	零或一	零或一
一或多个	一或多个	一或多个
一或许多	一或许多	一或多个
多(1)	多(1)	一或多个
1+	1+	一或多个
零或多个	零或多个	零或多个
零或许多	零或许多	零或多个
多(0)	多(0)	零或多个
0+	0+	零或多个
仅一个	仅一个	恰好一个
1	1	恰好一个

身份识别

【Identification】

关系可以分为 标识型 或 _ 非标识型 _，分别用实线或虚线表示。当其中一个实体无法在没有另一个实体的情况下独立存在时，这很重要。例如，一家为人们驾驶汽车提供保险的公司可能需要存储 NAMED-DRIVER 的数据。在建模时，我们可能首先观察到，一个 CAR 可以由许多 PERSON 驾驶，而一个 PERSON 可以驾驶许多 CAR - 两者都可以在没有对方的情况下存在，因此这是一个非标识型关系，我们可以在 Mermaid 中指定为：PERSON }|..|{ CAR : "driver"。注意关系中间的两个点，这将导致在两个实体之间绘制虚线。但是，当这种多对多关系被拆分为两个一对多关系时，我们会发现一个 NAMED-DRIVER 不可能在没有 PERSON 和 CAR 的情况下存在 - 这些关系变成了识别关系，并且会用连字符表示，对应的就是一条实线：

【Relationships may be classified as either identifying or non-identifying and these are rendered with either solid or dashed lines respectively. This is relevant when one of the entities in question cannot have independent existence without the other. For example a firm that insures people to drive cars might need to store data on NAMED-DRIVERs. In modelling this we might start out by observing that a CAR can be driven by many PERSON instances, and a PERSON can drive many CARs - both entities can exist without the other, so this is a non-identifying relationship that we might specify in Mermaid as: PERSON }|..|{ CAR : "driver". Note the two dots in the middle of the relationship that will result in a dashed line being drawn between the two entities. But when this many-to-many relationship is resolved into two one-to-many relationships, we observe that a NAMED-DRIVER cannot exist without both a PERSON and a CAR - the relationships become identifying and would be specified using hyphens, which translate to a solid line:】

值	别名
--	识别型
..	非识别型

别名

值	别名
to	标识性
可选 to	非标识性

属性

【Attributes】

可以通过指定实体名称，然后跟随一个包含多个 类型 名称 对的块来为实体定义属性，其中块由一个开括号 { 和一个闭括号 } 包围。属性会显示在实体框内。例如：

【Attributes can be defined for entities by specifying the entity name followed by a block containing multiple type name pairs, where a block is delimited by an opening { and a closing }. The attributes are rendered inside the entity boxes. For example:】

type 值必须以字母字符开头，并且可以包含数字、连字符、下划线、圆括号和方括号。name 值的格式与 type 类似，但也可以以星号开头，作为表示属性为主键的另一种选择。除此之外，没有其他限制，也没有隐含的有效数据类型集合。

【The type values must begin with an alphabetic character and may contain digits, hyphens, underscores, parentheses and square brackets. The name values follow a similar format to type, but may start with an asterisk as another option to indicate an attribute is a primary key. Other than that, there are no restrictions, and there is no implicit set of valid data types.】

实体名称别名

【Entity Name Aliases】

可以使用方括号为实体添加别名。如果提供了别名，图表中将显示别名而不是实体名称。别名名称遵循与实体名称相同的所有规则。

【An alias can be added to an entity using square brackets. If provided, the alias will be showed in the diagram instead of the entity name. Alias names follow all of the same rules as entity names.】

属性键和值说明

【Attribute Keys and Comments】

属性也可以定义 key 或注释。键可以是 PK、FK 或 UK，分别表示主键、外键或唯一键（键不支持 Markdown 格式和 Unicode）。要在单个属性上指定多个键约束，用逗号分隔它们（例如，PK, FK）。comment 通过属性末尾的双引号定义。注释中不能包含双引号字符。

【Attributes may also have a key or comment defined. Keys can be PK, FK or UK, for Primary Key, Foreign Key or Unique Key (markdown formatting and unicode is not supported for keys). To specify multiple key constraints on a single attribute, separate them with a comma (e.g., PK, FK). A comment is defined by double quotes at the end of an attribute. Comments themselves cannot have double-quote characters in them.】

方向

【Direction】

方向声明说明了图表的方向。

【The direction statement declares the direction of the diagram.】

这表示图表的方向是从上到下（TB）。可以将其反转为从下到上（BT）。

【This declares that the diagram is oriented from top to bottom (TB). This can be reversed to be oriented from bottom to top (BT).】

这表示图表的方向是从左到右（LR）。可以将其反向设置为从右到左（RL）。

【This declares that the diagram is oriented from left to right (LR). This can be reversed to be oriented from right to left (RL).】

可能的图表方向包括：

【Possible diagram orientations are:】

• TB - 从上到下
• BT - 从下到上
• RL - 从右到左
• LR - 从左到右

为节点设置样式

【Styling a node】

可以为节点应用特定样式，例如更粗的边框或不同的背景颜色。

【It is possible to apply specific styles such as a thicker border or a different background color to a node.】

也可以在一条语句中将样式附加到节点列表上：

【It is also possible to attach styles to a list of nodes in one statement:】

    style nodeId1,nodeId2 styleList

类

【Classes】

比每次都定义样式更方便的方法是定义一个样式类，并将该类附加到需要不同外观的节点上。

【More convenient than defining the style every time is to define a class of styles and attach this class to the nodes that should have a different look.】

类定义看起来像下面的示例：

【A class definition looks like the example below:】

    classDef className fill:#f9f,stroke:#333,stroke-width:4px

也可以在一个语句中定义多个类：

【It is also possible to define multiple classes in one statement:】

    classDef firstClassName,secondClassName font-size:12pt

将类附加到节点的操作如下：

【Attachment of a class to a node is done as per below:】

    class nodeId1 className

也可以在一条语句中将一个类附加到节点列表上：

【It is also possible to attach a class to a list of nodes in one statement:】

    class nodeId1,nodeId2 className

多个类也可以同时附加：

【Multiple classes can be attached at the same time as well:】

    class nodeId1,nodeId2 className1,className2

添加类的简短方式是使用 ::: 操作符将类名附加到节点，如下所示：

【A shorter form of adding a class is to attach the classname to the node using the :::operator as per below:】

在声明实体之间的关系时，可以使用此表格：

【This form can be used when declaring relationships between entities:】

类似于 class 语句，简写语法也可以一次应用多个类：

【Similar to the class statement, the shorthand syntax can also apply multiple classes at once:】

    nodeId:::className1,className2

默认类

【Default class】

如果一个类被命名为 default，它将被分配给所有没有特定类定义的类。

【If a class is named default it will be assigned to all classes without specific class definitions.】

    classDef default fill:#f9f,stroke:#333,stroke-width:4px;

注意： 来自 style 或其他类语句的自定义样式具有优先权，会覆盖默认样式。（例如，default 类为节点设置粉色背景，但如果应用了 blue 类，该节点将会显示蓝色背景。）

配置

【Configuration】

布局

【Layout】

图表的布局由 render() 处理。默认布局是 dagre。

【The layout of the diagram is handled by render(). The default layout is dagre.】

对于更大或更复杂的图表，你也可以使用 YAML frontmatter 中的 config 来应用 ELK（Eclipse 布局内核）布局。更多信息，请参见 自定义 ELK 布局。

【For larger or more-complex diagrams, you can alternatively apply the ELK (Eclipse Layout Kernel) layout using your YAML frontmatter's config. For more information, see Customizing ELK Layout.】

---
config:
  layout: elk
---

你的 Mermaid 代码应该类似于以下内容：

【Your Mermaid code should be similar to the following:】

信息

请注意，网站需要使用 Mermaid 版本 9.4 以上才能实现此功能，并且需要在懒加载配置中启用此功能。