数据模型

概念

数据模型用来抽象、表示和处理现实世界的数据和信息；

数据模型就是现实世界的模拟：

• 真实地模拟现实世界；
• 能为人工所理解；
• 易于在计算机实现；

现实世界中的客观对象抽象为概念，把概念模型转换为某一DBMS支持的数据模型，概念模型是现实世界到机器世界的一个中间层次；

层次

1. 概念模型CDM
   • 面向现实世界建模
   • 主要用来描述现实世界的概念化结构，与具体的DBMS无关；
   • 常用E-R模型表达
2. 逻辑模型LDM
   • 面向用户建模
   • 是具体的DBMS所支持的数据模型（网状/层次/关系/面向对象）
3. 物理模型PDM
   • 面向具体的DBMS，也面向机器
   • 描述数据在存储介质上的组织结构

三要素

1. 数据结构
   • 与数据类型、内容、性质有关的对象，如关系模型中的域、属性、关系等
   • 与数据之间联系有关的对象
   • 数据结构是对系统静态特征的描述
2. 数据操作
   • 数据操作是指对数据库中各种对象的实例允许执行的操作的集合，包括操作及有关的操作规则
   • 数据库主要有检索和更新（插入、删除、修改）两大类操作
   • 数据模型必须定义这些操作的含义、符号、规则及实现操作的语言
   • 数据操作是对系统动态特性的描述
3. 数据的约束条件
   • 数据的约束条件是一组完整性规则的集合。
   • 完整性规则是指给定的数据模型中的数据及其联系所具有的制约和依存规则，以保证数据的正确、有效、相容。
   • 提供定义完整性约束条件的机制

类型

1. 层次模型：用树来表示实体和实体间的联系；
2. 网状模型：一个联系可以被称为一个系，每个系至少由两种记录类型组成：一种等同于层次模型中父节点的首记录另一种等同于层次模型中子节点的属记录
3. 关系模型：关系模型是目前应用最广泛的数据模型，采用关系模型作为数据的组织方式，常用表描述；
4. 半结构化模型：包括XML模型，
5. 键值对型：如Redis；
6. 文档型：如MongoDB；
7. 列存：如Habse；
8. 图型：如NEO4J；

数据库安全

概念

数据共享必然带来数据安全问题，我们认为只允许有合法使用权限的用户允许访问他存取的数据；

数据库系统的安全保护措施是否有效是数据库系统主要的指标，数据库的安全性和计算机系统的安全是紧密联系、互相支持的；

数据库可能的破坏方式

• 数据库被无意破坏
  • 并发存取引起的数据异常
  • 数据分布存储的不一致问题
  • 逻辑错误造成更新事务未遵守数据一致原则
  • 事务处理中系统崩溃
• 数据库被恶意破坏
  • 未经授权的读取，修改和破坏数据

对策：

• 针对无意破坏：完整性约束控制，并发控制，数据库恢复
• 针对恶意破坏：数据库访问控制，身份鉴定，安全审计，数据加密

数据库安全性：保护数据库，防止因为用户非法使用造成数据的泄露，破坏或更改；

数据的保密：用户合法访问到机密数据后能否保证不泄密，需要指定法律等规则保证；

计算机系统安全性：

• 保护系统中的硬件，软件和数据，防止因为偶然或恶意的原因使得系统被破坏，数据更改或泄露；
• 需要建立立体防御：进不来、看不见、看不懂、改不掉、跑不了
• 可能包括三类安全性问题：技术安全，管理安全和政策法律

数据库系统的安全框架：

• 网络系统层次
  • 物理层面上避免入侵者进行物理破坏；
  • 网络层面上采用防火墙、入侵检测技术等手段阻止外部入侵。
• 操作系统层次
  • 操作系统安全策略、安全管理策略和数据安全
• 数据库系统层次
  • 用户标识和鉴别、存取控制、数据分级、视图机制、审计、数据加密

自主访问控制

概念

主体(Subject): 提出访问资源具体请求，是某一操作动作的发起者, 可能是某一用户，也可以是用户启动的进程、服务和设备等

客体(Object): 被访问资源的实体，所有可以被操作的信息、资源、对象都可以是客体, 可以是信息、文件、记录等集合体，也可以是网络上硬件设施

控制策略(Attribution):主体对客体的相关访问规则集合，即属性集合, 访问策略体现了一种授权行为，也是客体对主体某些操作行为的默认

自主访问控制的特点：

• 控制方式是自主的
  • 由客体的属主对自己的客体进行管理
  • 由属主自己决定是否将自己的客体访问权或部分访问权授予其他主体
  • 在自主访问控制下，用户可以按自己的意愿，有选择地与其他用户共享他的文件
• 可以在主体之间相互转让权限的访问控制
  • 对用户访问数据库中各种资源（包括表、视图、程序等）的权利（包括创建、查询 、更新、执行等）的控制
  • 一个用户建立了一个数据对象就自动具有了对这个数据对象的所有权利
  • 同一用户对于不同的数据对象有不同的存取权限，不同的用户对同一对象也有不同的权限，用户还可将其拥有的存取权限转授给其他用户
• C2级，灵活

权限

• 访问数据权限
  • SELECT:允许读取数据，不能修改数据
  • INSERT：允许插入新数据，不能修改已有数据
  • UPDATE：允许修改数据，不能删除数据
  • DELETE：允许删除数据
• 修改模式权限
  • INDEX：允许建立/删除索引
  • CREATE：允许建立表
  • ALTER：允许对表属性增加删除
  • DROP：允许删除表
• 其他
  • CONNECT: 允许连接数据库
  • REFERENCE:允许根据表的完整性约束中引用一个参照关系
  • USAGE: 授权用户使用指定域
  • TRIGGER：授权用户定义表中触发器
  • EXECUTE：授权用户执行函数/过程
  • UNDER：授权用户建立类的子类

授权

赋予用户一定权利，已操作数据对象

• 对象创建者自动拥有其所有权限
• 授权可由DBA授予，也可以由对象创建者授予

语法如下：

1
2
3
4

GRANT {all privileges|privilege{. privilege….}}
 ON [TABLE] tablename|viewname
 TO [PUBLIC|user_name{,user_name…}]
 [WITH GRANT OPTION]

授权的粒度：用于指定可以操作的数据对象的范围

• 关系数据库中的数据对象粒度：数据库/表/属性列/行
• 它是衡量授权机制是否灵活的一个重要指标
• 授权定义中数据对象的粒度越细，即可以定义的数据对象的范围越小，授权子系统就越灵活 ，但系统定义与检查权限的开销会相应增大
• 能否提供与数据值有关的授权反映了授权子系统精巧程度

视图授权

• 对视图也应可以授权
• 要授予其他用户与访问视图相关的权利，授权者必须拥有该视图（而且在视图所引用基本表或视图上有必要的权限）或已经通过WITH GRANT OPTION被授予了这些权限
• 若要在一个视图上授予插入、删除或更新权限，视图必须是可更新的
• 用户要建立视图，首先必须要有对所引用基本表或视图的SELECT权利

收回权限

从一个用户那里收回权限可能导致其他用户也失去该权限。这一行为称为级联回收 CASCADE。在大多数数据库系统中，级联回收是默认行为。

语法如下：

1
2
3
4

REVOKE [WITH GRANT OPTION FOR]{ALL PRIVILEGES|privilege{. Privilege….}}
 ON [TABLE] tablename|viewname
 FROM [PUBLIC|user_name{,user_name…}]
 [RESTRICT|CASCADE]

示例：

1
2
3
4
5
6
7
8
9
10

GRANT SELECT ON RecipeDetail TO LiXia；
GRANT SELECT ON RecipeMaster TO LiXia WITH GRANT OPTION；
GRANT UPDATE（Mprice） ON Medicine TO WangHao；
GRANT REFERENCE（Mno）ON Medicine TO ZhangYang；
GRANT INSERT，DELETE ON RecipeDetail TO MengFan WITH GRANT 
OPTION；
REVOKE SELECT ON RecipeDetail FROM LiXia；
REVOKE UPDATE（Mprice）ON Medicine FROM WangHao；
REVOKE GRANT OPTION FOR SELECT ON RecipeMaster FROM LiXia；
REVOKE SELECT ON RecipeMaster FROM LiXia RESTRICT；

授权图

用授权图来表示授权在用户之间的传递，图中的结点表示用户，如果用户$i$将权限传递给了$j$，则在图中增加一条 边$i\to j$。图的根是DBA 或对象创建者

用户具有授权当且仅当存在从授权图的根到代表该用户的结点的路径;

上述示例的授权图和收回权限图如下：

授权方法

RBAC方法：基于角色的授权

根据管理中相对稳定的职权和责任来划分角色

• 将访问许可权分配给一定的角色
• 用户通过饰演不同的角色获得访问许可权。

角色可以看作是一组操作的集合，不同的角色具有不同的操作集。

角色是访问控制中访问主体和受控对象之间的一座桥梁（授权模板）；

角色与用户关系：一个用户可经授权而拥有多个角色，一个角色可有多个用户组成 ；

角色与许可关系：每个角色拥有多种许可，每个许可也可以授权给多个不同的角色，每个操作可施加与多个客体，每个客体可接受多个操作；

例如

• 创建角色CREATE ROLE Admin;

• 角色授权GRANT SELECT ON RecipeMaster TO Admin;

• 角色授权给用户或其他角色：

  1 2 3 4

  GRANT Admin TO LiXia; CREATE ROLE Manager; GRANT Admin to Manager; GRANT Manager TO WangHao;

强制访问控制

MAC的特征：

• 对所有主体（系统中的活动实体，如用户）及其所控制的客体（如进程、文件、基 表、视图等）实施强制访问控制
• B1级，严格
• 每一个数据对象被标以一定的密级，每一个用户也被授予某一个级别的许可证，对 于任意一个对象，只有具有合法许可证的用户才可以存取

敏感度标记（Label）

• 对于主体和客体，DBMS为它们每个实例（值）指派一个敏感度标记
• 敏感度标记级别：绝密，机密，可信，公开
• 主体的敏感度标记称为许可证级别，客体的敏感度标记称为密级
• MAC机制就是通过对比主体的Label和客体的Label，最终确定主体是否能够存取客体

强制存取控制规则

• 仅当主体的许可证级别大于或等于客体的密级时，该主体才能读取相应的客体
• 仅当主体的许可证级别小于或等于客体ee的密级时，该主体才能写相应的客体

DAC与MAC共同构成DBMS的安全机制

• 先进行DAC检查，通过DAC检查的数据对象再由系统进行MAC检查
• 只有通过MAC检查的数据对象方可存取。

审计

审计是一种事后追责手段，体现在以下操作：

• 启用一个专用的审计日志（Audit Log），将用户对数据库的所有操作记录在上面
• DBA可以利用审计日志中的追踪信息，找出非法存取数据的人
• C2以上安全级别的DBMS必须具有审计功能，体现“跑不了”

审计负荷：

• 审计很费时间和空间
• DBA可以根据应用对安全性的要求，灵活地打开或关闭审计功能 ，执行SET AUDIT ON/OFF

故障恢复

如何应对系统故障：

• 提高系统的可靠性
• 在系统故障发生后，把数据库恢复到一致状态
  恢复的关键问题是如何建立冗余数据，以及利用冗余数据实施数据库恢复
  恢复技术：
• 记录日志文件
• 数据转储

日志

日志概念

日志是用来记录事务对数据库的更新操作的文件，是日志记录的序列

• 事务标识符：执行写操作的唯一标识符
• 数据项标识符：事务操作对象的唯一标识符
• 前像（BI）：更新前数据的旧值；
• 后像（AI）：更新后数据的新值；

记录形式

• <T START>:事务T开始
• <T COMMIT>：事务T提交
• <T ABORT>：事务T中止
• <T,X,V1,V2>：事务T对数据项X写，前像为V1，后像为V2

日志要求

• 每次事务执行写操作，必须在数据库修改前建立此次修改前的日志记录
• 日志必须存储在稳定的存储器上
• 稳定存储器中的日志记录顺序必须与写入缓冲区的日志记录顺序完全一样
  一般来说，日志的记录遵循日志先写规则：在贮存中的数据块输出到数据库之前，所有可数据块中数据有关的日志记录必须已经输出到稳定存储器上
  写日志的方式：
• 后像后写
• 后像前写
• 后像前后写

后像后写

恢复数据库的步骤

• 从后向前扫描数据库，将提交的事务放入队列redolist中
• 从前往后扫描日志，对遇到的每一个<T,X,V1>记录
  • 若不是队列中的事务，则无事发生
  • 若是队列中的事务，将数据项写为V1
• 对每个未完成的事务，在日志写入一个<T,ABORT>的记录并刷新日志

后像前写

事务恢复过程：Undo，将事务T更新的所有数据项的值设为旧值；
简化日志记录内容：

• 每一条日志记录内容为<T,X,V1>
• 需要省去新值字段；
• 事务T对数据项X执行写操作，写前的旧值为V1
  恢复管理器执行：
• 对日志从后往前扫描，将<T,COMMIT>记录的事务放入redo-list队列
• 重新对日志文件从后往前扫描
• 对每一个<T,X,V1>记录，若T在redo-list队列中，则恢复管理器忽略它；若不在，则将这个数据项改为旧值V1

后像前后写

后像在事务提交前后写入数据库，提交的时机应该和设置的缓存大小有关;
理论上事务应该按照非窃取强制写的方式刷新数据库，以保证原子性和一致性；
但是后像前后写可能存在4种组合方式刷新数据库；

• 被修改的数据项写入磁盘的时机既可能在提交前，也可能在提交后；
• 日志更新记录表示：<T,X,V1,V2>
• 有些数据库实现直接构建redo-log和undo-log，而不是维护redo-list和undo-list
• 窃取方式写日志一定包含undo操作，非强制方式写日志一定包含redo操作
  执行规则：日志先写，被更新数据项写入磁盘，更新记录<T,X,V1,V2>必须已经写到稳定存储器上
  恢复管理器步骤：
• 对日志文件从前往后扫描，将有<T,COMMIT>记录和没有<T,COMMIT>记录的事务分别放入两个队列：redo-list，undo-list
• 从前往后扫描日志，执行redo-list
• 从后往前扫描日志，执行undo-list

等幂操作

恢复机制应该是等幂的，也就是恢复过程中再次发生崩溃，恢复机制仍然可以重新恢复，前一次恢复过程是否更新为旧值或新值无关紧要；

• 多次执行操作与执行一次操作的效果完全相同
• 无论redo和undo，恢复的步骤都是等幂的；
  注意这时，redo-log内容属于逻辑日志，undo-log内容应该属于物理日志；

检查点

提交一致性检查点：

• 新的事务不能开始，直到检查点完成
• 现有事务继续执行直到中止或提交，将相关数据以及日志写入稳定存储器；
• 将checkpoint写入稳定存储器

高速缓存一致性检查点：

• 新的事务不能开始到检查点完成
• 已存在的事务不允许执行新的更新操作
• 将当前日志和数据写入磁盘
• 将<checkpoint，T-list>写入稳定存储器

数据转储

数据转储是数据库恢复中采用的技术

• 定期将整个数据库复制到其他介质保存起来
• 备用的数据文本称为后备副本
  静态转储
• 在系统中无运行事务时进行转储
• 转储开始时数据库处于一致性状态
• 转储期间不允许对数据库任何存取和修改
• 优点：实现简单
• 缺点：降低了数据库的可用性，转储必须等待事务结束，新的事务必须等待转储结束
  动态转储
• 转储过程和事务并发进行，允许对数据库进行存取和修改
• 优点：无需等待正在运行的事务结束，不会影响新事物的运行
• 缺点：不能保证副本的数据正确有效
• 利用带台转储得到的副本进行恢复，需要建立转储期间的日志活动
• 后备副本+日志文件才能将数据库恢复到某一时刻的正确状态
  完全转储: 每次转储全部数据库
  增量转储: 只转储上次转储后更新过的数据
• 从恢复角度看，使用完全转储得到的后备副本进行恢复往往更方便
• 但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效

恢复策略

故障分类

事务故障

• 逻辑错误：事务由于内部条件（如非法输入、溢出等）无法继续正常执行
• 系统错误：系统进入一种不良状态（如死锁），事务无法继续正常执行
• 事务故障使得事务无法达到预期的终点，数据库可能处于不一致的状态。恢复机制强行回滚该事务，撤销该事务对数据库做的任何修改
  系统故障
• 包括硬件故障、数据库软件或操作系统的漏洞造成的系统停止运转。它导致系统易失性存储器中的内容丢失，事务处理停止，但非易失性存储器中的内容不会受到破坏
  介质故障
• 在数据传送操作过程中由于磁头损坏或故障造成磁盘块上的内容丢失
• 需使用其他非易失性存储器上的数据库后备副本进行故障的恢复

事务故障恢复

恢复技术：利用日志文件

• 后像后写：发生故障时数据库中的数据并没有发生变化，所有数据项的修改只是在日志文件中有记录。恢复管理器忽略这些未完成的事务
• 后像前写：发生故障时，系统可能已将部分或全部数据项的修改写入磁盘，使用日志文件撤销（UNDO）此事务对数据库的修改。
• 后像前后写：发生故障时系统仍可能已将部分数据项的修改写入磁盘。使用日志文件撤销（UNDO）此事务对数据库的修改
  一般通过日志文件，需要维护redo-list和undo-list
  当系统崩溃重新启动时，它构造两个队列：undo-list存放需要撤销的事务标识符，redo-list存放需要重做得事务标识符
• 这两个队列刚开始时都是空的
• 队列构造步骤如下
  • 系统反向扫描日志，直到发现第一个记
  • 对每一个<Ti，COMMIT>记录，将Ti加入redo-list
  • 对每一个<Ti，START>记录，如果Ti不属于redo-list，则将Ti加入undo-list

系统故障恢复

• 利用日志文件：
• 后像后写
• 后像前写
• 后像前后写

介质故障恢复

• 装入最近的完全转储后备副本：若数据库副本是动态转储的，还需要同时装入转储开始时刻的日志文件副本，利用恢复系统故障的方法将数据库恢复到某个一致性状态
• 如果有后续的增量转储，按照从前往后的顺序，根据增量转储来修改数据库
• 装入转储结束后的日志文件副本，重做已完成的事务
  • 首先反向扫描日志文件，找出故障发生时已经提交的事务，将事务标识符写入redo-list
  • 然后正向扫描日志文件，对redo-list中的所有事务进行redo操作

事务并发

某些突发故障可能导致数据库产生不一致的结果；并发执行应用可以提高性能，但是有可能带来数据操作结果不符合预期
数据库的更新：

• 读数据库：将数据库中数据先从磁盘读入内存，然后再将值赋予另一个变量；
• 写数据库：现将变量的值写入内存，然后再有内存写入磁盘；
• 数据库更新应该权衡减少在磁盘上的I/O&防止数据不一致

概念

事务是用户定义的一个数据库操作序列

• 这些工作是原子的，要么全做，要么全不做，是不可分割的工作单位；
• 一个事务可以是一条SQL语句，一组SQL语句或整个程序
• 一个应用程序可以包含事务

定义

在SQL中可以显式定义

1
2
3
4
5

BEGIN TRANSACTION 
	<SQL1>
	<…>
	COMMIT|ROLLBACK
END TRANSACTION

没有显式定义事务时，DBMS按缺省方式自动划分事务

特性ACID

• 原子性Atomicity：
  • 事务的所有操作在数据库中要么全部正确反映，要么全部不反应；
  • 系统崩溃后，DBMS将恢复或撤销系统崩溃前处于活动状态的事务对数据库产生的影响，从而保证事务的原子性
  • 事务管理部件处理
• 一致性Consistency：
  • 事务完成时，必须所有数据具有一致的状态；
  • 一般由开发者确保
• 隔离性Isolation：
  • 当多个事务并发执行时，一个事务的执行不能被其他事务干扰
  • 解决前面提到的并发执行带来的错误问题
  • 交错调度的效果应该和某个串行调度结果是一致的
  • 并发控制部件处理
• 持续性Durability：
  • 一个事务一旦提交，它对数据库中的数据的改变应该是永久性的，即使系统可能出现故障
  • 恢复管理部件负责

事务并发

概念

并发执行的优点：改善系统的资源利用率，减少短事务的等待时间
调度：一个或者多个事务的操作按时间排序的一个序列
不受控制的事务调度问题：

• 丢失更新
• 读脏数据
• 不可重复读
• 幻读

原因：事务ACID特性中隔离性被破坏

隔离级别

如何实现事务隔离？

• 串行：每个事务一次顺序执行
• 并行但控制：事务之间并发执行，收到DBMS调整事务调度

读未提交Read Uncommitted

一个事务可以读取另一个未提交事务的数据

读提交Read Committed

一个事务要等另一个事务提交后才能读取数据

重复读Repeatable Read

在开始读数据时，不允许修改操作

序列化Serializable

最高的事务隔离级别，事务在这个级别下串行化执行，在该级别下性能最低

可串行化调度

概念

事务交叉调度结果与某一个串行调度结果相同
调度可串行化意味着保持着数据库的一致性，DBMS需要事务调度管理

• 事务并发完全交给操作系统并不可靠
• 调度不一定能保持数据库一致
• DBMS对事务运行加以控制，确保一致性

数学化表示

指令冲突

指令冲突性：调度中两个事务发生冲突，意味着

• 必须对同一数据对象进行操作
• 两个指令有一个写操作

冲突等价：对于调度S中属于不同事务的两条操作指令是不冲突的，则可以交换两条指令的执行顺序，得到一个新的调度S‘，称两个调度冲突等价

冲突可串行化：若一个冲突等价于一个串行调度，则这个调度是冲突可串行化的；

• 冲突可串行是可串行性的充分条件

视图等价：对于同一事务集，若两个调度$S_1$和$S_2$视图等价

• 在任何事务保证美俄事务读取相同的值，
• 写入数据库最终状态也是一样的；

视图可串行化：若某个调度视图等价于一个串行调度，则称这个调度是视图可串行化的；

• 若调度是冲突可串行化的，则一定是视图可串行化的
• 反之未必

前驱图precedence graph

定义有向前驱图$G(V,E)$

• 顶点为调度S的事务

• $T_i\to T_j$表示$T_i$先于$T_j$对应的指令执行，且二者存在某一对冲突指令

• 若前驱图存在环，则调度S不是可串行化的；

• 若前驱图不存在环，表示调度是冲突可串行化的

• 一个拓扑排序意味调度一个等价的串行调度

存储过程

定义

创建存储过程

1
2
3
4
5
6

CREATE|RPLACE Procedure <过程名>
AS
DECLARE <变量声明>
BEGIN
<ACTION>
END;

调用存储过程

1

CALL <过程名>；

删除存储过程

1

DROP Procedure <过程名>；

参数

• 输入参数IN：将存储过程外部的值传递给存储过程使用；
• 输出参数OUT:存储过程在执行时，将中间结果赋值给OUT参数，存储过程执行完后，外部用户通过OUT参数获得执行存储过程结果
• 输入输出参数INOUT:既作为输入参数，同时在执行过程中也会将中间结果输出给外部用户；

触发器

概念

触发器

• 一组SQL语句
• 当插入，更改，删除，事件发生的时候，触发器自动执行
• 用以维护数据完整性，或者其他数据处理工作
• 属于动态完整性约束

分类

根据事件分类

• DML触发器：发生数据操作事件时调用，包括INSERT UPDATE DELATE
• DDL触发器：发生数据定义事件调用，包括CREATE DROP DELETE
  根据发生时间和操作分类
• AFTER触发器：是最常见的触发器，在事件执行之后检查触发条件，若满足则调用触发器
• BEFORE触发器：在事件执行之前检查触发条件，若满足则调用触发器
• INSTEAD OF触发器：一般用于视图，事件执行之前检查触发条件，若满足，则用触发器定义的操作代替原来的数据更新操作
  根据执行粒度分类
• 语句级触发器：执行完一条SQL语句，是DBMS的默认值，关键字为FOR EA CH STATEMENT
• 元祖级触发器：在每一行触发FOR EACH ROW

触发器操作

创建触发器

1
2
3
4
5

Create｜Replace Trigger <触发器名>
Before|After|Instead Of <事件子查询>
[ For Each Row ]
When ( <条件>)
<数据操作>;

删除触发器

1

DROP Trigger <触发器名>

使用触发器可以容易实现参照完整性；

游标

定义

声明游标DECLARE
打开游标OPEN
从一个游标中逐条获取并处理记录信息FETCH
关闭游标CLOSE
以下是一个例子：

1
2
3
4

Open GPA36;
Fetch Next From GPA36 Into
msID, msName,mGPA,mcName,mmajor;
Close GPA36;

完整性约束

控制机制

完整性约束是加在数据库模式上的一个具体条件，规定什么样的数据能够存储到数据库中；
定义机制：

• 约束条件：数据模型的组成部分，约束数据库的寓意
• DBMS提供定义数据库完整性约束条件，并作为模式的一部分存入数据库

检查机制：

• 检查用户发出的操作是否违背了完整性约束条件

违约反应：

• 发现用户的操作请求使数据违背了完整性约束条件，则采取一定的动作保证数据完整性；

分类

• 主键约束PRIMARY KEY ：一个关系仅一个，属性非空
• 唯一约束UNIQUE：一个关系可声明多个，可为空，允许多个空值，不能定义在被主键约束的属性上
• 非空约束NOT NULL
• 自定义约束CHECK
• 参照完整性约束FOREIGN KEY
• 断言ASSERTION

还可以根据位置分类为列级，行级和表级约束；以下是一些表建立的约束的例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

CREATE TABLE Diagnosis{
DGno VARCHAR(10) PRIMARY KEY,
Pno VARCHAR(10) NOT NULL,
Dno VARCHAR(10) NOT NULL,
Symptom VARCHAR(100),
Diagnosis VARCHAR(100),
DGtime DATETIME,
Rfee DECIMAL(18,2) NOT NULL
};
CREATE TABLE Doctor{
Dno VARCHAR(10),
Dname VARCHAR(50) NOT NULL,
Dsex VARCHAR(2) CHECK( Dsex IN (‘男’, ‘女’)),
Dage INT CHECK( Dage > 0 AND Dage <60),
Ddeptno VARCHAR(10),
Dlevel VARCHAR(50),
Dsalary DECIMAL(18,2),
PRIMARY KEY(Dno),
};
CREATE TABLE RecipeDetail{
Rno VARCHAR(10),
Mno VARCHAR(10) NOT NULL,
Mamount DECIMAL(18,0),
PRIMARY KEY(Rno,Mno),
CHECK (Mno IN (SELECT Mno FROM Medicine))//这是参照完整性约束，允许出现其他关系的子查询
};

以下是断言的格式和一个例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

CREATE ASSERTION fk_Diagnosis
CHECK 
( NOT EXISTS
( SELECT * 
FROM Diagnosis 
WHERE Dno NOT IN
(SELECT Dno
FROM Doctor))); 


CREATE ASSERTION <断言名> CHECK<谓词>
Create assertion salarycheck check(
Not exists(
Select * from Doctor x
Where Dsalary >= some ( select Dsalary from Doctor y 
Where x.Deptno=y.Deptno and y.Dno =(
Select Manager from Dept 
Where x.Deptno =Dept.Deptno)
)
);

参照完整性

概念

给定关系R，S，若存在R.A参照S.B

• R是参照表，S为被参照表
• A取值要么为空，要么来自于S.B
• A为外码
• B是S的主码
  若两张表的属性有参照完整性约束，在创建R表声明

1
2

REDERENCES S(B)
FOREIGN KEY(A) REFERENCES S(B)

可见对R和S的删除，更新，插入都有可能触发完整性违约；

• DELETE FROM S
• UPDETE S.B
• UPDETE R.A
• INSERT TO R

策略

• 受限策略RESTRICTED:系统的默认方式，出现违约时，系统拒绝执行
• 置空策略SET-NULL：根据环境的语义，外码可能为空
• 级联策略CASCADE：不用拒绝用户操作请求的处理方式
• 定义方式ON (DELETE|UPDATE) (SET NULL|CASCADE)

视图

创建视图

特点：

• 虚表，从一个或几个基本表导出的表；
• 只存放视图的定义，不会出现数据冗余
• 基表中数据发生变化，从视图查询出数据也随之改变
• 视图建立后，用户可以像基表一样对视图查询

优点：

• 限制用户直接存取基表的某些列或记录，从而为基表带来附加的安全性；
• 视图可定义在多个基表上或其他视图上，通过视图可得到多个表经计算后的数据，从而隐藏数据的复杂性；

作用：

• 视图能够简化用户的操作：当视图中数据不是直接来自基本表时，定义视图能够简化用户的操作
  • 基于多张表连接形成的视图
  • 基于复杂嵌套查询的视图
  • 含导出属性的视图
• 视图使用户能以多种角度看待同一数据：视图机制能使不同用户以不同方式看待同一数据，适应数据库共享的需要
• 视图能够对机密数据提供安全保护
  • 对不同用户定义不同视图，使每个用户只能看到他有权看到的数据
  • 通过WITH CHECK OPTION对关键数据定义操作时间限制
• 利用视图可以清晰地表达查询：复杂查询分步实现；

创建视图

1

CREATE VIEW <视图名> [列名1，…] AS <子查询>

• 省略列名时，则由子查询中SELECT目标列中的诸字段组成
• 明确指定视图的所有列名:
• DBMS执行CREATE VIEW语句时只是把视图的定义存入数据字典，并不执行其中的SELECT语句。
• 在对视图查询时，按视图的定义从基本表中将数据查出。
• 子查询可以是任意复杂的SELECT语句，但通常不允许含有ORDER BY子句和DISTINCT短语

删除视图

语法：

1

DROP VIEW <视图表>

更新视图

由于视图是不存储数据的虚表，数据是来自其他基表部分数据，对视图的更新最终是对基表的更新。

• 对于直接CURD生成的基表，其视图只读；
• 对于采取统计查询/聚集查询的基表，其视图可删除，不可修改；
• 对于采取表达式计算的列，其更新不允许；

索引

概念

类似于词典的索引,索引是关于数据位置信息的关键字表。

• 数据库中的索引是一个表中所包含的值的列表，其中注明了表中包含各个值的记录所在的存储位置。
• 可以为表中的单列或多列创建索引;
• 索引通常采用采用B树，B+树或哈希表等结构。
• 数据库系统检索数据时，根据索引提供的信息，可以直接找到与该条件临近的数据区，而不是一条一条记录地比较，因此可提高查询速度；

使用索引

• 建立索引是加快查询速度的有效手段
• 索引由DBMS内部实现，属于内模式范畴
• 建立索引：DBA或表的属主根据需要建立，有些DBMS自动建立以下列上的索引: PRIMARY KEY和 UNIQUE
• 维护索引：DBMS自动完成
• 使用索引：DBMS自动选择是否使用索引以及使用哪些索引

聚簇索引

建立聚簇索引后，基表中数据也需要按指定的聚簇属性值的升序或降序存放。

• 在一个基本表上最多只能建立一个聚簇索引
• 用途：对于某些类型(范围查找)的查询，可以提高查询效率
• 适用范围：很少对基表进行增删操作，很少对其中的变长列进行修改操作
  语法：

1

CREATE CLUSTERED INDEX Stusname ON Student(Sname);

非聚簇索引

• 数据存储在一个地方，索引存储在另一个地方，索引带有指针指向数据的存储位置;
• 索引中的项目按索引键值的顺序存储，而表中的信息按另一种顺序存储（也可以由聚簇索引规定）。
• 在搜索数据值时，先对非聚集索引进行搜索，找到数据值在表中的位置，然后从该位置直接检索数据。
• 由于索引包含描述查询所搜索的数据值在表中的精确位置的条目，这使非聚集索引成为精确匹配查询的最佳方法。
• 关键字为NONCLUSTERED

单列索引

• 普通索引：允许在定义索引的列中插入重复值和空值；
• 唯一值索引：唯一索引确保索引列不包含重复值，在多列唯一索引的情况下，该索引可以确保索引列中每个值组合是唯一的
• 主键索引：不允许为空的唯一索引；

组合索引

在表中的多个字段组合上创建索引；

1

CREATE [UNIQUE][CLUSTERED / NONCLUSTERED] INDEX <索引名> ON <表名> (列名1);

删除索引

删除索引语法：DROP INDEX <索引名>
删除索引实例:DROP INDEX <索引名>

索引的原则

• 选择数据量较大的表建立索引
• 选择列中的数据多而杂的列建立索引
• 建立索引的数量要适量
  • 索引要占用磁盘空间
  • 维护索引结构系统要花费一定的开销
  • 仅用来查询的表来讲课建立多个索引，对更新操作比较频繁的表少建立索引
• 优先考虑主键列建立索引
• 选择合适的时机建立索引
  • 建立索引应选择在表中装入数据之后
  • 如果要保证装入数据的唯一性，在装入数据前建立唯一性索引

数据库管理技术

问题和挑战

数据库管理技术研究研究如何对数据进行科学管理，从而为人们提供可共享的、安全的、可靠的数据；

数据库管理技术可能面临的挑战：垃圾信息，数据类型多样化和一体化，数据库安全……

发展阶段：人工管理$\to$文件系统$\to$数据库系统$\to$关系数据库$\to$非关系型数据库（NoSQL，Not Only SQL）$\to$​​分布式关系数据库(new SQL)；

发展历程

人工管理

计算机主要用于科学计算，软件只有汇编语言，尚无数据管理方面的软件，数据处理方式基本是批处理，比较原始；

• 计算机系统不提供对用户数据的管理功能。
• 数据不能共享。
• 不单独保存数据;

文件系统

计算机不仅用于科学计算，还利用在信息管理方面，软件领域出现了操作系统和高级软件

• 数据以文件形式保存
• 程序与数据之间具有“设备独立性”
• 数据冗余、不一致、数据联系弱

数据库系统

• 数据结构面向全组织
• 数据冗余小，易扩充
• 数据独立于程序
• 统一的数据管理功能，包括数据的安全性控制、数据的完整性控制及并发控制

网状数据库

最早的网状数据库管理系统 IDS；
数据库标准的制定DBTG，首次提出了数据库三层体系结构；

层次数据库

IBM公司研制成功第一个层次数据库IMS
数据不在存储在文件中，树/图的结构存储数据
程序和数据完全分离

关系数据库

简单统一的数据结构， 描述性的SQL查询语言

关系数据库的不足

• 结构约束严格，不能满足非结构化数据处理的需求
• SQL语言不支持复杂的数据分析

关系数据库内部扩展

1. 对象模型和XML模型
2. 专用系统：One-size-dose-not-fit-all

绪论

数据库是什么

数据库：长期存储在计算机内，有组织，可共享的海量数据集合

数据库相关理论及相关问题：

• 数据模型，规范化理论：如何组织这些数据?
• 数据定义和操作语言；如何存取和操作数据？
• 数据安全：哪些人可以操作这些数据？
• 并发控制：多人如何操作统一数据？
• 数据恢复：出现故障怎么办？
• 数据挖掘：如何分析数据和发现数据价值？

数据库相关人员职责：

1. 数据库开发者
2. 数据库设计者
3. 数据库管理员
4. 数据库实现者

数据概念

数据

数据是一种符号序列，它的内容是事物特性的反映，能被计算机识别，存储；

数据的类型：

• 数字，字母，文字
• 图形， 图像，声音…

信息

信息是经过加工处理的数据，是数据的具体含义；

数据和信息的联系：

1. 数据是信息的载体，数据是信息的外延；
2. 信息是数据的具体含义，信息是数据的内含；
3. 信息是抽象的，不随数据形式而变化；
4. 信息对应的数据表现形式具有可选择性；

知识

知识是有用的信息；

知识获取的过程既是从大量、已知信息出发、根据事物之间的固有联系和规律，提出有价值、有意义的信息

数据库概念

数据库DB

数据库是长期储存在计算机内、有组织的、可共享的大量数据集合。

• 按一定的数据模型组织，描述和存储；
• 可为各种用户共享；
• 冗余度小；
• 数据独立性高；
• 易拓展；

数据库管理系统DBMS

定义：一个能让用户定义，创建和维护数据库以及控制对数据库访问的软件系统；

功能

1. 数据库定义DDL：对各级数据库模式进行精确定义（create, alter, drop），包括创建模式，数据库，表，视图；

2. 数据操纵DML：对数据库中的数据进行处理(select, insert, update, delete)，包括增加、删除、修改、查询；

3. 数据库运行控制DCL：数据库恢复，数据库并发控制，数据完整性控制，数据安全性控制(grant, revoke)

4. 数据库的维护功能：

   • 初始数据的载入；
   • 数据库的转储；
   • 数据库性质监视，分析功能；

5. 数据字典DD：存放数据库的三级模式的描述

数据库系统

定义：引入数据库后的计算机系统；

• 硬件
• 软件（数据库，数据库管理系统和相关软件）
• 用户（数据库管理员，数据库开发者， 最终用户）

一般认为DBS包含DB，DBMS，但是DB和DBMS没有包含关系；