数据库系统教学课件：第4讲-关系模型

1、第4讲(第2章): 关 系 模 型重庆大学计算机学院课程名称: 数据库系统 -概念数据模型最终会转换成关系数据库设计。这意味着实体、属性、关系和唯一标识符将转换成关系数据库中的对象。请将这种情况与在纸上设计并用织物实现其设计的服装设计师比较。设计师需要了解如何缝制设计的服装，就我们需要了解关系数据库对象的结构一样。 关系数据库图示 关系数据库就是用户所看到的二维表集合形式的数据库，每个表都包含行和列。 下表包含雇员数据。 使用结构化查询语言 (SQL) 可以有效地访问关系数据库中的数据。不要手动搜索每一行来查找雇员编号为 200 的记录，而是使用下面的 SQL 语句： 用于访问数据的语言 为了

2、查找部门编号 90 中的所有雇员，我们编写了另一条 SQL 语句： 特定的 SQL 查询 主键 (PK) 是唯一地标识表中各行的一个列或一组列。每个表都应有一个主键，并且主键必须是唯一的。主键的任何部分都不能为空。 主键一个表可以包含多个列或若干列的组合，这些列可以作为该表的主键。每个列（或列组合）称为一个“候选”键，因为它可能被选用为主键。 选择一个要用作该表主键的候选键。其他候选键将变成替代键（或唯一键）。 主键候选项 外键 (FK) 是一个表中的一个列（或列组），其中包含与另一个表中的主键值匹配的值。外键如果主键由一个或多个外键组成，则 FK 值不能为 NULL。 外键规则一个列只能包含

3、与为该列定义的数据格式一致的值。 列完整性 数据完整性规则（也称为约束条件）为数据库定义了正确的关系状态。数据完整性规则可以确保用户只能执行将数据库保持为正确且一致状态的操作。 数据完整性规则总结 概念模型（实体关系图）最终会转换为物理模型。物理实现结果将是一个关系数据库。 从概念模型转换为物理模型 分析（概念模型）与实施（物理模型）这两个阶段使用不同的术语： 实体变成了表。 实例成为行。 属性成为列。 主要唯一标识符成为主键。 关系将转换为外键列和外键约束条件。 术语映射 关系是主键与外键之间的映射，使一个表可以引用另一个表。如果不映射关系，我们就会有大量独立的表，其中包含的信息与数据库的其

4、他部分没有关联。 关系映射在“多”边关系中，一个关系会在表中创建一个或多个外键列。 我们使用表的简称来命名外键列。在示例中，“雇员”表中的外键列为部门标识和雇员标识，以分别引用与部门的关系和与其自身的递归关系。 外键列可以是必需的，也可以是可选的，具体取决于业务需求。在本示例中，部门标识是必需的，而雇员标识是可选的。 关系映射规则关系映射规则示例关系无论在一端是必需的还是在两端是必需的，它们的映射方式与在一端为可选的关系完全相同。概念模型足以捕获关系两端的可选性。由于外键约束条件只能在多端强制实施必需关系，因而物理模型会受到局限。 在下面的示例中，物理模型无法强制乐队包含一个以上的乐师。必须另

5、外进行编程才能实现一端的可选性。 映射“一”端上的必需关系 强制执行可选性 概念模型中的不可转移关系意味着无法更新数据库表中的外键列。外键约束条件本身无法在数据库中强制执行该操作。 需要另外进行编程才能确保数据库符合该业务规则。将这些规则记录下来，以便小组成员编写正确的代码并强制执行该业务规则，这一点很重要。 映射不可转移的关系 强制执行不可转移的关系限定关系会在“多”端上映射为外键列，就像其他任何一对多 (1:M) 关系一样。在这种情况下，外键列具有双重角色，因为它还是主键的一部分。 在本示例中，“银行帐号”是“帐户”表中引用“银行”表主键的外键列。同时它还是帐户表主键的一部分。 映射限定关

6、系 映射限定关系示例层次会导致级联限定关系，在限定关系中，顶层的实体 UID 将一直向下传递到底层的实体 UID。在本示例中，房间 UID 由房间编号、套间编号、楼层编号和单元楼标识组成。这可以使用限定关系来表示。 如果将限定关系映射为物理模型，可能会导致外键列名很长，因为该列名将源表的简称用作前缀。建议的命名惯例是，不要使用两个以上的表前缀。在本示例中，将房间表中一直来自单元楼的外键列命名为“套间单元楼标识”，而不是“套间楼层单元楼标识”。 级联限定关系 级联限定关系（续）各个表中的样本数据说明了级联限定关系。 级联限定关系图示 多对多 (M:M) 关系是使用交集实体解析的，可将该关系映射到

7、交集表中。该交集表将包含引用源表的外键列。 在本示例中，评论包含评论家和电影之间的所有组合。 映射多对多关系 转换一对一 (1:1) 关系时，会创建一个外键和一个唯一键。该外键的所有列也是唯一键的组成部分。 如果关系在一端是必需的，则会在相应表中创建外键。在本示例中，瓶盖代码就是汽水瓶表中的外键列，它引用了瓶盖的主键。瓶盖代码在汽水瓶表中也要保持唯一。 映射一对一关系 如果关系在双端都是可选的，则可以选择由哪个表获取外键。关于此关系并没有绝对的规则，但有一些指导： 在行数较少的表中实现外键可节省空间。 实现对业务更有意义的外键。 可选一对一 在本示例中，租车代理更关注汽车，而不是车位，因此，将

8、外键放在“汽车”表中更有意义。但对于停车场业务而言，主要对象则是停车位。因此，将外键放在车位表中是明智的做法。 可选一对一 业务规则如果关系在两端都是必需的，则数据库中的限制与“一”端必需的一对多 (1:M) 关系相同。因此，需要另外编写代码来强制执行该限制。 强制执行一对多 具有弧的实体将映射为一个表，该表包含的外键来自位于关系的“一”端的表。 请注意，即使弧中的关系在多端上是必需的，生成的外键也必须是可选的（因为其中一个外键始终为空）。 映射弧映射弧由于弧代表排斥关系，因此需要另外编写代码来强制实现表中仅有一个外键在每行都有一个值。存储在数据库中的检查约束条件可以轻松地做到这一点。在本示例

9、中，检查约束条件的代码与以下代码类似： CHECK (公共场所标识 is not null AND 私人住宅标识 is null) OR (公共场所标识 is null AND 私人住宅标识 is not null) 如果关系完全是可选的，则可添加： OR (公共场所标识 is null AND 私人住宅标识 is null) 映射弧（续）代码将验证：如果公共场所标识 (pse_id) 具有值，则私人住宅标识 (phe_id) 列必须为空。反之，如果公共场所标识为空，则私人住宅标识必须具有值。在完全可选的关系中，通过另外编写代码可允许公共场所标识和私人住宅标识都为空（活动不在任何地点举办）。

10、映射弧（续）此选择会生成一个单表，以用来实现父类型实体及其子类型实体。这也称为“单表（或一表）实现” 规则： 1.表：仅创建一个表，不考虑子类型数量。 2.列：单表使用一列来包含父类型的每个属性，并具有属性的初始可选性。 3.该表还会对属于子类型的每个属性使用一列，但这些列都会成为可选列。 4.此外，应创建一个必需列作为辨别列，以区分实体的不同子类型。可获取的值来自所有子类型简称（在本示例中为 FTE、PTE 和 OTR）集合。此辨别列通常称为 _类型，如示例中的雇员类型 父类型实现：单表 父类型单表实现规则： 1.标识符：唯一标识符将转换成主键和唯一键。 2.关系：父类型级别的关系按常规方法

11、进行转换。子类型级别的关系将作为可选的外键列来实现。 3.完整性约束条件：需要使用检查约束条件，以确保对每个特定的子类型而言，来自必需属性的所有列都为非空。 父类型实现：单表（续） 在概念模型中，全职雇员的薪金是必需的，兼职雇员的小时工资率也是必需的。如果在物理模型中将“雇员”父类型实现为单表，则这些属性将变为可选。需要使用检查约束条件来强制执行实体关系图中建模的业务规则。 在本示例中，检查约束条件的代码与以下代码类似： CHECK (雇员类型 = FTE and 薪金 is not null and 小时 工资率 is null and 代理标识 is null) OR (雇员类型 = PT

12、E and 薪金 is null and 小时工资率 is not null and 代理标识 is not null) 父类型实现：单表（续） 代码将检查如果雇员是全职的（雇员类型 = FTE），则薪金列是否具有值，以及小时工资率和代理标识列是否为空。反之，如果雇员为兼职雇员（雇员类型 = PTE），则小时工资率和代理标识必须包含一个值，而薪金为空。 父类型实现：单表（续） 单表实现是一种常见而灵活的实现。您很可能会优先考虑这种实现，它尤其适用于以下情况： 大部分属性都处于父类型级别。 大多数关系都处于父类型级别。 从全局看，子类型的业务规则都相同。 何时选择单表/父类型实现？ 这也称为“双

13、表实现”。将为每个子类型创建一个表。因此，如果子类型的数量实际上多于两个，则会规则： 1.表：每个第一级子类型都有一个表。 2.列：每个表都使用一列来包含父类型的每个属性，并具有该属性的初始可选性。 3.每个表还具有一列，其中包含属于子类型的每个属性，并具有该属性的初始可选性。4.标识符：父类型级别的主 UID 为每个表都创建一个主键。父类型的辅助 UID 将成为每个表的唯一键。 5.关系：所有表都使用一个外键来引用父类型级别的关系，并具有初始可选性。对于子类型级别的关系，将在其映射到的表中实现外键。初始可选性保留不变。 子类型实现：双表 子类型实现：双表（续） 在本示例中，将分别为衬衫和鞋子

14、创建一个表。 子类型实现：双表（续）子类型实现适用于以下情况： 子类型的共有属性很少。父类型级别的属性较少，有几个子类型级别的属性。 大多数关系都处于子类型级别。 不同子类型的业务规则和功能各不相同。 表的使用方法不同。例如，一个表正在查询，而另一个表正在更新。 何时考虑子类型实现 可将父类型实体及其子类型建模为弧关系。这里又是一个包含父类型和子类型的 ERD。 将父类型建模为弧 在此 ERD 中，我们重新绘制了“服饰”父类型及其子类型“衬衫”和“鞋子”作为独立的实体，每个都与父类型有必需的一对一 (1:1) 关 系。这些关系以弧表示。 弧建模图示 该选择会为每个实体生成一个表。对于每个子类型

15、表，父类型表都有一个外键。这些外键代表排斥关系。由于只有一个外键对表中的每一行都具有一个值，所以这些外键都是可选的。 父类型和子类型（弧）实现规则 1.表：有多少个子类型，就创建多少个表，为父类型也创建一个表。 2.列：每个表都使用一列来包含其所基于的实体的所有属性，并具有初始可选性。 3.标识符：父类型级别的主 UID 为每个表都创建一个主键。其他所有唯一标识符都成为其对应表的唯一键。 4.关系：所有表都使用一个外键来引用实体级别的相关关系，并具有初始可选性。 5. 完整性约束条件：在基于父类型的表中另外创建两列。这两列将作为外键列，引用用于实现子类型的表。由于外键用弧表示，所以这些列是可选的。还额外需要一个检查约束条件来实现弧。由于外键列实现了一个一对一 (1:1) 必需关系，所以它们也是唯一键。 父类型和子类型（弧）实现父类型和子类型（弧）实现（续） 这种实现很少使用，但可能适用于以下情况： 子类型的共有属性很少，每个表都包含可独立使用的信息。例如，如果服饰表提供了全部全局信息，而鞋子和衬