【数据库系统原理】第13篇:现实世界的概念抽象:实体-联系模型向关系模型的转化策略

目录

一、转化的总则:从认知模型到逻辑结构

二、规则一:强实体的转化

三、规则二:弱实体的转化

四、规则三:二元联系的转化------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联系的外码放在哪一侧,继承关系选择哪种策略,多值属性是否独立成表------这些决策都涉及对数据量、查询模式、更新频率、未来扩展方向的综合预判。数据库设计的困难之处从来不是理论规则的匮乏,而是在多重约束下做出面向未来的权衡。

下一篇,我们将从转化的宏观视角收束到关系模式内部的微观结构------函数依赖的公理系统与闭包计算,为后续的范式理论奠定形式化基础。转化后的关系模式是否消除了冗余、能否规避更新异常,取决于模式内部的依赖结构。理解函数依赖,就是理解关系模式中数据的"引力场"------哪些属性决定了哪些属性,哪些属性之间的约束是逻辑上的必然。

相关推荐
JAVA面经实录9172 小时前
NoSQL 非关系型数据库【简洁版】
java·数据库·nosql
IvorySQL2 小时前
PostgreSQL 19 新特性:基于 SQL/PGQ 实现图数据查询
数据库·sql·postgresql
jghhh012 小时前
C# 图片水印工具(支持9个位置)
数据库·microsoft·c#
辰海Coding2 小时前
MiniSpring框架学习笔记-JDBC 访问框架:如何抽取 JDBC 模板并隔离数据库?
java·数据库·笔记·学习·spring
救救孩子把2 小时前
01 Milvus-向量数据库基础
数据库·milvus
闪电悠米2 小时前
黑马点评-Redis 消息队列-01_why_redis_mq
java·数据库·spring boot·redis·缓存·junit·消息队列
oradh2 小时前
Oracle数据库扩展区(extent)概述
数据库·oracle·oracle基础·oracle数据库扩展区概述
IT策士2 小时前
Redis 从入门到精通:初识 Redis
数据库·redis·缓存
不剪发的Tony老师2 小时前
DBHub:一款免费开源的数据库MCP服务器
数据库·mcp