扫码获取 VIP 码
添加管理员微信获取 VIP 码
软考数据库系统工程师的下午案例题和上午选择题中，E-R模型向关系模式的转换是每年必考的核心考点。每年都有大量考生在看似简单的转换规则上丢分——不是因为不会画E-R图，而是忽略了转换中的边界条件和特殊实体处理。本文从E-R模型与关系模型的基本定义出发，逐条拆解实体、属性、联系的转换规则，覆盖一元联系、弱实体、多值属性、特化概化等高频考点，结合历年真题命题套路，帮你建立一套不漏项的转换思维框架。
E-R模型即实体联系模型，由陈品山于一九七六年提出，是数据库概念结构设计阶段最核心的建模工具。它用实体表示可区分的对象，用属性描述实体的特征，用联系刻画实体间的关联。E-R图是E-R模型的产物，矩形框代表实体，椭圆框代表属性，菱形框代表联系，连线上标注参与约束即实体参与联系的最小和最大次数。
关系模型是数据库逻辑结构设计阶段的数据组织方式，用二维表组织数据，每一行是一个元组，每一列是一个属性。关系模型建立在集合论和一阶谓词逻辑之上，每个关系本质上是笛卡尔积的子集。关系中实体间的联系不再通过指针实现，而是通过外键机制——在一个关系中加入另一个关系的主键作为属性列，建立跨表引用。
E-R模型向关系模式转换的本质，是从概念设计到逻辑设计的过渡。E-R图描述用户视角下的数据世界，偏重"有什么、谁和谁有什么关系"；关系模式描述数据库内部的数据组织方式，偏重"表怎么建、列怎么定、键怎么设"。转换有一整套形式化规则，掌握它们是软考数据库科目的基础能力。
转换的总体原则可概括为：每个实体转成一个关系，每个多对多联系转成一个关系，每个一对多联系通过外键实现。但真实考题不会只考这三句话的表面含义，命题人会在弱实体、多元联系、特化概化、多值属性等特殊场景中设陷阱。
实体转换为关系模式是最基础的一步，涉及主键选择、属性映射、复合属性和多值属性的处理，每个环节都有命题人挖坑的余地。
常规实体的转换遵循一条铁律：一个实体对应一个关系模式，实体名即为关系名，实体的简单属性直接映射为关系的列，实体的码即为主键。举例来说，学生实体含学号、姓名、性别、出生日期四个属性，学号为码，则转换为关系模式：学生，学号为主键。看似简单，但需要区分三种特殊属性形态。
复合属性由多个子属性组合而成，典型例子是地址由省市、街道、门牌号组合而成。转换时复合属性本身不作为一列出现，而是将其子属性分别展开为独立列。学生实体的地址是复合属性，转换后学生关系中直接出现省、市、街道、门牌号四个列，地址这个名称不出现在关系模式中。
多值属性是指一个实体在该属性上可取多个值，最典型的例子是电话号码：一个人可以有多个手机号，也可以同时有座机和手机。多值属性不能直接作为关系的一列，因为关系模型要求每列的值原子化、不可再分。处理多值属性的标准做法是为该属性单独创建关系模式，包含实体主键和多值属性本身，两者组合作为主键。比如学生实体的电话是多值属性，则新建关系模式：学生电话，主键为。
派生属性是指值可通过其他属性计算得出，如年龄可通过出生日期和当前日期计算。转换时派生属性一般不存储，但若查询频率极高也可物理存储。软考很少单独考查派生属性，但会出现在规范化分析中——关系中同时存在出生日期和年龄时，年龄即为冗余属性，可能诱发更新异常。
还有一种特殊情况是实体只有码属性而没有其他属性，例如纯粹的关联实体。这种情况下仍要创建独立的关系模式，哪怕只含主键列，因为它在后续联系转换中可能需要承担外键角色。省略这种"单列关系"会破坏关系模式的完整性。
联系转换为关系模式是整个转换过程中变量最多、命题人最常设置陷阱的部分。联系的类型由参与实体的数量和映射基数共同决定，转换策略因联系类型不同而有显著差异。
一对一二元联系表示两个实体集之间每个实体最多与对方的一个实体相关联。在E-R图中，菱形框两端都标注了一或者零和一。一对一的转换有四种策略，选择哪种取决于两端的参与约束是全参与还是部分参与。
第一种策略是将联系合并到任一端的实体关系中。在A关系中添加B的主键作为外键，或反之，外键列需加唯一约束确保一对一不被破坏。两个实体都全参与时此策略最优，不会产生空值。
第二种策略是将两个实体和联系三者合并为一个关系模式。两个实体都全参与且需要频繁联合查询时比较高效，但会破坏实体独立性。软考有时要求判断合并后的范式等级，合并可能带来部分函数依赖。
第三种策略是保持两个实体独立，创建第三个关系描述联系。新建关系包含两个实体的主键，任选其一作为主键，另一个作为外键并加唯一约束。优点是保持独立性，缺点是增加连接开销。题目未明确参与约束时，此策略最稳妥，适用于所有一一对场景。
第四种策略适用于部分参与情况。比如校长和学校，每所学校必须有校长，但并非每个教授都是校长。应在校长关系中加入学校主键作为外键，而非在学校里给校长留空列。判断标准：谁的部分参与度更高，谁就成为外键持有方以减少空值。
一对多二元联系是软考最常见的联系类型，转换策略最为简洁：在多端实体关系中添加一端实体主键作为外键。比如系和学生，转换后在学生关系中增加系编号列作为外键，引用系关系的主键。
这里有一个命题人常用的陷阱：联系本身的属性如何处理。如果一对多联系本身带有属性，这些属性必须与多端实体合并存储。举例来说，如果学生和课程之间存在选修联系，且联系本身带有成绩属性，虽然学生和课程之间本质上是一对多的修课关系，但这里实际是多对多的——一个学生选多门课，一门课被多个学生选。因此不能简单地把成绩放在学生表或课程表中，而必须新建一个选课关系来承载成绩属性。命题人会故意设置一个表面上一对多、实际数据要求多对多的场景来考查考生的判断力。
多对多二元联系必须为联系本身创建独立的关系模式。新建关系包含两端实体主键作为外键，同时加入联系自身属性。新建关系的主键由两端实体主键组合而成，即联合主键。
以学生和课程的多对多选修联系为例，选修联系自带成绩属性。转换后创建选课关系模式，主键为联合主键。易错点：成绩既不能放在学生关系也不能放在课程关系中，放在任何一方都会导致冗余和数据异常。
判断二元联系是否需独立成表的核心标准不是看菱形框两端数字，而是看业务语义是否允许两端各自独立参与多次联系。允许则为多对多，必须独立成表；否则需进一步判断为一对还是一对多。
一元联系又称递归联系，指同一实体集内部实体间的关系。常见于职工上下级管理、课程前驱后继依赖、零件装配组成等场景。一元联系虽然只涉及一个实体集，但映射基数同样分为一一对、一对一和多对多三种，转换策略与二二元联系类似，只是外键引用目标均为同一个关系。
一元一对一联系的典型场景是职工婚姻关系。转换时在职工关系中添加配偶职工编号列作为外键，引用自身主键，同时加唯一约束确保一对一。
一元一对多联系的经典案例是职工上下级关系。每个职工最多有一个直接上级，一个上级可管理多个下级。转换后在职工关系中添加上级职工编号列作为外键，引用自身主键，最高层管理者此列允许为空。
一元多对多的典型场景是课程先修关系。一门课可能需要多个先修课，一门课也可能是多门其他课的先修课。转换时必须创建独立的关系模式，新建关系包含两个课程编号属性，分别代表先修课和被先修课，两者组合作为联合主键。
多元联系是指三个或更多实体集之间的一次性关联。转换时一律为多元联系创建独立的关系模式，包含所有参与实体的主键作为外键及联系自身属性。主键通常由所有参与实体主键联合组成，但具体取决于函数依赖分析。例如供应商、零
本篇完！