Chapter 6.8 ISA

Thu, 23 Oct 2025 00:00:00 +0800

ISA关系（6.8）

ISA Relationship 指的是一种特定的数据建模技术，用于在概念模型（如ER图）中表示实体之间的继承关系。

ISA 是 “IS-A” 的缩写，例如 “A Manager IS-AN Employee”（一个经理是一个员工）。它描述了一种父类型（超类型） 和子类型 之间的层次关系。

核心概念

在数据库设计中，ISA关系用于捕捉现实世界中存在的分类结构。

超类型 / 父类： 一个更一般化、更抽象的实体。
- 例如：人(Person)、账户(Account)、车辆(Vehicle)
子类型 / 子类： 一个更具体、更特化的实体，它是超类型的一种。
- 例如：员工(Employee) 和 学生(Student) 是 人(Person) 的子类型。
- 储蓄账户(SavingsAccount) 和 支票账户(CheckingAccount) 是 账户(Account) 的子类型。

ISA关系的两个关键约束

当你在设计中使用ISA关系时，必须定义两个重要的约束：

1. 重叠约束（Disjoint/Overlapping Constraint）

规定一个超类型的实例是否可以同时属于多个子类型。

不允许重叠： 一个超类实例只能属于一个子类型。
- 例如：一个 账户(Account) 要么是 储蓄账户(SavingsAccount)，要么是 支票账户(CheckingAccount)，但不能同时是两者。用 “OR” 表示。
允许重叠： 一个超类实例可以同时属于多个子类型。
- 例如：一个 人(Person) 可以同时是 员工(Employee) 和 学生(Student)。用 “AND” 表示。

2. 完备性约束（Completeness constraint）

规定超类型中的每一个实例是否都必须至少属于一个子类型。

全完备性（total）： 超类型的每一个实例都必须是某个子类型的实例。
- 例如：公司规定，每一个 员工(Employee) 都必须是 小时工(HourlyEmployee) 或 月薪工(SalariedEmployee) 中的一种。超类型 员工(Employee) 不会存在不属于任何子类的“孤例”。在ER图中，用双线表示。
部分完备性（partial）： 超类型的实例可以不属于任何子类型。
- 例如：一个 人(Person) 可以只是普通人，既不是 员工(Employee)，也不是 学生(Student)。在ER图中，用单线表示。

在数据库中的实现方式

ISA层次结构在物理数据库中主要有三种实现方式：

1. 每个具体类一张表

方法： 忽略超类型，只为每个子类型创建一张表。这张表包含该子类型特有的属性，以及从超类型继承来的所有属性。
举例： 创建 学生表(Students) 和 员工表(Employees)，没有 人表(Persons)。Students表中有 student_id, name, age, major 等字段。
优点： 查询特定子类型的数据时速度快。
缺点：
- 数据冗余（如果一个人既是学生又是员工，他的name和age信息会在两张表中重复存储）。
- 难以对所有人进行统一查询（需要UNION操作）。
- 无法表示不属于任何子类的人。

2. 单张表

方法： 将整个层次结构“扁平化”为一张表。这张表包含超类型和所有子类型的所有属性。同时，增加一个“类型鉴别”字段来标识每一行属于哪个子类型。
举例： 创建一张 人表(Persons)，包含字段：person_id, name, age, person_type, major, salary, department。
- 如果 person_type = ‘Student’，那么 major 字段有意义，salary 字段为NULL。
- 如果 person_type = ‘Employee’，那么 salary 字段有意义，major 字段为NULL。
优点： 统一查询非常简单，不需要JOIN操作。
缺点：
- 表中存在大量NULL值，浪费存储空间。
- 表结构会随着子类型的增加而变得非常庞大和复杂。

3. 超类型和子类型分别建表

方法： 为超类型和每一个子类型都创建一张表。
- 超类型表包含所有实例共享的公共属性（和一个主键）。
- 子类型表只包含其特有的属性，并共享超类型表的主键（即子类型表的主键同时也是引用超类型表的外键）。
举例：
- 人表(Persons)：person_id (PK), name, age
- 学生表(Students)：person_id (PK, FK references Persons), major
- 员工表(Employees)：person_id (PK, FK references Persons), salary, department
优点：
- 设计规范，消除了数据冗余。
- 易于添加新的子类型。
- 能很好地支持重叠约束（一个人可以同时在Students和Employees表中有记录）。
缺点： 查询数据时需要频繁使用JOIN操作，性能可能成为瓶颈。

总结

在数据库领域中，ISA Relationship 是一个强大的概念建模工具，它清晰地表达了 “是一个” 的继承关系。理解并正确定义其重叠约束和完备性约束至关重要，因为它直接影响到最终数据库表结构的设计选择（每种实现方式都有其优缺点，需要根据具体应用场景进行权衡）。

Chapter6 ER模型

Thu, 23 Oct 2025 00:00:00 +0800

Chapter 6 The Entity-Relationship Model

Entity Sets（实体集，实体型）

一张学生表是一个实体集，一个学生是一个实体（一行记录）

Relationship Sets(关系集)

选课表就是一个关系集。它定义了“学生”和“课程”之间的“选修”这种关系。关系表示特定实体之间的一次具体关联。它对应的是联系表中的一行记录。关系集也可以拥有自己的属性（关系集属性），用于描述关系的特征。它同样对应联系表中的列。选课表这个关系集可以有成绩、选修日期等属性，这些属性不属于学生，也不属于课程，而是属于“选修”这个行为本身。

Choice of Primary key for Binary Relationship

在多的那一端把一的主键拿过来当外键

多元联系(non-binary)

先转成多个二元联系再转表：将其他实体集的主键和关系自身属性建成表，各实体集不存放多余属性。

E-R图（概念设计结果）

Representing Cardinality Constraints in ER Diagram

→：一 —：多 (one,many) x (one,many) = 4 种

参与约束(Participant Constraints)

完全参与、部分参与

逻辑设计阶段

E-R图转关系模式实体、联系、属性（单值属性、多值属性、复合属性）如何转表？多值属性单独转表复合属性拆开（如时间、地址）

弱实体集、强实体集；用实体还是属性？ Not to use the primary-key of an entity set as an attributes of another entity set (to represent implicitly association between these two entity sets), it is better to use an relationship set to explicitly show this association e.g. for the entity student, do not use instructor.id as its attribute, in stead of, representing association among student and instructor using relationship advisor.

用实体还是关系？“动作”对应“联系”

弱实体集理解

扩展ER （详情看ISA那篇）

面向对象ER：Object-oriented (OO) E-R

specialization （特化，特殊化，例化）自上而下，底层实体集是高层实体集的真子集高层：超类；底层：子类

generalization (概括化，泛化，普遍化) 自底向上

attributes inheritance （属性继承）联系也可以继承

Aggregation

relationship on relationship（联系的联系）

ER模型 on zcys univ II Hugo ver