目录
一、转化的总则：从认知模型到逻辑结构
二、规则一：强实体的转化
三、规则二：弱实体的转化
四、规则三：二元联系的转化——1:1、1:N与M:N
五、规则四：多元联系的转化
六、规则五：自反联系的转化
七、规则六：组合联系与聚合的转化
八、规则七：继承关系的转化——父类与子类的博弈
九、结语：转化的终点是设计者的判断
一、转化的总则：从认知模型到逻辑结构
在进入具体的转化规则之前，需要首先明确转化的目标与边界。E-R模型是认知层面的工具——它用实体、属性和联系这三个概念构件来描述业务领域的语义结构。关系模型是逻辑层面的工具——它用关系模式、属性、码和完整性约束来定义数据的存储结构。转化的任务是将前者翻译为后者，翻译的结果应当满足两个标准：语义保真和结构合法。
语义保真意味着，E-R图中表达的所有业务事实——某个实体具有哪些属性、某两个实体之间存在怎样的关联、这种关联是强制性的还是可选的——在转化后的关系模式中都应当有对应的表达，且表达的语义不扭曲、不丢失。结构合法意味着，转化得到的关系模式必须满足关系模型的基本要求——每个关系有确定的主码、外码引用目标明确、满足域完整性和实体完整性。
转化的核心策略可以凝练为一条总则：实体转化为独立的关系，联系根据其基数比和参与约束决定是吸收进某个实体的关系中，还是单独成为一个关系。这条总则之下，不同类型的实体和联系有其特定的转化细则，我们将其归纳为七条规则。
二、规则一：强实体的转化
强实体是E-R模型中最常见的实体类型——它拥有自己的主标识符（即E-R图中的主码），其实例不依赖于其他实体而独立存在。典型的强实体如“学生”（主标识符为学号）、“课程”（主标识符为课程编号）、“部门”（主标识符为部门编号）。
强实体的转化规则最为简明：强实体直接转化为一个独立的关系模式，实体的属性转化为关系的列，实体的主标识符转化为关系的主码。复合属性（如“地址”由省、市、区、街道组成）展开为多个独立的列，多值属性（如一个学生的多个联系电话）则需要单独处理——通常的做法是为多值属性创建一个单独的关系，包含原实体的主码和多值属性列，二者共同构成复合主码。
例如，E-R图中的强实体“学生”，具有属性：学号（主标识符）、姓名、出生日期、性别。转化后的关系模式为：
text
学生(学号 CHAR(10) PRIMARY KEY, 姓名 VARCHAR(50), 出生日期 DATE, 性别 CHAR(1))
这个转化如此直接，以至于学习者容易低估它的重要性。但在整个转化体系中，强实体关系的确定是整个逻辑设计的骨架——其他所有联系和弱实体都围绕强实体关系展开。
三、规则二：弱实体的转化
弱实体是一类特殊的实体——它没有自己的主标识符，其存在依赖于另一个实体（称为标识实体或所有者实体）。弱实体的实例只能通过与标识实体的关联来唯一标识。一个典型的场景是：在“员工”与“家属”的联系中，“家属”的属性可能只包含“姓名”和“关系”（如配偶、子女），但仅凭姓名无法唯一标识一位家属——同一公司可能有多个员工都有名为“张三”的家属。“家属”的完整标识需要组合“所属员工的工号”和“家属姓名”才能实现。
E-R图中，弱实体用双线矩形框表示，它与标识实体之间的联系用双线菱形表示，这种联系被称为标识联系。
弱实体的转化规则为：弱实体转化为一个独立的关系模式，其属性包括弱实体自身的属性，加上标识实体的主码作为外码。该关系的主码由标识实体的主码和弱实体的部分码（即在同一标识实体内能够区分不同弱实体实例的属性）共同组成。
上述“家属”弱实体转化后的关系模式为：
text
家属(员工工号 CHAR(10), 家属姓名 VARCHAR(50), 关系 VARCHAR(20), PRIMARY KEY (员工工号, 家属姓名), FOREIGN KEY (员工工号) REFERENCES 员工(工号))
弱实体关系的主码是一个复合主码——外码“员工工号”标识了所属员工，“家属姓名”在同一员工的不同家属间做出区分。外码“员工工号”同时承担着两种身份：作为主码的一部分（参与唯一标识），又作为外码（引用标识实体）。这种双重身份是弱实体关系的标志性特征。
四、规则三：二元联系的转化——1:1、1:N与M:N
二元联系是E-R图中最常见、也是转化时最需要细致处理的部分。转化策略取决于联系的基数比。
1:1联系的转化：设实体A与实体B之间存在1:1联系R。理论上，可以将任意一方的主码作为外码加入另一方，并将联系自身的属性（如果有的话）随外码一同加入。如果联系是“部门”与“部门经理”之间的1:1“管理”联系，可以选择在“部门”表中加入“经理工号”外码，也可以在“经理”表中加入“部门编号”外码。选择哪一侧吸收外码，取决于参与约束——如果一方是全部参与（如每个部门必须有经理），而另一方是部分参与（并非每位员工都是经理），通常将外码放在全部参与侧以减少空值数量。
1:N联系的转化：这是实践中最常见的联系类型。设实体A与实体B之间存在1:N联系R，其中A为“1”方，B为“N”方。转化规则是：将“1”方的主码作为外码加入“N”方的关系中，并将联系自身的属性（如果有的话）也随外码一同加入“N”方。这一规则的逻辑基础是：对于“N”方的每一个实例，它最多关联到“1”方的一个实例，因此用一个外码列就足以存储这个关联信息。例如，“部门”（1）与“员工”（N）之间的“所属”联系，转化时在“员工”表中加入“部门编号”外码即可。
M:N联系的转化：设实体A与实体B之间存在M:N联系R。关键区别在于，此时无论将外码放在A方还是B方，都无法用一个列来存储“多个关联”的信息——一个员工选修了多门课程，在“员工”表的一行中无法用单个列存储多个课程编号。因此，M:N联系必须转化为一个独立的关系模式。这个新关系的属性包括：A的主码、B的主码（二者共同构成复合主码），以及联系自身的属性。新关系的外码分别引用A和B。
例如，“学生”与“课程”之间的“选课”M:N联系，转化后产生：
text
选课(学号 CHAR(10), 课程编号 CHAR(8), 成绩 DECIMAL(4,1), PRIMARY KEY (学号, 课程编号), FOREIGN KEY (学号) REFERENCES 学生(学号), FOREIGN KEY (课程编号) REFERENCES 课程(课程编号))
这个独立的关系模式将M:N联系还原为两个1:N联系的组合——“选课”关系中，一个学生对应多条选课记录（1:N），一门课程也对应多条选课记录（1:N），而“选课”关系本身的结构恰好承载了这种交叉关联。
五、规则四：多元联系的转化
当联系涉及三个或更多实体时，称为多元联系。例如，一个“授课”联系可能涉及“教师”、“课程”和“教室”三个实体——一位教师在特定教室教授特定课程。多元联系通常隐含M:N:P的基数结构（一位教师可以教授多门课程、使用多个教室；一门课程可以由多位教师教授、在多个教室授课；一个教室在不同时段可能由不同教师使用教授不同课程）。
多元联系的转化规则与二元M:N联系类似：多元联系必须转化为一个独立的关系模式，其属性包括所有参与实体的主码（共同构成复合主码），以及联系自身的属性。上述“授课”联系转化为：
text
授课(教师工号 CHAR(10), 课程编号 CHAR(8), 教室编号 CHAR(6), 授课时间 VARCHAR(20), PRIMARY KEY (教师工号, 课程编号, 教室编号), FOREIGN KEY (教师工号) REFERENCES 教师(工号), FOREIGN KEY (课程编号) REFERENCES 课程(课程编号), FOREIGN KEY (教室编号) REFERENCES 教室(教室编号))
主码的确定需要仔细分析基数约束。如果多元联系中存在一个实体，对于其他实体的任意组合至多出现一个实例，则其他实体的主码组合即可构成主码，而无需包含全部实体。但在多数实际场景中，多元联系需要全部参与实体的主码共同构成复合主码。
六、规则五：自反联系的转化
自反联系是一个实体集内部的联系——联系的两端都指向同一个实体集，但在联系中扮演不同的角色。典型的自反联系是“员工”实体内部的“管理”联系——一位员工（经理）管理多位员工（下属），而该经理自身也是一位员工。
自反联系的转化规则与普通二元联系一致，区别仅在于外码和引用目标属于同一个关系。对于1:N的自反联系（一位经理管理多位下属），在“员工”表中加入一列“经理工号”作为外码，该外码引用“员工”表自身的“工号”主码：
text
员工(工号 CHAR(10) PRIMARY KEY, 姓名 VARCHAR(50), 经理工号 CHAR(10), FOREIGN KEY (经理工号) REFERENCES 员工(工号))
对于M:N的自反联系（如零件之间的“装配”联系——一种零件由多种子零件组成，一种子零件也可用于多种父零件），需要转化为独立的关系模式：
text
零件装配(父零件编号 CHAR(10), 子零件编号 CHAR(10), 用量 INT, PRIMARY KEY (父零件编号, 子零件编号), FOREIGN KEY (父零件编号) REFERENCES 零件(编号), FOREIGN KEY (子零件编号) REFERENCES 零件(编号))
自反联系的特殊之处在于，外码与主码存在于同一个关系中，这要求数据库系统能够正确处理同一表内的自引用完整性约束。
七、规则六：组合联系与聚合的转化
E-R模型允许将联系本身视为一个高层实体，参与与其他实体之间的进一步联系。这种将联系聚合为实体的抽象机制，用于表达“某个关系本身具有属性或参与其他关系”的语义。例如，“选课”是学生与课程之间的M:N联系，它可以被聚合为一个高层实体“修读”，然后“修读”与“教师”之间建立“辅导”联系——表示某位教师负责辅导某个学生某门课程的学习。
聚合的转化规则：被聚合的联系已经转化为独立的关系模式（因为它通常是M:N联系），聚合实体直接使用该关系模式的主码参与新联系的转化。上述示例中，“选课”已经转化为独立的“选课(学号, 课程编号, 成绩)”关系，其主码为(学号, 课程编号)。聚合后的“辅导”联系转化为独立关系：
text
辅导(学号 CHAR(10), 课程编号 CHAR(8), 教师工号 CHAR(10), PRIMARY KEY (学号, 课程编号, 教师工号), FOREIGN KEY (学号, 课程编号) REFERENCES 选课(学号, 课程编号), FOREIGN KEY (教师工号) REFERENCES 教师(工号))
注意“辅导”关系的外码(学号, 课程编号)引用的是“选课”关系的主码——这正是聚合机制所表达的逻辑层级：“辅导”不是直接关联学生与教师，而是关联一个具体的“修读事件”与一位教师。
八、规则七：继承关系的转化——父类与子类的博弈
继承是概念模型中一种高级语义结构——一个高层实体（父类）的属性和联系被低层实体（子类）所继承，子类可以拥有自己特有的属性和联系。例如，“员工”是父类，“全职员工”和“兼职员工”是子类。全职员工有其特有的属性“年薪”，兼职员工有其特有的属性“时薪”，而“姓名”和“工号”是二者从“员工”继承的共享属性。
继承关系的转化有三种可选策略，各有优劣，设计者需根据实际情况权衡选择。
策略一：父类与子类各自独立为关系。父类转化为一个关系（包含共享属性），每个子类各自转化为一个关系（包含子类特有属性，加上父类主码作为外码，同时也是子类关系的主码）。查询子类完整信息时，需要将子类关系与父类关系按主码连接。此策略结构清晰，与面向对象设计对齐，但查询子类时需要连接操作。
策略二：仅子类各自独立为关系。每个子类各自转化为一个独立的关系，该关系包含父类的所有共享属性以及子类自身的特有属性。父类不单独存在。此策略避免了查询子类时的连接操作，但如果存在同时属于多个子类的实体（多重继承），则同一实体的共享属性可能多份存储，产生冗余。
策略三：仅父类独立为关系，子类属性并入父类。所有子类的特有属性都作为可空列加入父类关系中，并增加一个“类型”列以标识每行属于哪个子类。此策略将所有数据集中在一个表中，查询极为简便，但当子类间属性差异较大时会产生大量空值，且类型标识列承担了原本应由模式结构承担的语义。
三种策略反映了数据库设计中一个永恒的矛盾——规范化（消除冗余）与性能（减少连接）之间的张力。策略一最规范化，策略三最高性能，策略二是二者之间的折中。大型企业级应用中，策略一通常是默认选择，再根据实际性能需求通过物化视图或缓存机制来弥补连接开销。
九、结语：转化的终点是设计者的判断
本文系统梳理了E-R图向关系模式转化的七条核心规则，它们共同构成了一套完整的转化方法论。强实体、弱实体、二元联系、多元联系、自反联系、聚合与继承——这七种模式覆盖了绝大多数业务场景的语义结构。
然而，规则是骨架，判断才是血肉。转化规则告诉设计者“可以怎么做”，但不能取代设计者回答“应该怎么做”。1:1联系的外码放在哪一侧，继承关系选择哪种策略，多值属性是否独立成表——这些决策都涉及对数据量、查询模式、更新频率、未来扩展方向的综合预判。数据库设计的困难之处从来不是理论规则的匮乏，而是在多重约束下做出面向未来的权衡。
下一篇，我们将从转化的宏观视角收束到关系模式内部的微观结构——函数依赖的公理系统与闭包计算，为后续的范式理论奠定形式化基础。转化后的关系模式是否消除了冗余、能否规避更新异常，取决于模式内部的依赖结构。理解函数依赖，就是理解关系模式中数据的“引力场”——哪些属性决定了哪些属性，哪些属性之间的约束是逻辑上的必然。
