数据库原理 for NCRE 4
记录自 全国高等教育制定教材 数据库原理 和 部分自己的整理
1. 数据库系统的基本概念
1.2 数据描述
1.2.1 概念设计中的数据描述
实体(Entity): : 客观存在,可以相互区别的事物成为实体
实体集(Entity Set) : 性质相同的同类实体的集合
属性(Attribute) : 实体的特性称为属性
实体标识符(Indentify) : 能唯一标识实体的属性或属性集
1.2.2 逻辑设计中的数据描述
记录(Record) : 字段的有序集合
字段(Field) : 标记实体属性的命名单位称为字段或数据项
文件(File) : 同一类记录的集合
关键码(Key) : 能唯一便是文件中某个记录的字段或字段集
术语的对应关系
概念设计 | 逻辑设计 |
---|---|
实体 | 记录 |
属性 | 字段 |
实体集 | 文件 |
实体标识符 | 关键码 |
1.2.4 数据联系的描述
联系 (Relationship) : 实体之间的相互关系,与一个联系相关的实体个数称为联系的元数
联系的类型 : 一对一,一对多,多对多 1:1, 1:N, N:M
1.3 数据的抽象级别
1.3.1 数据抽象过程
模型(Model) : 对现实世界的抽象
数据模型(Date Model) : 数据库的结构和语义,对现实世界的数据进行抽象
: > wiki-数据模型 数据模型是定义数据如何输入和与输出的一种模型。 其主要作用是为信息系统提供数据的定义和格式。数据模型是数据库系统的核心和基础, 现有的数据库系统都是基于某种数据模型而建立起来的。
1.3.2 概念模型
- 表达数据的整体逻辑结构,是系统用户对整个应用项目设计的数据的全面描述
- 从用户的观点出发,对数据建模
- 独立于硬件和软件
- 是数据库设计人员与用户之间进行交流的工具
1.3.3 逻辑模型
- 表达了DB的整体逻辑结构,设计人员对整个应用项目数据库的全面描述
- 从数据库的实现观点出发,对数据建模
- 独立于硬件,依赖于软件
- 数据库设计人员与应用程序员之间进行交流的工具
逻辑模型的类型: 层次,网状,关系
1.3.4 外部模型
- 是逻辑模型的子集
- 独立于硬件,依赖于软件
- 反应用户使用数据库的观点
外部模型的优点
- 简化用户的观点
- 有助于数据的安全性保护
- 外部模型是对概念模型的支持
1.3.5 内部模型
内部模型也叫做物理模型,是数据库最底层的抽象,它描述数据在磁盘或磁带上的存储方式,存取设备和存取方法
现今的内部细节大多由操作系统实现
1.3.6 三层模型和两级映象
- 三层模型即上述的: 外部,逻辑,内部
- 两层映象为: 内部 <-> 逻辑, 逻辑 <-> 内部
- 优点: 增强了独立性,不同模式层次之间的操作由映射完成
1.4 数据库管理系统(DBMS)
1.4.1 DBMS的工作模式
数据库操作系统(DBMS) : 是指数据库系统中对数据进行管理的软件系统。它是数据库系统的核心组成部分.对DB的一切操作, 包括定义,查询,更新及各种控制,都是通过DBMS进行的.
DBMS的工作模式
- 接受应用程序的数据请求和处理请求
- 将用户的数据请求(高级指令)转换(编译)成复杂的机器码(低级指令)
- 实现对数据库的操作
- 从对数据库的操作中接受查询结果
- 对查询结果进行处理(格式转换)
- 将处理结果返回给用户
DBMS的主要功能
- 定义(DDL)
- 操纵(DML)
- 数据库的保护功能
- 数据库的恢复
- 并发控制
- 完整性控制
- 安全性控制
- 数据库的维护功能 包括数据的载入,转换,转储,数据库的改组以及性能监控等
- 数据字典 数据库系统中存放三级结构定义的数据库成为数据字典(DD)
1.5 数据库系统(DBS)
1.5.1 DBS的组成
DBS 是采用了数据库技术的计算机系统.它是数据库,硬件,软件和数据库管理员的集合体.
数据库(DB) : 是各项应用有关的全部数据的集合.分为两类,一类是应用数据的集合,成为物理数据库, 是数据库的主题;另一类是各级数据结构的描述,称为描述数据库,由DD系统管理.
数据库管理员(DBA)
DBA需要具备的素质
- 熟悉企业全部数据的性质和用途
- 对所有用户的需求有
1.5.2 DBS的全局结构
常见书上的图 1.21
1.5.3 DBS的笑意
- 灵活性
- 简易性
- 面向用户
- 有效的数据控制
- 加快应用系统的开发速度
- 维护方便
- 标准化
2. 数据库设计和 ER 模型
2.1 数据库系统生存期
数据库生存期一般分为七个阶段: 规划,需求分析,概念设计,逻辑设计,实现,运行维护
2.1.1 规划阶段
对于数据库系统,特别是大型数据库系统或大型信息系统中的数据库群,规划阶段是十分必要的. 规划的好坏将直接影响到整个系统的成功与否,对应用单位的信息化进程将产生深远影响.
规划阶段的具体步骤:
-
系统调查 对应用单位做全面的调查.发现其存在的主要问题,并画出组织层次图,以了解企业的组织结构
-
可行性分析 从技术,经济,效益,法律等诸方面对建立数据库的可行性进行分析,然后写出可行性分析报告;组织专家进行讨论其可行性
-
确定数据库系统的总目标, 并对应用单位的工作流程进行优化和制定项目开发计划. 在得到决策部门批准后,就正式进入数据库系统的开发工作
2.1.2 需求分析阶段
这一阶段是计算机人员(系统分析员)和用户双方共同收集数据库所需的信息内容和用户对处理的需求, 并以需求说明书的形式确定下来,作为以后开系统开发的指南和系统验证的依据
需求分析阶段的具体步骤:
- 分析用户活动,产生业务流程图
- 确定系统范围,产生系统关系图
- 分析用户活动涉及的数据,产生数据流图(DFD)
- 分析系统数据,产生数据字典
数据字典中通常包括数据项,数据结构,数据流,数据存储和处理5个部分
2.1.3 概念设计阶段
概念设计的目标是产生反应用户单位信息需求的数据概念结构,即概念结构,概念模型独立于计 算机硬件结构,独立于支持数据的DBMS.
概念设计的主要步骤:
-
进行数据抽象,设计局部概念模型
设计概念结构时,常用的数据抽象方法是"聚集"和"概括"
-
将局部概念综合成全局概念模型
-
评审 确认全局结构是否完整,各种划分是否合理,是否存在不一致性,各种文档是否齐全
2.1.4 逻辑设计阶段
概念设计的结果是得到一个与DBMS无关的概念模型.而逻辑设计的目的是把概念设计阶段设计好的 概念模型转换成具体的逻辑模型.
逻辑设计的主要步骤:
- 把概念模型转换成逻辑模型 ER模型转换成关系模型
- 设计外模型
- 设计应用程序与数据库的接口
- 评价模型
- 修正模型
2.1.5 物理设计阶段
具体步骤:
- 存储记录结构设计
- 确定数据存放位置
- 存取方法的设计
- 完整性和安全性考虑
- 程序设计
2.1.6 数据库的实现
主要包括
- 用DDL定义数据库结构
- 数据装载/组织数据入库 具体步骤: 筛选数据, 输入数据, 转换数据格式, 校验数据, 综合数据
- 编制与调试应用程序 该步骤使用模拟数据进行调试
- 数据库试运行 功能调试,性能测试
2.1.7 数据库的运行与维护
在数据库运行阶段,对数据库经常性的维护工作主要由DBA完成,它包括以下内容:
- 数据库的转储和恢复
- 数据库安全性,完整性控制
- 数据库性能的监督,分析和改进
- 数据库的重组织和重构造
3. 关系模式设计理论
关系模式设计理论主要包括三个方面的内容: 数据依赖,范式和模式设计方法
3.1 关系模式的设计准则
3.1.1 关系模式的冗余和异常问题
__分解__是解决冗余的主要方法,也是规范化的一条原则:"关系模式有冗余,就分解它"
3.1.2 关系模式的非形式化设计准则
准则 3.1 : 关系模式的设计尽可能只包含有直接联系的属性,不要包含有间接联系的属性. 也就是,每个关系关系模式应只对应于一个实体类型或一个联系类型.
准则 3.2 : 关系模式的设计尽可能使得相应关系中不出现插入,删除和修改等操作异常现象. 如果出现任何异常,则要清楚的加以说明,并确保更新数据库的程序正确操作.
准则 3.3 : 关系模式的设计尽可能使得相应关系中避免放置经常为空的属性.
准则 3.4 : 关系模式的设计应尽可能使得关系的等值连接在主键和外键的属性上进行, 并且保证连接以后不会产生额外的元组. > 如果两个连接匹配的不是外键或主键,那么这种连接很可能会产生额外元组
3.2 函数依赖
3.2.1 函数依赖的定义
定义 3.1 : 设有关系模式 R(U), X 和 Y 是属性集 U 的子集, 函数依赖(FUnctional Dependency, 简记为 FD) 是形成 的一个命题, 只要r是R的当前关系, 对r中任意两个元组 t 和 s,都有 t[X] = s[X] 蕴含 t[Y] = s[Y], 那么称 在关系模式 R(U)中成立.
这里 t[X] 表示元组 t 在属性集 X 上的值,其余类同. 读作 X 函数决定 Y, 或 Y 函数依赖于 X. FD 是对关系模式 R 的一切可能的关系 r 定义的. 对于当前关系 r 的任意两个元组, 如果 X 相同,则要求 Y 值也相同.即有一个 X 值就有一个 Y 值与之对应, 或者说 Y 值由 X 值决定. 因而这种依赖称为函数依赖.
当关系模式上存在函数依赖时,对其关系中的值将有严格的限制.
定义 3.2 : 如果 和 同时成立,则可记为 . 也就是在关系中, X 值和 Y 值具有一一对应的关系.
3.2.2 FD 的逻辑蕴含
定义 3.3 : 设 F 是在关系模式 R 上成立的函数依赖的集合, 是一个函数依赖. 如果对于 R 的每个满足 F 的关系 r 也满足 , 那么 F 逻辑蕴含 ,记为 .
定义 3.4 : 设 F 是函数依赖集, 被 F 逻辑蕴含的函数依赖全体构成的集合,称为函数依赖集 F 的 闭包(Closure), 记为 . 即
3.2.3 FD 的推理规则
设 U 是关系模式 R 的属性集. F 是 R 上成立的只涉及到 U 中舒心的函数依赖集. FD 的推理规则有以下三条:
自反性(Reflexivity) : A1 : 若 , 则 在 R 上成立.
增广性(Augmentation) : A2 : 若 在 R 上成立,且 , 则 在 R 上成立.
传递性(Transitivity) : A3 : 若 和 在 R 上成立, 则 在 R 上成立.
定理 3.1 : FD 推理规则 A1, A2 和 A3. 也就是, 如果 是从 F 用推理规则导出, 那么 在中
定理 3.2 FD 的其他五条推理规则
合并性(Union) : A4 :
分解性(Decomposition) : A5 :
伪传递性 : A6 :
复合性(Composition) : A7 :
通用一致性定理(Genernal Unification Theorem) :
定义 3.5 : 对于 , 如果 , 那么称 是一个 平凡的 FD, 否则称为 非平凡的 FD
正如名称所示,平凡的 FD 并没有实际意义,根据规则 A1 就可以退出. 人们感兴趣的是非平凡的 FD. 只有非平凡的 FD 才和 真正的 完整性约束条件相关.
从规则 A4 和 A5. 立即可得到下面的定理
定理 3.3 : 如果 是关系模式 R 的属性集, 那么 成立的充分必要条件是 成立
3.2.4 FD 和关键码的联系
函数依赖是关键码概念的推广.
定义 3.6 : 设关系模式 R 的属性集是 U, X 是 U 的一个子集.如果 在 R 上成立, 那么称 X 是 R 的一个超键. 如果 子 R 上成立,但对于 X 的任一真子集 都有 不成立,那么称 X 是 R 上的一个候选键(没有多余属性).
一般键都是指候选键.
3.2.5 属性集的闭包
定义 3.7 : 设 F 是属性集 U 上的 FD 集, X 是 U 的子集. 那么(相对于 F)属性集 X 的闭包用 表示, 它是一个从 F 集使用 FD 推理规则推出的满足所有 的属性A的集合:
从属性集闭包的定义,立即可得出下面的定理
定理 3.4 : 能用 FD 推理规则推出的充分必要条件是
算法 3.1 : 求属性集 X 相对于 FD 集 F 的闭包 : 设属性集 X 的闭包为 , 其计算算法如下:
3.2.6 FD 集的最小依赖集
定义 3.8 : 如果关系模式 R(U) 上的两个函数依赖集 F 和 G, 有 ,则称 F 和 G 是等价的函数依赖集
F 和 G 等价,意味着 F 中每一个 FD 都可以从 G 推导出来, 并且 G 中每一个 FD也都可以从F推导出来
函数依赖集 F 中的 FD 很多,我们应该从 F 中去掉平凡的 FD, 无关的 FD, FD 中无关的属性, 以求得与 F 等价的最小依赖集 G.
定义 3.9 如果函数依赖集 G 满足下列三个条件,则称 G 是最小依赖集
- G 中每个 FD 的右边都是单属性
- G 中没有冗余的 F, 即 G 中不存在这样的函数依赖 , 使得 与 G 等价
- G 中每个 FD 的左边没有冗余的属性, 即 G 中不存在这样的函数依赖 , X 有真子集 W 使得 与 G 等价.
显然, 每个函数依赖集至少存在一个等价的最小依赖集,但并不一定唯一
算法 3.2 : 计算函数依赖集 F 的最小依赖集 G
1. 根据推理规则的分解特性(A5),得到一个与 F 等价的 FD 集 G,
G中每个FD的左右均为单属性
2. 在 G 的每个 FD 中消除左边冗余的属性
3. 在 G 中消除冗余的 FD
3.3 关系模式的分解特性
3.3.1 关系模式的分解
定义 3.10 : 设有关系模式 R(U), 属性集为 U, 而 都是 U 的子集, 并且有. 关系模式 的集合用 表示, . 用代替 R 的过程 称为关系模式的分解.这里称为 R 的一个分解.也称为__数据库模式__.
3.3.2 无损分解
定义 3.11 : 在泛关系模式 R 分解陈数据库模式 时, 泛关系 r 在 的每一模式 上投影后 再连接起来,比原来r中多出来的元组,称为 寄生元组(Spurious Tuple).
定义 3.12 : 设 R 是一个关系模式, F 是 R 上的一个 FD 集. R 分解成数据库模式 .如果对 R 中满足 F 的每一个关系 r, 都有
那么称分解 相对于 F 是__无损连接分解(Lossless Join Decomposition)__, 简称为 无损分解,否则称为 损失分解(Lossy Decomposition)
_损_是指信息的丢失,而不是元组的丢失.如果一个分解不具有_无损_性质, 那么泛关系在投影连接以后就可能产生寄生元组.寄生元组表示的是错误信息.
其中符号 表示关系 r 在模式 属性上的投影. r 的投影连接表达式 用符号表示, 即
需要注意的是,上述定义有一个先决条件,即 r 是 R 的一个关系. 也就是先存在 r(泛关系) 的情况下,再去谈论分解,这是关系数据库理论中著名的__泛关系假设(Universal Relation Assumption)__
定义 3.13 : 在无泛关系假设时,对两个关系进行自然连接中被丢失的元组称为悬挂元组.
悬挂元组是造成两个关系不存在泛关系的原因.
3.3.3 模式分解的优缺点
优点:
- 模式分解能消除数据冗余和操作异常现象
- 在分解了的数据库中可以存储悬挂元组,存储泛关系中无法存储的信息
缺点:
- 分解以后,检索操作需要做笛卡尔积或连接操作,这将付出时间代价
- 在有泛关系假设时,对数据库中关系进行自然连接时,可能产生寄生元组, 即损失了信息.在无泛关系假设时,由于数据库可能存在悬挂元组,就有可能 不存在泛关系
3.3.4 无损分解的测试方法
略
3.3.5 保持 FD 的分解
分解的另一个特性是在分解的过程中能否保持函数依赖集,如果不能保持 FD, 那么数据的 寓意就会出现混乱.
定义 3.14 : 设 F 是属性集 U 上的 FD 集, Z 是 U 的子集, F 在 Z 上的投影用 表示,定义为
定义 3.15 : 设 是 R 的一个分解, F 是R 上的 FD 集, 如果有 , 那么称分解 保持函数依赖集 F.
3.4 范式
关系模式的好与坏,用什么标准来衡量? 这个标准就是模式的__范式(Normal Forms, 简记为 FN)__.
3.4.1 第一范式(1NF)
定义 3.16 : 如果关系模式 R 的每个关系 r 的属性值都是不可分的原子值,那么称 R 是 __第一范式(First Normal Forms, 简记为 1NF)__的模式.
满足 1NF 的关系称为规范化的关系,否则称为非规范化的关系.关系数据库研究的关系都是规 范化的关系.
3.4.2 第二范式(2NF)
定义 3.17 : 对于 ,如果存在 有 成立, 那么称 是局部依赖(A 局部依赖于 W);否则称 是完全依赖.
完全依赖也称为__左部不可约依赖__.
定义 3.18 : 如果 A 是关系模式 R 的候选键的属性,那么称 A 是 R 的主属性; 否则称 A 是 R 的非主属性
定义 3.19 : 如果关系模式 R 是 1NF, 且每个非主属性完全函数依赖于候选键,那么称 R 是第二范式(2NF)的 模式.如果数据库模式中每个关系模式都是 2NF,则称数据库模式为 2NF 的数据库模式.
不满足 2NF的关系模式中必定存在有非主属性对关键码的局部依赖.
3.4.3 第三范式(3NF)
定义 3.20 : 如果 是传递依赖(A 传递依赖于 X).
定义 3.21 : 如果关系模式 R 是 1NF, 且每个非主属性都不传递依赖于 R 的候选键,那么称 R 是第三范式 (3NF)的模式.如果数据库模式中每个关系模式都是 3NF,则称其为 3NF 的数据库模式.
定义 3.22 : 设 F 是关系模式 R 的 FD 集, 如果对 F 中每个非平凡的 , 都有X是R的超键,或者 Y 的每个属性都是主属性, 那么称 R 是3NF 的模式.
定理 3.5 : 如果 R 是 3NF 模式,那么 R 也是2NF 模式.
局部依赖和传递依赖是模式产生冗余和异常的两个重要原因. 由于 3NF 模式中不存在非主属性 对候选键的局部依赖和传递依赖,因此消除了很大一部分存储异常. 将 1NF, 2NF 转换为 3NF 的过程称为 关系的规范化处理.
3.4.4 BCNF(Boyoce-Codd NF)
定义 3.33 : 如果关系模式 R 是 1NF, 且每个属性都不传递依赖于 R 的候选键,那么称 R 是 BCNF 模式. 如果数据库中的所有关系模式都是 BCNF, 则称为 BCNF 的数据库模式.
定义 3.34 : 设 F 设计关系模式 R 的FD 集, 如果对 F 中每个非平凡 都有 X 是 R 的超键,那么称 R 是 BCNF 模式.
这个定义表明,如果非平凡的 中 X 不包含超键,那么 Y 必定 传递依赖于候选键, 因此 R 不是 BCNF 模式.
定理 : 3.6 如果 R 是 BCNF 模式,那么 R 也是 3NF 模式
3.5 多值依赖和第四范式
略
Appendix.A ER 模型
1. ER 模型的基本元素
1.1. 实体
实体(Entity) : 是一个数据对象,指应用中可以区别的客观存在的事物
实体集(Entity Set) : 是指同一类
实体类型(Entity Type) : 是对实体集中实体的定义
1.2. 联系
联系(Relationship) : 表示一个或多个实体之间的关联关系
联系集(Relationship Set) : 是指同一类联系构成的集合
联系类型(Relationship Type) : 是对联系集中联系的定义
1.3 属性
实体的某一特性称为属性(Attribute).在一个实体中,能够唯一标识实体的属性或属性 集称为"实体标识符".
2. 属性的分类
2.1 简单属性和复合属性
简单属性(Simple Attribute) : 简单属性是不可再分割的属性.例如: 年龄,性别
复合属性(Composite Attribute) : 复合属性是可以再分解为其他属性的属性.例如: 地址可分为省,市,区,街道等子属性
2.2 单值属性和多值属性
单值属性(Single-Valued Attribute) : 是指同一个实体的属性只能取一个值.例如: 年龄,性别
多值属性(Mulyi-Valued Attribute) : 实体属性可取多个值.例如: 一个文章的标签,可能会有多个标签
分解多值属性的方法
- 将原来的多值属性用几个新的单值属性表示
- 将多值属性用一个新的实体类型表示
2.3 存储属性和派生属性
派生属性(Derived Attribute) : 两个(或两个以上)属性是相关的.可以从其他属性推导该属性的值 > 派生属性的值不必存储在数据库内
存储属性(Stored Attribute) : 反之,除了能推导出值的派生属性,其他都是存储属性.
2.4 可空属性
可空属性(Null Value) : 当实体在某个属性上没有值时,可以使用空值(Null Value)的属性 : 例如: 配偶,当未婚是该值无意义,即可为空,但也可以理解为已婚但配偶未知,或尚不知是否婚 : 否.在数据库中,空值是很难处理的一种值.
3. 联系的设计
3.1 联系的元数
元数/度数(Degree) : 一个联系涉及到的实体集的个数 : 简单的可称之为 一元联系,二元联系,三元联系
3.2 联系类型的约束
3.2.1 基数约束
映射基数(Mapping Cardinalities) : 实体集 E1 和 E2 之间有二元联系,则参与一个联系中的实体数目成为映射基数 : 对于二元联系类型,可能的映射基数有 1:1, 1:N, N:M,
3.2.2 参与约束
完全参与 : 如果实体集 E 中的内阁实体都参与联系集 R 的至少一个联系中,则称实体集 E 完全参与 联系集 R
3.3 ER模型的操作
ER 模型的操作包括实体类型,联系类型和属性的分裂,合并,增删 等
分裂方式有水平分裂和垂直分裂两种 合并是分裂的逆操作过程,合并的联系类型必须是定义在相同的实体类型组合中
3.4 采用ER模型的数据库概念设计步骤
采用 ER 模型进行数据库的概念设计,可以分成三步进行: 设计局部 ER 模型,然后把各局部 ER 模型综合成一个全局 ER 模型,最后对全局 ER 模型进行优化,得到最终的 ER 模型,即概念模型.
3.4.1 设计局部 ER 模型
-
确定局部结构范围 一个数据结构是为多个不同用户服务的.各个用户使用数据的方法不同,需求不同.固先为各种用户确定局部的使用方法,并以 ER 模型来表示. 需要考虑的因素
- 范围划分要自然,易于管理
- 范围之间的界面要清晰,相互影响要小
- 范围的大小要适度
-
定义实体 每一个局部结构都包含一些实体类型,实体定义的任务就是从信息需求和局部范围定义出发,确定每一个实体类型的属性和键. 划分的依据通常有:
- 采用人们习惯的划分
- 避免冗余
- 依据用户的信息处理需求
-
定义联系
-
分配属性 分配属性分为两个步骤: 一是确定属性,二是把属性分配到 确定属性的原则:
- 属性应该是不可再分解的寓意范围.不可分解是为了使模型结构简单化,不出现嵌套结构.
- 实体与属性之间的关系只能是 1:N 的
- 不同实体类型的属性之间应无直接关系
3.4.2 设计全局 ER 模型
-
确定公共实体类型 一般把同名实体类型作为公共实体类型的一类候选,把具有相同键的实体类型作为公共实体类型的另一类候选.
-
合并局部 ER 模型 合并原则: 首先进行两两合并; 先合并那些现实世界中有联系的局部结构;合并从公共实体类型开始,最后加入独立的局部结构. 进行二元合并是为了减少合并工作的复杂性.后两项则是为了使合并结果的规模尽可能小.
-
消除冲突
- 属性冲突
- 结构冲突
- 命名冲突
3.4.3 全局 ER 模型的优化
一个好的全局 ER 模型,除能准确,全面地反映用户功能需求外,还应满足下列条件(优化目标):
- 实体类型的个数尽可能少
- 实体类型所含属性个数尽可能少
- 实体类型间联系无冗余
优化规则:
- 合并实体类型 可以把 1:1 联系的两个实体类型合并
- 消除冗余属性
- 消除冗余联系
4. ER 模型到关系模型的转换
4.1 ER 图转换成关系模式集的算法
-
实体类型的转换
实体 | 关系模式 :---:|:------: 实体 | 关系模式 实体属性 | 关系模式属性 实体标识符 | 关系模式的键
-
联系类型的转换
-
二元联系的转换
- 1:1 在任意一个关系模式中加入另一个关系模式的键作为外键
- 1:N 在N端实体转换成的关系模式中加入1端关系模式的键作为外键
- N:M 将联系类型转换为关系模式,将两段的键作为外键加入到该关系模式, 并将联系类型的属性加入到该模式中,而键为两段实体键的组合
-
一元联系的转换 和二元转换类似
-
三元联系类型的转换
- 1:1:1 在任意一个关系模式中加入另外两个的键作为外键,加入联系类型的属性
- 1:1:N 同上,将键加入到 N 端实体转换成的关系模型中
- 1:M:N 将联系类型转换为关系模型,将 N 端和 M 端的键作为外键和联系类型的 属性加入到该关系模型中, 键为 N 端和 M 端实体键组合
- M:N:P 同上,将三端的键(作为外键)和联系属性加入到该关系模型, 键为三端实体键的组合
-
4.2 采用 ER 模型的逻辑设计步骤
-
导出初始关系模式集 即把概念设计的结果(全局 ER 模型)转换为初始关系模式集
-
规范化处理 规范化的目的是减少乃至消除关系模式中存在的各种异常,改善完整性,一致性和存储效率
-
模式评价 主要包括功能和性能两方面
-
模式修正
-
设计子模式(外部模式 )
5.增强的 ER 模型
为了更准确的模拟现实世界,需要扩展基本 ER 模型的概念,从而产生了增强的 ER 模型(Enhanced-ER model, 简称 EER)
5.1 弱实体与强实体
若实体 : 一个实体的存在必须依赖于其他实体
若实体参与联系时是完全参与,强实体与弱实体的联系只能是 1:N或N:M
强实体 : 可不必依赖于其他实体
5.2 子类实体与超类实体
单较低层上实体类型表到了与之联系的较高层上的实体类型的特殊情况时,就称较高层上实体类型为超类型(Supertype),较低层上实体类型为子类型(Subtype)
在数据库设计中,子类到超类的抽象化过程称为概化,则是自底向上的概念综合(Synthesis);从超类具化到之类的过程称为特化,则是自顶向下的概念发挥(Refinement).
之类与超类有两个特点:
- 之类与超类之间具有继承性特点
- 这种继承性是通过之类实体和超类实体具有相同的实体标识符实现的
此外,有两种约束适用于特化过程.
不相交约束(Disjointness Constraint) : 约束之类特化是是否相交,分为不相交和重叠两种情况
不相交(Disjoint) : 约束规定了在特化过程中,之类必须是不想交的.
重叠(Overlap) : 在特化过程中,子类可以相交
完备性约束(Complete Constraint): : 分类整体特化和部分特化
整体特化(Total Specialization) : 约束指定超类中的每个实体必须是特化中的某个子类的一个成员
部分特化(Partial Specialization) : 超类中的实体可以不属于任何一个子类
在 ER 图中,所有的子类和超类组成了__层次(Hierarchy)__或 __格(Lattice)__的结构
6. ER模型的基本表示
定义 | 表示 |
---|---|
实体 | 矩形 |
联系 | 菱形 |
属性 | 椭圆 |
多值属性 | 双线椭圆 |
派生属性 | 虚线椭圆 |
实体标识符 | 下划线 |
实体与属性 | 直线连接 |
联系与属性 | 直线连接 |
联系的基数约束 | 在连线上以(m,n)的形式表面 |
联系的完全参与 | 用双线连接 |
联系的类型 | 在直线两端指明(1:1,1:N,N:M) |
弱实体 | 双线矩形框 |
不相交 | 小圆圈里为 d |
重叠 | 小圆圈里为 o |
整体特化 | 超类实体与圆圈之间用__双线条__连接 |
部分特化 | 超类实体与圆圈之间用__单线条__连接 |
Appendix.B 关系模型
1. 关系模型的基本术语
关系模型(Relation Model) : 用二维表格表示实体集,用关键码表示实体之间联系的数据模型称为关系模型.
在关系模型中,字段称为属性,字段值称为属性值,记录类型称为关系模式,记录称为 元组(Tuple),元组的集合称为关系(Relation) 或 实例(Instance).
在关系中属性的个数称为元数(Arity), 元素个数称为 基数(Cardinality)
**关键码(Key,简称键)**由一个或多个属性组成,一般有以下几种:
超键(Super Key) : 在关系中能唯一标识元组的属性集称为关系模式的超键
候选键(Candidate Key) : 不含有多余属性的超键称为候选键
主键(Primary Key) : 用户选作元组标识的候选键称为主键
外键(Foreign Key) : 如果模式R中,属性K是其他模式的主键,那么K在模式R中称为外键
关系中每一个属性都有一个取值范围,称为属性的值域(Domain).属性A的取值范围用 DOM(A) 表示.每一个属性对应一个值域,不同的属性可对应于同一值域.
2. 关系的定义和性质
关系是一个属性数目相同的元组的集合.
如果一个关系的元组数目是无限的,则称为无限关系,否则称为有限关系.由于计算机存储系统限制,只限于研究有限关系.
在关系模型中,对关系有下列规范性限制:
- 关系中每一个属性值都是不可分解的
- 关系中不允许出现重复元组
- 由于关系是一个集合,因此不考虑元组间的顺序,即没有行序
- 元组中的属性在理论上也是无序的,但使用时按习惯考虑列的顺序
3. 三类完整性规则
-
实体完整性规则(Entity Integrity Rule) 这条规则要求关系中元组在组成主键的属性上不能有空值.
-
参照完整性规则(Reference Integrity Rule) 即不允许引用不存在的实体. 这点规则有以下变通:
- 外键和相应的主键可以不同名,只要定义在相同的值域上即可
- 外键可以是引用同一组关系模式, 此时表示了同一个关系中不同元组之间的联系
- 外键值是否允许空,应视具体情况而定
-
用户定义的完整性规则
Appendix.X 额外的笔记
名词定义
完全非平凡函数依赖 : 仅当其右边集合的属性都不在左边的集合中时成立
完全还原模型 : 支持四种备份模式, 1.完全备份, 2.差异备份, 3.事务日志备份, 4.文件组备份
锁的类型 : 互斥锁,共享锁
分类 : 分类的目的是学会一个分类函数或分类魔心,该模型能把数据库中的数据项映射到给定 类别中的某一个.
聚类 : 聚类是把一组个体按照相似性归成若干类别,目的是使属于同一类别的个体之间距离尽 可能小,而不同类别上个体间距离尽可能大.
数据库恢复顺序 : 首先恢复完全备份,其次恢复差异备份,然后恢复日志备份
功能需求 : 是详细描述总体结构及功能,系统覆盖的功能范,各功能子系统的划分,功能描述及 子系统之间的关系等
信息需求/数据需求 : 是完整描述系统所涉及的信息范围, 数据的属性特征,数据之间的关系和约束.
性能需求 : 描述对系统的性能要求,包括响应时间,存储容量,系统适应性,数据库安全性, 一致性和可靠性.
元数据 : 是描述数据属性的信息,用来支持如指示存储位置,历史数据,资源查找,文件记录等功能. 元数据算是一种电子式目录,为了达到编制目录的目的,必须描述并收藏数据的内容 或特色,进而达到协助数据检索的目的.
需求分析 : 是指对即将要开发的系统要做什么以及完成什么功能的全面描述,它关注的是这个系统 必须要做什么.
日常维护的相关工作
- 数据库的备份和恢复
- 完整性维护
- 安全性维护
- 存储空间管理
- 冰法控制及死锁处理
可串行化调度 : 对n个事务组成的事务集 , 如果并发调度 S 等价于某一在 TS 上的串行调度,那么 S 称为可串行化调度, 否则 S 是不可串行化调度.
冲突串行化 : 如果定义早事务集 TS 上的并发调度 S 冲突等价于事务集 TS 上的某个串行调度 S', 则称 S 是冲突可串行的.冲突可串行的并发调度的执行结果与串行调度一致,是正确的, 同时又具有较高的执行效率.
触发器 : 通常用于保证业务规则和数据完整性, 其主要优点是用户可以用编程的方法来实现复杂的 处理逻辑和业务规则,增强了数据完整性约束的功能.
技术可行性 : 是根据用户提出的系统功能,性能及实现系统的各项约束条件,对系统软件,系统硬件,技术 方案作出评估和选择建议,它属于规划与分析阶段的可行性分析.
数据库应用系统的需求 : 数据需求分析, 数据处理需求分析, 业务需求分析以及在性能, 存储, 安全, 备份和恢复 等方面的要求. 数据操作相应时间, 系统吞吐量, 最大并发用户数都是性能需求分析的 重要指标.
数据库概念设计阶段的工作目标
- 定义和描述应用领域设计的数据范围
- 获取应用领域或问题域的信息模型
- 描述清楚数据的属性特征
- 描述清楚数据之间的关系
- 定义和描述数据的约束
- 说明数据的安全性要求
- 支持用户的各种数据处理需求
- 保证信息模型方便地转换成数据库的逻辑结构(数据库模式),同时也便于用户理解.
数据仓库的定义 : 是一个面向主题的,集成的,非易失的,且随时间变化的数据集合,用来支持管理人员的决策
数据仓库的特性 : 主题与面向主题,集成,不可更新,随时间变化.
聚集索引和非聚集索引 : 对数据文件和它的一个特定的索引文件,如果数据文件中数据记录的排列顺序与索引文件中 索引项的排列顺序一致,或者说,索引文件按其查找码指定的顺序与数据文件中数据记录 顺序一致,则该索引文件称为聚集索引,否则成为非聚集索引.
稠密索引和稀疏索引 : 如果数据文件的每个查找码值在索引文件中都对应一个所以记录,则该索引称为稠密索引. 如果只是一部分查找码对应一个索引记录,则该索引码称为稀疏索引.
主索引和辅索引 : 在数据文件包含的属性集上建立的索引称为主索引.在数据文件的非主属性上建立的索引 称为辅索引.
软件总体设计的依据包括 需求分析阶段得到的数据流图, 事务描述和业务规则等需求分析结果. 总体设计得到的系统总体结构和分层模块结构可以用模块结构图表示,模块结构图主要关心模块 的外部特性,即上下级模块以及同级模块间的数据传递和电泳关系,与内部处理流程无关.
数据模型 : 数据模型是数据库系统的形式框架,是用来描述数据的一组概念和定义.它是包括描述数据,数据 联系,数据操作,数据语义以及数据一致性的概念工具,是数据库系统的核心和基础.按照数据 模型在数据建模和数据管理中的不同作用,可以将其分为概念数据模型,数据结构模型和物理数 据模型.概念数据模型简称概念模型,是按用户的观点对数据和信息进行建模,是现实世界到 信息世界的第一层抽象.数据结构模型也称为表示型或实现型的数据模型,是机器世界中与具体 DBMS 相关的数据模型.物理数据模型属于底层数据模型,通过诸如记录格式,记录顺序和存取路 径等表示信息,描述数据在数据库系统中的实际存储方式/概念模式是对数据库中全体数据的 逻辑结构和特征的描述,是所有用户的公共数据视图,一个数据库只有一个模式.
数据库应用系统包括概念设计,逻辑设计,物理设计三个步骤.每个步骤按照数据组织与存储,数据 访问与处理,应用设计等几个方面进行.在概念设计阶段,采用自下而上的 E-R 设计. 将关系模式转换为具体 DBMS 平台支持的关系表是数据库物理设计阶段的工作.设计视图和关系 模式的完整性约束是数据逻辑设计阶段的工作.
OLTP 中的数据一般按面向应用的方式组织,数据仓库系统中的数据一般按面向分析主题的方式组织.
日志文件的作用
- 用于事务故障恢复和系统故障恢复
- 动态转储中必须建立日志文件
- 静态转储中也可以建立日志文件
为保证数据库是可恢复的,必须遵循两条规则
- 登记的次序严格按并行事务执行的时间次序
- 必须先写入日志文件,后写入数据库.
人机界面设计原则
- 用户应当感觉系统的运行始终在自己的控制之下,保持用户与人机界面的双向交流
- 当系统发生错误或程序运行时间较长时,用户界面应该提供有意义的反馈信息,并有上下文感知的 帮助系统
- 用户界面能容忍用户在操作过程中发生的各种操作错误,并能方便的从错误中恢复,保证系统不受 用户错误操作的影响
- 界面遵循一定的标准和常规
- 界面应采取灵活多样的数据输入方式,尽量减少用户的输入负担.
性能需求分析
- 数据操作响应时间,或数据访问响应时间 指用户向数据库系统提交数据操作请求到操作返回用户的时间.
- 系统吞吐量 系统在单位时间内可以完成的数据库事务或数据查询的数量. 吞吐量可以表示为 每秒事务数(TPS).
- 允许并发访问的最大用户数 在保证单个用户查询响应时间的前提下,系统最多允许多少用户同时访问数据库.
- TPS 代价值 用于衡量系统性价比的指标.
视图的作用
- 简化数据查询语句
- 使用户能从多角度看待同一数据
- 提高数据的安全性
- 提供了一定程度的逻辑独立性
结构化分析及建模方法的主要优点
- 不过早陷入具体的细节
- 从整体或宏观入手分析问题
- 通过图形化的模型对象直观的表示系统要做什么,完成什么功能
- 图形化建模方法方便系统分析员理解和描述系统
- 模型对象不涉及太多技术术语,便于用户理解模型
UML
每一种 UML 的视图都是由一个或多个图组成的, UML 提供了9种不同的图,分为两类.
- 静态图 用例图, 类图, 对象图, 组件图, 部署图
- 动态图 顺序图, 交互图, 状态图, 和 活动图
可以根据不同的视图应用进行分类:
- 用例视图: 用例图
- 结构视图: 类图, 对象图
- 行为视图: 顺序图, 交互图, 状态图, 活动图
- 实现视图: 组件图
- 环境视图: 部署图
分布式数据库
目的是: 本地自治, 非集中式管理,高可用性,位置独立性,分布式查询处理,分布式事务管理等.
-
分布式数据库系统概念 是物理上分散,逻辑上统一的数据库系统.
-
分布式数据的概念 分布式数据库则是分布式数据库系统中个场地上数据库的逻辑合.
-
分布式数据库的结构
- 共享内存结构
- 共享磁盘结构
- 无共享结构 最好的并行结构
- 次结构 以上体系结构的结合.
分布式数据库的分布策略
数据分片 : 对某一个关系进行分片是将关系划分为多个片段, 这些片段中包含足够的信息可以使关系重构.
数据分片有四种基本方法:
- 水平分片 在关系中从行的角度(元组)依据一定条件划分为不同的片段,关系中的每一行必须至少属于 一个片段,以便在需要时可以重构关系
- 垂直分片 在关系中从列的角度(属性)依据一定的条件分为不同的片段,各片段中应该包含关系的主码 属性,一边通过连接方法恢复关系.
- 导出分片 是导出水平分片,分片的依据不是本关系的条件,而是其他关系属性的条件.
- 混合分片 以上三种方法的混合
范式的简述
- 第一范式 指关系必须满足每一个属性值都是不可分解的数据项
- 第二范式 在第一范式的基础上,使关系中的每一个属性必须只依赖主码(非主属性完全依赖于候选键)
- 第三范式 在第二范式的基础上,每一个非主属性必须只依赖于主码 (非主属性都不传递依赖于候选键)
一般关系模式规范化工作仅做到 3NF 就可以把关系中不合理的属性基本消除.
关于性能/优化
- 将表的数据和索引放置在同一磁盘上不利于提高系统查询的效率
- 物理设计的目标是得到存储空间占用少,数据访问效率高和维护代价低的数据库物理模式. 设计一个好的索引和索引字段,可以提高数据查询的速度和效率.
- 尽可能先执行查询条件,把表连接放到最后执行
- 可以使用 FIFS 来避免活锁的产生
- 使用内连接替代左右连接
查询优化
- 合理使用索引
- 避免或简化排序
- 消除对大型表进行数据的顺序存取
- 避免相关子查询
- 避免困难的正则表达式
- 使用临时表加速查询
- 用排序来取代非顺序磁盘存取
- 不充分的连接条件(避免左右连接)
- 使用存储过程
- 不要随意使用游标
- 使用事务处理
分类/方法
SQL Server 2000 数据库备份方式
- 先创建备份设备,然后将数据库备份到备份设备上(这种设备称为永久备份设备)
- 直接将数据库备份到物理文件上(这种设备称为临时备份设备)
在执行备份过程中, 可以同时向多个备份设备写备份内容,也称为并行备份.
死锁的预防方法
- 一次加锁 要求每个事务在开始执行时必须将需要访问的数据项全部枷锁,否则不允许执行下去, 也就是要求事务必须能一次性的获得对需要访问的全部数据项的访问权.
- 顺序加锁 该方法对数据库中事务访问的所有数据项规定一个加锁顺序,每个事务在执行过程中 必须按此顺序对所需数据项加锁.
数据库管理员执行的工作
- 数据库的转储和恢复
- 数据库的安全和完整性控制
- 数据库的性能监控和分析
- 数据库的重组和重构
系统故障/软故障 的处理方法
对于未完成的事务,可能已经写入数据库的内容,回滚所有未完成的事务写入的结果,以保证 数据库中数据的一致性. 对于已完成的事务可能部分或全部留在缓冲区的结果,需要重做所有已提交的事务,以将数据 库恢复到一致状态 即,撤销(Undo)所有未提交的事务,重做(Redo)所有已提交的事务.
数据仓库中数据的维护策略
- 实时维护
- 延时维护 查询时触发维护,减少了对数据源的更新时间,但视图查询时间较长.
- 快照维护 定期对数据库进行维护,维护操作的触发条件是时间.
数据库物理设计步骤
- 数据库逻辑模式调整
- 文件组织与存取设计
- 数据分布设计
- 安全模式设计
- 确定系统配置
- 物理模式评估
DBAS 总体设计
- 确定 DBAS 体系结构
- 系统硬件平台和操作系统,数据库管理系统等系统软件的选型和配置
- 应用软件结构设计
- 对需求分析阶段识别出的业务规则进行初步设计,细化业务规则流程,分析所处理的业务数据 和处理方式,明确采用的关键技术和算法等.
- 对系统采用的关键技术进行方案选型和初步设计.
RAID 分级
RAID等级 | n | 最小容错硬盘数 | 可用容量 | 性能 | 安全性 | 目的 | 应用产业 |
---|---|---|---|---|---|---|---|
JBOD | ≧1 | 0 | n | 不变 | 无(同RAID 0) | 追求最大容量 | |
0 | ≧2 | 0 | n | 最高 | 一个硬盘异常,全部硬盘即跟着异常 | 追求最大容量、速度 | 3D产业实时渲染、视频剪接高速缓存用途 |
1 | ≧2 | 总数的一半 | 总容量的一半 | 稍有提升 | 最高 | 追求最大安全性 | 个人、企业备份 |
5 | ≧3 | 1 | n-1 | 高 | 高 | 追求最大容量、最小预算 | 个人、企业备份 |
6 | ≧4 | 2 | n-2 | 比RAID 5稍慢 | 安全性较RAID 5高 | 同RAID 5,但较安全 | 个人、企业备份 |
10 | ≧4 | 总数的一半 | 总容量的一半 | 高 | 安全性最高 | 综合RAID 0/1优点,理论速度较快 | 大型数据库、服务器 |