数据模型
信息
数据模型是一种对现实世界数据特征的抽象, 是数据库系统的核心和基础. 由于计算机不可能直接处理现实世界中的数据, 也就是首先要数字化, 把显示世界中具体的人, 物, 活动, 概念用数据模型这个工具来抽象, 表示和处理. 通俗的讲, 数据模型就是现实世界的模拟.
两类数据模型
数据模型应该满足三方面要求: 一是比较真实地模拟显示世界, 二是容易为人所理解, 三是便于在计算机上实现. 一种数据模型要很好的, 全面地满足这三方面的要求在目前尚很困难. 因此, 在数据库系统中针对不同的使用对象和应用目的, 采用不同的数据模型.
如同在建筑设计和施工不同阶段需要不同的图纸一样, 在开发实施数据库应用系统中需要使用不同的数据模型: 概念模型, 逻辑模型和物理模型. 根据模型应用的不同目的, 又将这些模型划为两大类, 第一类包含概念模型, 第二类包含逻辑模型和物理模型.
- 第一类
- 概念模型: 是按照用户的观点来对数据和信息建模, 主要用于数据库设计
- 第二类
- 逻辑模型: 是按照计算机系统的观点对数据建模, 主要用于数据库管理系统的实现
- 物理模型: 是对数据最底层的抽象, 描述的是系统内部的表示方式和存取方法, 是面向计算机系统的
为了把显示世界中的具体事务抽象, 组织为某一数据库管理系统支持的数据模型, 人们常常首先将现实世界抽象为信息世界, 然后将信息世界转换为机器世界. 也就是说, 首先把现实世界中的客观对象抽象为一种信息结构, 这种信息结构并不依赖于具体的数据库管理系统, 而是概念级的模型, 然后再把概念机模型转换为计算机上某一数据库管理系统支持的数据模型.
从现实世界到概念模型的转换是由数据库设计人员完成的; 从概念模型到逻辑模型的转换可以由数据库设计人员完成, 也可以用数据库设计工具协助设计人员完成. 从逻辑模型到物理模型的转换主要由数据库管理系统完成.
图片表示, 点击这里.
概念模型
概念模型是现实世界到机器世界的中间层次. 概念模型用于信息世界的建模, 是现实世界到信息世界的第一层抽象, 是数据库设计人员和用户之间交流的语言, 因此概念模型应该有较强的语义表达能力, 方便用户理解.
信息世界的基本概念
实体, 实体型和实体集2
- 实体(Entity)表示一个离散对象. 不同的实体是不同的, 只能代表他自己一种. 如鲫鱼, 鲤鱼, 金龙鱼, 茉莉蜜茶, 冰红茶, 青梅绿茶. 这些都可以称之为实体. 注意上述的例子中都是一个非常具体的东西
- 实体型(Entity Type)是实体名及其属性名集合来抽象和刻画的同类实体. 如鲫鱼, 鲤鱼, 金龙鱼前面三种鱼我们将其统称为鱼. 🐟具有什么属性呢? 🐟有品种, 长度, 重量等属性, 那么🐟这个统称和这些属性名的组合, 将这个组合称为实体型, 即🐟(品种, 长度, 重量). 再比方说学生(学号, 姓名, 性别, 班级)也是实体型, 汽车(品牌, 价格, 产地)也是实体型, 在ERD中, 通常用矩形表示统称, 用椭圆表示属性
- 实体集(Entity Set)是同一类型实体的集合, 一般是有限的. 如{茉莉蜜茶, 冰红茶, 青梅绿茶}这就是一个实体集, {鲫鱼, 鲤鱼, 金龙鱼}这也是一个实体集
强/弱实体型
强实体型是有独立主键的实体型, 弱实体型是没有独立主键的实体型. 这里主要介绍弱实体型.
弱实体的存在取决于一个识别拥有者实体(Identifying Owner Entity)的存在. 换句话说, 如果没有与之相关的强实体存在, 弱实体本身就无法存在. 弱实体集必须通过一个一对多/多对一的识别关系和强实体集相联系. 在这种关系中, 强实体集通过主键来识别和关联弱实体集. 弱实体集必须全部参与到关系中(即完全参与约束), 弱实体集中的每一个实体必须参与这个关系. 弱实体集在ERD中表现为一个嵌套的方形(方形外面套一个方形). 强弱实体的关系集在ERD中表现为一个嵌套的菱形(菱形外面套一个菱形).
区分符(discriminator): 如, 贷款和还款. "贷款"是一个强实体集, "还款"是一个弱实体集. 每一个贷款可以有多个还款, 这是一个一对多的关系. 所有的还款必须参与到关系中. Load_ID是贷款的主键, Repayment_ID是还款的编号, 是区分符, 用于区分同一笔贷款中的不同还款. 还款表的主键应该是(Loan_ID, Repayment_Number). 如图.
属性3
- 属性(Attribute): 实体所具有的某一方面的特性, 属性可以只有一个值, 也可以有多个值. 一个值的属性用一个椭圆表示, 多个值的属性用两个椭圆表示(椭圆外面再套一个椭圆); 属性也可以是简单的, 或者是复合的, 简单属性只有一层椭圆, 复合属性由多层椭圆表示, 如图
- 域(Domain): 一个属性可能取的所有属性值的范围称为该属性的域
- 码(Key): 唯一标识实体的属性集, 在ERD中, 有下划线的属性为码
超键/候选键/主键/外键
- 超键: 可以唯一标识一个实体的属性集称为超键. 如属性集Sno, Sname, Sage, Ssex. 在这个结构中, 只有包含Sno的属性集合才能是超键, 因为如果不包含Sno, 可能会出现同名, 同姓的人, 也可能出现同岁的人, 所以在上面的关系模式中只有通过学号才能找到某个特定的学生. 如(Sno), (Sno, Sname), (Sno, Sname, Sage)都可以称为超键
- 候选键: 能唯一标识实体并且不含多余属性的属性级称为候选键. 在上面提到的例子中, 如果没有重名的学生, Sname也可以当作是候选键, 这里可以看出候选键是一种特殊的超键, 即把超键中多余的属性删除就可以叫作候选键. 所以在上述关系中, (Sno), (Sname)可以叫作候选键
- 主键: 在若干候选键中, 随意指定一个作为关键字, 此关键字即为主键. 很好理解, 就是在候选键的基础上任意选择一个作为主键. 同时衍生出复合主键和联合主键. 假设我们没有学号字段, 如果可以通过姓名, 年龄, 性别一同找到某个特定的学生, 那么就称(name, age, sex)为复合主键, 由多个主键联合形成的键为联合主键
- 外键: 若将一张表的数据和另一张表的数据通过某一个属性关联起来, 这种属性称为外键. 如上述例子中, student表中的主键列Sno可以作为score表中Sno的外键列. 虽然Sno在student表中是主键, 但是在score表中它只是一个普通属性
关系与关系集4
- 关系(Relationship): 实体(型)内部的关系和实体(型)之间的关系. 实体内部的关系通常是指组成实体的各个属性之间的关系, 实体之间的关系通常是指不同实体集之间的关系
- 关系集(Relationship Set): 同类关系的集合
- 关系型(Relationship TYpe): 是关系名及其属性名集合来抽象和刻画的同类关系
Tip
关系和实体在表现形式上是类似的, 都有"集"/"型", 都有属性. 但是在本质上, 它们是不同的.
属性
就如同实体, 关系也是可以有属性的. 如John在2024学年的第二个学期参加了COMP9120课程. 所以实体John和COMP9120课程产生关系. 这个关系有一个属性是"学期".
角色
每一个参与关系的实体可以被分配一个角色. 如下述一元关系中员工集体内部的"管理"关系. 一个员工实体被分配为"下属"角色, 另一个员工实体被分配为"经理"角色.
度数
度数(Degree)描述的是连接中涉及的不同实体型的数量.
- 一元关系(Unary Relationship): 关系仅涉及一个实体型, 又称为"递归关系", 意味着实体集中的一个实例与同一个实体集中的另一个实例存在关系. 如一个人和另一人形成"已婚"的关系, 这里实体型就是"人". 又如"员工"实体集内部可能存在一个"管理"关系, 一个员工管理另一个员工
- 二元关系(Binary Relationship): 关系涉及两个实体型, 如学生和课程之间的注册关系, 这里的实体型是"学生"和"课程"
- 多元关系: 关系涉及三个或者更多的实体型, 如供应商, 产品和仓库之间的运输关系, 这里的实体型是"供应商", "产品"和"仓库"
基数
基数(Cardinality)描述的是两个实体型之间的产生关系的实例数量的关系.
- 一对一: 实体集A中的一个实体对应B中的一个实体, 记为1:1, 如一个学生只有一个成绩
- 一对多: 实体集A中的一个实体对应B中的多个实体, 记为1:N, 如一个学院有多名学生
- 多对多: 多实体对多实体, 记为M:N, 如一位老师上多门课, 一门课有多个老师
超键/候选键
- 实体集有超键, 关系集也有超键. 在关系集中, 超键是由参与关系的各实体的主键组成的. 如在Enrols关系中, Student实体集的主键是student_id, Course实体集的主键是course_id, 所以它们的组合(student_id, course_id)就是Enrols关系的超键.
- 实体集有候选键, 关系集也有候选键. 在关系集中, 确定候选键要考虑到基数. 以Works_In关系集为例, 它用来表示员工和部门之间的关系, 这里的场景是一个员工可以在多个部门工作, 并且一个部门也可以有多个员工, 因此是多对多的关系, 该关系集的候选键是(employee_id, department_id), 只有这样才能标识哪个员工在哪一个部门工作. 再以Manager-Department关系集为例, 每个部门最多只有一个经理, 这表示一个部门和经理的关系是一对一或多对一的关系, 这种情况下, department_id就是候选键. 因为每个部门只会对应一个经理
Tip
我们不会在ERD中表现出关系集的键, 但是会表现出实体集的键.
键约束
键约束指的是在一个实体集中, 每一个实体只能参与最多一次关系, 那么就称该关系对该实体集有键约束. 同时, 这个实体集的主键就是关系集的候选键. 键约束只会出现在一对一关系和一对多/多对一关系中. 在一对一关系中, 两个实体集都有键约束; 在多对一关系中, "多"那一侧的实体集有键约束.
如, 一个职工最多只能在一个部门工作, 但是一个部门可以有多个员工. 此时是一对多/多对一的关系. "多"的那一侧是职工实体集, 对于职工实体集有键约束, 且职工实体集的主键emp_id就是该关系集的候选键.
键约束在ERD中的表现形式是一根箭头, 如图.
参与约束
参与约束是指在一个实体集中, 所有的实体或者部分的实体必须参与到关系中, 据此, 可以分为完全参与和部分参与.
如, 所有员工必须至少属于一个部门.
完全参与约束在ERD中的表现形式是一条粗线, 如图.
键约束结合参与约束
如果所有的实体正好都参与一次关系, 那么该实体所处的实体集同时受到键约束和参与约束, 如图.
基数约束
基数约束是指对参与某个关系的实体集中的实体在在某个关系中至少参与多少次和最多参与多少次. 在ERD中, 用min...max的形式表示.
如, 所有的员工必须在1-3个部门工作, 如图.
实体-关系方法
概念模型是对信息世界的建模, 所以概念模型应该能够方便, 准确地表示出上述信息世界中的常用概念. 概念模型表示的方法有很多, 其中最为常用的是P.P.S.Chen于1976年提出的实体-关系方法(Entity-Relasionship Approach). 该方法用E-R图来描述现实世界的概念模型, E-R方法也被称为E-R模型.
ERD图怎么画, 在上面的各个小节中描述地很清楚了.
增强ER模型
原版的ER模型不支持泛化(Generalization)/反泛化(Specialization)和抽象. 增强ER模型解决了这一痛点, 它囊括了基础ER的所有思想, 还包括了一些面向对象的新东西, 如子类, 超类, 泛化/反泛化, 聚合. 增强ER模型又叫作扩展ER模型, 记为E2R或者EER.
泛化/反泛化
如Person实体集表示了一般的人员概念, 它包含了id, name, phone, address这些属性. 这是泛化的结果, 将两个更加具体的实体集Employee和Customer的共同属性抽象为一个更一般的Person实体集. Person实体集还可以反泛化为为两个更加具体的子实体集, 即Employee和Customer. 见图. 我们用isA关系集来表示层次结构中的继承关系, isA关系在ERD中用三角形表示.
若两个实体型EF的关系是isA关系(F是一个E), 则:
- F的属性是E的属性的超集
- F的实体集是E的实体集的子集
- F是E的反泛化的结果
- E是F的泛化的结果
- F作为子类会继承E的所有属性
重叠/覆盖约束
- 重叠约束(Overlap Constraints): 指定了一个实体是否可以属于多个低层次的实体集. 重叠约束还有两种类型:
- 不相交(Disjoint): 一个实体只能属于一个低层次的实体集, 在ERD中, 通过在isA三角形旁边写上disjoint来表示这种约束. 如, Employee和Customer它们是不相交的, 那么一个实体只能属于Empolyee和Customer之一, 不能同时属于两者
- 重叠(Overlapping): 一个实体可以同时属于多个低层次的实体集, 这是默认情况(可能在一些参考书中不是默认情况). 如, 一个实体也可以同时是Employee和Customer
- 覆盖约束(Covering Constraints): 指定了一个实体是否必须属于至少一个低层次的实体集. 覆盖约束还有两种类型:
- 完全覆盖: 一个实体必须属于至少一个低层次的实体集. 在ERD中, 通过在ISA三角形和父类之间画一条粗线来表示. 如, 一个实体必须是Employee或Customer中的一个
- 部分覆盖: 一个实体不必属于任何一个低层次的实体集, 这是默认情况. 如, 有些实体可能既不是Employee也不是Customer
聚合
聚合(Aggregation)表示我们将一组实体和关系视为一个更高级别的实体.
如图.
图中, 整个Sponsor关系(包括Project和Department)被聚合为一个新的实体, 这个新的实体作为Monitors关系的一部分与Employee进行交互. 在这里, Monitors关系连接了Employee和聚合后的Sponsors实体, 表示某个员工复杂监控某个部门对项目的赞助, 直到某个时间为止.
数据模型的组成要素
一般来讲, 数据模型是严格定义的一组概念的集合. 这些概念精确地描述了系统的静态特性, 动态特性和完整性约束条件(integrity constraints). 因此数据模型通常由数据结构, 数据操作和数据的完整性约束条件三部分组成.
数据结构
数据结构描述数据库的组成对象以及对象之间的关系. 简单来说, 数据结构包括内容和属性, 以及对象之间的关系. 数据结构是刻画一个数据模型性质最重要的方面. 因此在数据库系统各种, 人们通常按照其数据结构的类型来命名数据模型. 例如层次结构, 网状结构和关系结构的数据模型分别命名为层次模型, 网状模型和关系模型. 数据结构是对系统静态特征的描述.
数据操作
数据操作是指对数据库中的各种对象(型)的实例值允许执行的操作的集合, 包括操作及有关的操作规则. 数据库主要有查询和更新(包括插入, 删除, 修改)两大类操作. 数据类型必须定义这些操作的确切含义, 操作符号, 操作规则(如优先级)以及实现操作的语言. 数据操作是对系统动态特性的描述.
数据的完整性约束条件
数据的完整性约束条件(integrity constraints)是一组完整性规则. 完整性规则是给定的数据模型中数据极其关系所具有的制约和依存规则, 用以限定符合数据模型的数据库状态和状态的变化, 以保证数据的正确, 有效和相容.