本文依据《数据库系统概率》(第五版), 记录了数据库理论基础, 关系数据库设计, 以及数据库有关技术. 关于SQL语句的有关知识, 可以阅读SQL语法精简笔记. 关于大数据的有关内容, 可以阅读大数据技术原理.
第一章 绪论
数据库系统概述
数据库
数据库是 长期存储 在计算机内, 有组织的 , 可共享 的 大量 数据的集合. 数据库中的数据按照一定的 数据模型 组织, 描述和存储, 具有 较小的冗余度(redundancy)、较高的数据独立性(data independence)和 易扩展性(scalability), 并可为各种用户共享.
常见数据库
Database | Description |
---|---|
Oracle RDBMS | 成熟的商业数据库, 支持各种主流平台 |
Microsoft SQL Server | 微软的数据库, 可在windows上运行 |
MySQL | 开源的免费数据库, 支持多种平台, 适合web环境使用 |
信息和知识
- 信息(Information): Data + Context
- 知识(Knowledge): Data + Context + Casual relation(因果关系)
数据库系统构成
- 数据库(DataBase, DB)
- 数据库管理系统(DataBase Management System, DBMS)
- 应用程序
- 数据库管理员(DataBase Administrator, DBA)
数据库系统特点
- 数据结构化
- 数据的共享性高, 冗余性低, 易于扩充
- 数据独立性高
- 数据由DBMS统一管理和控制
DBMS主要功能
- 数据定义
数据定义语言(DDL), 定义数据库表等数据对象 - 数据操纵
数据操纵语言(DML), 实现对数据库的基本操作 - 数据库运行管理
对数据库实现统一的管理, 统一的控制 - 数据库建立、维护
实用程序, 实现数据加载, 转储恢复, 重组重构, 性能检测分析等
数据模型
- 是对现实世界数据特征的抽象
- 是描述数据库的语言
两类数据模型
- 概念模型
- 也称信息模型, 是按照用户的观点来对数据和信息建模
- 逻辑模型和物理模型
- 逻辑模型主要包括网状模型, 层次模型, 关系模型, 面向对象模型等
- 是按照计算机系统的观点进行数据建模
- 物理模型是最底层的数据抽象, 描述数据在系统内部的表示方式与存取方法
数据库系统结构
数据库的模式和实例
- 模式是对数据库的逻辑结构和特征的描述
- 是型的表示, 不涉及具体值
- 实例是一个模式具体的值
- 反应数据库某一时刻的状态
- 同一模式可以有很多实例
数据库系统的三级模式
- 模式(Schema)
- 也称为逻辑模式
- 数据库中全体数据的逻辑结构和特征的描述
- 所有用户的公共数据视图
- 是数据库系统模式结构的中间层
- 外模式(External Schema)
- 也称子模式或用户模式
- 数据库用户使用的局部数据的逻辑结构和特征描述
- 用户的数据视图是与某一应用有关的数据的逻辑表示
- 介于模式与应用之间
- 保证数据库安全性的一个有力措施
- 内模式(Internal Schema)
- 是数据物理结构和存储方式的描述
- 是数据在数据库内部的表示方式
- 一个数据库只有一个内模式
数据库的二级映像
- 外模式/ 模式映像
- 当模式改变时, 由DBA对各个外模式/模式映像做相应改变, 使外模式保持不变, 从而应用程序不必修改, 保证了数据的 逻辑独立性
- 模式 / 内模式映像
- 数据库存储结构改变时, 由DBA对模式/内模式映像做相应改变, 使模式保持不变, 从而保证了数据的 物理独立性
模式与模型
- 数据模型(Data Model)
- 是(抽象的)规约或语言, 用于说明”数据库模式”
- 有不同抽象基本的数据模型
- 概念模型: E-R模型
- 逻辑模型:层次模型, 网状模型, 关系模型, OR模型
- 数据库模式(Database Schema)
- 对数据库结构, 约束等对象的说明与规定
- 针对某一特定的应用领域
- 也称为”数据库模型”
- 有不同的抽象几倍
- 教学数据库概念模式:教学数据库E-R图
- 教学数据库逻辑模式:教学数据库关系模式
数据模型的组合要素
- 数据结构
- 数据操作
- 数据约束条件
主要的逻辑数据模型
- 第一代(70~80年代)
- 层次模型
- 网状模型
- 第二代(80年代后)
- 关系模型
- 新型数据模型(90年代后)
- 面向对象模型(Object-Oriented Model)
- 对象-关系模型(Object-Relational Model)
第二章 关系数据库
关系和码
名称 | 英文名称 | 含义 |
---|---|---|
候选码 | Candidate Key | 若关系中的某一属性(组)能唯一的标识一个元组, 则称该属性(组)为候选码 |
全码 | All-key | 最极端的情况, 关系模式中所有属性组是这个关系模式的候选码 |
主码 | Primary Key | 若一个关系中有多个候选码, 可选择一个作为主码 |
主属性 | Prime Attribute | 候选码的属性称为主属性 |
非主属性 | Non-Prime Attribute | 不包含在任何候选码中的属性称为非主属性 |
关系模式
- 关系是值, 关系模式(Relation Schema)是型
- 关系模式是对关系的描述, 包括元组的结构描述和完整性约束条件描述
关系的完整性
- 实体完整性(Entity Integrity)
- 如果属性A是关系R的主属性, 则属性A不可为空
- 参照完整性(Referential Integrity)
- 若属性F是关系R的外码, 对于与关系S的主码K
- 则对于每个元组在F上的取值, 或者为空, 或者为S的某个元组的主码值
- 用户定义完整性(User-defined Integrity)
- 属性是否唯一
- 非主属性是否可为空
- 属性的取值范围
第四章 数据库安全性
数据库的安全性是指保护数据库以防止不合法的使用导致的数据泄露, 更改或破坏.
用户身份鉴别
名称 | 含义 |
---|---|
标识(Identification) | 标识用户身份 |
鉴别(Authentication) | 核实用户身份 |
安全等级划分
安全级别 | 定义 | 解释 |
---|---|---|
A1 | 验证设计 | 在B3的基础上, 给出形式化设计说明和验证 |
B3 | 安全域 | 满足访问监控器要求, 审计能力更强 |
B2 | 结构化保护 | 提供形式化的安全策略模型 |
B1 | 标记安全保护 | 对数据进行标记, 对标记的主体和客体实施强制存取控制, 是真正意义上的安全产品 |
C2 | 受控存取保护 | 安全产品的最低档, 支持审计和资源隔离 |
C1 | 自主安全保护 | 非常初级的保护, 实现用户和数据分离, 提供自主存取控制 |
D | 最小保护 | 所有不安全的系统归为此类 |
存取控制
- 自主存取控制(DAC, Discretionary Access Control)
- 用户对不同的数据对象有不同的存取权限
- 不同用户对同一对象也有不同权限
- 用户可以授权给其他用户
- 强制存取控制(MAC, Mandatory Access Control)
- 每一个数据对象被标以一定的密级
- 每一个用户被授予某一个级别的许可证
- 对与任意对象, 只有合法许可证的用户可以存取
权限控制
有关权限控制的内容, 查看SQL语法精简笔记的权限控制和角色控制章节.
强制存取方式
- 敏感度标记
- 绝密(Top Secret, TS)
- 机密(Secret, S)
- 可信(Confidential, C)
- 公开(Public, P)
- 主体敏感度标记称为许可证级别(Clearance Level)
- 客体敏感度级别称为密级(Classification Level)
- 仅当主体的许可证级别大于或等于客体的密级时, 该主体才能读相应的客体
- 仅当主体的许可级别小于或等于客体的密级时, 该主体才能写相应的客体(保证高级别的数据不能被当前主体重写成低等级的数据)
审计
- 启用一个专用的审计日志(Audit Log), 将用户对数据库的所有操作记录在上面
- 审计员利用审计日志监控数据库中的各种行为, 找出非法存取数据的人、时间和内容
- C2以上的DBMS必须具有审计功能
- 由于审计消耗时间和空间, 因此DBA可以根据安全性要求, 灵活的决定是否开启审计
数据加密
- 根据一定的算法将原始数据, 从明文(Plain text)变为不可直接识别的密文(Cipher text)
- 可分为存储加密和传输加密
第五章 数据库完整性
数据库完整性(Integrity)是指数据的正确性(Correctness)和相容性(Consistency). 正确性是数据符合现实世界语义, 反应了当前的实际状况. 相容性是数据库同一对象在不同关系表中的数据是符合逻辑的.
数据库完整性的要求
- 提供定义完整性约束条件的机制
- 提供完整性检查方法
- 违约处理
违约处理
操作 | 含义 |
---|---|
拒绝执行(NO ACTION) | 不允许该操作执行, 通常是默认操作 |
级联操作(CASCADE) | 当删除或修改被参照表的一个元组导致与参照表不一致时, 删除参照表中的数据 |
设置为空值 | 当删除或修改被参照表的一个元组导致与参照表不一致时, 将参照表中的数据置为空 |
用户定义完整性
操作 | SQL关键字语句 |
---|---|
不许取空值 | NOT NULL |
列值唯一 | UNIQUE |
自定义检查 | CHECK |
关于具体的完整性定义, 参考SQL语法精简笔记的完整性约束章节
第六章 关系数据理论
数据依赖
- 是一个关系内部, 属性与属性之间的一种约束关系
- 是现实世界属性间相互联系的抽象
- 是语义(Semantics)的一种体现
- 数据依赖(Dependency)是表内部属性的关系
- 联系(Relationship)是不同表之间的关系
两种依赖
- 函数依赖(Functional Dependency, FD)
- 多值依赖(Multi-Valued Dependency, MVD)
不合理数据库的问题
问题 | 解释 |
---|---|
数据冗余 | 某些数据多次重复的出现 |
更新异常 | 更新某一数据后, 需要同时更新大量其他地方的数据 |
插入异常 | 某些条件不具备时, 无法插入数据(例如, 某个系没有学生无法加入系主任) |
删除异常 | 删除某一数据时, 其他数据一同被删除(例如, 某个系全部毕业, 系主任信息一同消失) |
一个好的数据库不应该存在插入异常, 删除异常, 更新异常, 数据冗余要尽可能少
函数依赖
- 如果X可以唯一的确定Y, 则记为 X->Y
- 若X->Y 且Y不是X的子集, 则称此为非平凡的函数依赖, 否则称为平凡的函数依赖
- 如果X->Y, 且对于任何X的子集X’, 都没有X’->Y, 则称Y对X完全函数依赖, 否则称Y对X部分函数依赖
- 如果X–>Y, Y-/->X, Y–>Z, 且Z不是Y的子集, 则Z对X传递函数依赖(Transitive Functional Dependency)
- 注意若有Y–>X, 则X<–>Y, 此时Z直接依赖X, 而不是传递依赖X
范式理论
范式 | 要求 |
---|---|
第一范式 | 关系的每个分量必须是不可分开的数据项 |
第二范式 | 如果R是第一范式, 且每个非主属性都完全函数依赖于任何的候选码, 则R是第二范式 |
第三范式 | 如果R是第一范式, 若R中不存在非主属性对码的部分依赖和传递依赖, 则R是第三范式 |
BC范式 | 如果R是第一范式, 若R中每个决定属性集都包含候选码, 则R是BC范式 |
注意:
- 如果不满足第二范式, 说明有些属性并不需要候选码中的所有属性就能确定, 但是整个元组却需要这些属性, 因此需要将元组拆分
- 如果不满足第三范式, 此时任意的断开一个函数依赖即可解决传递依赖的问题
范式的证明
对于第三范式, 如果有Y部分函数依赖X, 则存在X的一个子集X’, 有 X’–> Y, 从而有 X –> X’, X’–> Y, 即X与Y传递依赖, 因此不满足第二范式时必然不满足第三范式.
对于BC范式, 相当于所有的X都是候选码, 从而所有的依赖都是完全依赖. 由于所有的候选码之间没有依赖, 因此不可能产生传递依赖. 综上BC方式满足三范式. 由于BC范式的判定反而更简单, 因此更容易直接得到BC范式.
范式理论小结
- 并不是规范化程度越高就越好, 实际的范式选择需要结合实际情况
- 通过范式分析不一定比通过ER图分解更容易处理
第七章 数据库设计
数据库设计
- 广义的数据库设计
- 对于一个给定的应用环境, 构造优化的数据库逻辑模式和物理结构, 并据此建立数据库以及应用系统, 使之能有效的存储和管理数据, 满足各种用户的应用需求(DB+DBAS)
- 狭义的数据库设计
- 对一个给定的应用环境, 构造优化的 数据库逻辑模式和物理结构 (DB)
模式设计阶段
模式设计可以分为三个阶段, 即
- 在逻辑设计阶段将E-R图转换为具体的数据库产品支持的数据模型(例如关系模型), 形成数据库 逻辑模式
- 根据用户处理的要求, 安全性的考虑, 在基本表的基础上建立必要的视图, 形成数据的 外模式
- 在物理设计阶段根据DBMS特点和处理的需要, 进行物理存储安排, 设计索引, 形成数据库 内模式
数据字典
数据字典时进行详细设计的数据手机和数据分析所获得的主要成果. 它是关于数据库中数据的描述, 即元数据, 而不是数据本身. 数据字典一般包含以下的内容
内容 | 含义 |
---|---|
数据项 | 不可再分的数据单位 |
数据结构 | 反映数据之间的组合关系 |
数据流 | 数据结构在系统内传输的路径 |
数据存储 | 数据结构停留或保存的地方 |
处理过程 | 说明处理的功能和要求 |
E-R图
E-R模型是用E-R图来描述现实世界的概念模型, 主要包括实体、属性、实体之间的联系等. 各元素的含义如下:
名称 | 图例 | 说明 |
---|---|---|
实体 | 使用矩形表示 | 矩形框内写明实体名 |
属性 | 使用椭圆形表示 | 使用无向边连接对应的实体 |
联系 | 使用菱形表示 | 使用无向边连接相关的实体, 联系本身也可以有属性 |
UML设计
在数据库的概念模型中, 可以使用UML图进行设计, 关于此部分的内容, 参考数据库设计与UML图
实施和维护
操作 | 含义 |
---|---|
数据载入(Load) | 数据库建立好以后, 向输入库装载数据 |
功能测试 | 实际运行应用程序, 执行对数据库的各种操作 |
性能测试 | 测量系统的性能指标, 分析是否符合设计目标 |
转储和恢复(Backup/Recovery) | 正式运行后的重要维护工作之一, 从而保存数据库故障后能恢复到某种一致性的状态 |
重组织(Re-Organization) | 在不改变物理模式的情况下, 对数据进行重排, 回收垃圾, 减少指针链等操作 |
重构造(Re-Construction) | 重新调整数据库的模式和内模式 |
第八章 数据库编程
通用数据访问技术
名称 | 英文全称 | 产生原因 | 特点 |
---|---|---|---|
ODBC | Open Database Connectivity | 使用统一的标准来访问不同的数据库 | 使用同一的API访问, 数据库厂商提供驱动程序, 可移植强 |
OLEDB | Object Linking and Embedding Database | 需要访问非关系型数据库 | 提供了对关系型数据库与非关系型数据库一致的访问 |
JDBC | Java Database Connectivity | Java平台使用的统一API | 独立于数据库, 统一的API, 跨平台, 可移植性好 |
ADO | ActiveX Data Object | 更简单的面向对象的编程接口 | 基于OLEDB, 可以访问OLEDB和IDBC的接口 |
LINQ | Language Integrated Query | C#和VB的语言扩展 | 使用类似SQL的语法来查询任何形式的数据 |
NoSQL | Not Only SQL | 弥补传统数据库对超大规模数据的不足 | 高并发, 低延迟的读和写, 高伸缩性和高可用性 |
关于NoSQL的有关内容, 可以参考大数据技术原理NoSQL的有关内容.
过程化SQL
SQL的扩展, 添加了过程化语句功能. 常见的实例有Oracle的PL-SQL和SQL Server的Transaction-SQL
存储过程
过程化的SQL有两种类型, 即命名块和匿名块. 直接编写的代码是匿名块, 每次执行都需要重新编译. 存储过程和函数是命名块, 编译后存储在服务器端, 可被多次调用.
第十章 数据库恢复技术
数据库的恢复
数据库的恢复(Recovery)是数据库管理系统把数据库从错误状态恢复到某一已知的正确状态, 恢复技术是衡量系统优劣的重要指标.
故障种类
故障类型 | 解释 |
---|---|
事务内部故障 | 通常指非预期的故障, 例如运算溢出, 死锁, 强制中断等 |
系统故障 | 系统故障是造成系统停止的运作的任何事件, 使得系统需要重新启动 |
介质故障 | 系统故障称为软故障(soft crash), 介质故障称为硬故障(hard crash) |
计算机病毒 | 人为制造的恶意程序 |
事务出现故障后, 通常需要进行事务撤销(UNDO), 使得事务好像根本没有启动. 如果故障无法被撤销, 还可以利用存储在系统别处的冗余数据来重建数据库中被破坏的数据, 即数据库的恢复.
恢复实现技术
恢复的本质是冗余数据, 因此建立冗余数据有两种常见的方法, 即
恢复方法 | 解释 |
---|---|
数据转储(Backup) | 数据库管理员定期的将整个数据库复制到其他介质之中 |
登记日志文件(Logging) | 记录数据库中所有的更新操作 |
对于转储, 依据转储时是否可以更新数据库, 分为静态转储和动态转储. 对于存储的数据, 可以分为海量转储和增量存储.
数据库镜像
数据库镜像(Mirror)功能是指数据库管理系统自动把整个数据库或其中的关键数据复制到另外一个磁盘. 由数据库管理系统保证镜像数据与主数据的一致性, 从而一旦出现故障, 可以直接使用镜像(热备份)进行恢复.
最后更新: 2024年04月24日 15:50
版权声明:本文为原创文章,转载请注明出处
原始链接: https://lizec.top/2017/12/20/%E6%95%B0%E6%8D%AE%E5%BA%93%E7%B3%BB%E7%BB%9F%E5%8E%9F%E7%90%86/