【数据库系统原理】第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联系的外码放在哪一侧继承关系选择哪种策略多值属性是否独立成表——这些决策都涉及对数据量、查询模式、更新频率、未来扩展方向的综合预判。数据库设计的困难之处从来不是理论规则的匮乏而是在多重约束下做出面向未来的权衡。下一篇我们将从转化的宏观视角收束到关系模式内部的微观结构——函数依赖的公理系统与闭包计算为后续的范式理论奠定形式化基础。转化后的关系模式是否消除了冗余、能否规避更新异常取决于模式内部的依赖结构。理解函数依赖就是理解关系模式中数据的“引力场”——哪些属性决定了哪些属性哪些属性之间的约束是逻辑上的必然。