数据库原理笔记

一、数据库设计初步

第一章 数据库设计目标

确定数据库应该满足的特性，例如：

• 具有良好的结构（可读性、可维护性）
• 数据完整性（避免数据就丢失）
• 计划查询

第二章 设计方法

• 需求分析—收集数据性质、特别需求（字段约束）
• 概念设计—绘制ERD（实体关系图），包括表、字段、表之间的关系，以及规范化
• 逻辑设计—创建数据库语言命令、生成表定义，有些ERD工具支持自动生成数据定义语言（DDL）
• 物理设计—根据底层物理属性修改数据库模型
• 调整阶段—建立索引、规范化、反规范化、安全特性

第三章 数据库建模构件块

信息、数据、数据完整性。

1. 数据完整性，即数据有效性、影响因素有：

• 认为数据项操作错误
• 网络传输错误
• 软件病毒、硬件故障
• 自然灾害

2. 保护数据完整性

• 数据库备份（规律性）
• 计算机安全
• 通过适当界面约束数据操作

表的概念

1. 纪录=元组=行
2. 字段=列=属性

数据类型

简单数据类型：

1. 字符串

• 定长：用于较短字符串，字符不足时自动前面补充空格
• 变长：可设置最大字符数。VARCHAR(500)

2. 整型
3. 定长小数：可指定小数位数
4. 浮点型：检索效率低
5. 日期和时间
   除简单数据类型外，还有复杂数据类型和专门数据类型

约束和有效性

1. NOT NULL
2. 有效性检查：通过脚本、函数约束具体允许的值，例如只允许插入‘M’、‘W’。
3. 键约束：包括主键、外键、唯一键。键约束允许检查验证不同表中字段之间的值。主键和外键本质是实现父子表。

规范化（最小化冗余）

1. 优点

• 减少物理存储需求
• 数据组织更好
• 更新数据时只需要操作少量数据（数据独立性）

2. 过度使用缺点

• 过多最小化冗余按时更多数据表，查询时需要较大SQL连接语句
• 可能是数据库结构更复杂

数据表关系

1. 鸟足结构
2. 一对一、一对多、多对多
3. 零、一或多
4. 标识和非标识关系（字表主键是否包括父表主键）

键

1. 主键：唯一标识（用于唯一锁定一条记录）
2. 唯一键：唯一标识（避免出现相同纪录值，如同一个乐队不能有两首同名歌曲，需要将其设置为唯一键）
3. 外键：反向引用父表中的主键，设置外键属性会自动检查父表主键（完整性约束

参照完整性

定义： 确保相关表中的主键值和外键值之间关系的完整性

索引

二、关系数据库模型设计

第四章 规范化

规范化定义

1. 异常：主表与明细表之间的矛盾。考虑插入异常、删除异常、更新异常
2. 依赖（传递依赖、完全函数依赖、多值依赖、循环依赖）、决定因子、候选键（除主键外可以唯一确定纪录的组合字段，可代替主键）

定义范式（共六个，一般需要满足第三范式）

1. 第一范式：在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。

   • 消除重复组
   • 定义主键
   • 使用主键唯一标识所有记录，主键不可重复
   • 其他字段必须直接或间接依赖主键
   • 所有字段至少包含一个值
   • 每个字段为相同数据类型
   • 创建新表，从原始表中移动重复组

2. 第二范式：要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。

3. 第三范式：在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）
   第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性，也就是在满足2NF的基础上，任何非主属性不得传递依赖于主属性。
4. BCNF范式： 消除主属性对主码的传递依赖（3NF是针对非主属性）。这是为了避免一个元组中部分空值引起的信息丢失或异常。

三、数据库原理

3.1 查询优化

1. 语义优化
   程序员或者DBMS自动的优化SQL语句中低效或冗余
2. 语法优化
   利用语法等价性（关系代数），尽可能早做选择、早做投影运算
3. 物理优化
   为每一个关系代数操作，通过代价估算，选择最优的物理查询执行程序。代价估算方式如下：
   
   这些代价，需要数据库管理员（DBA）使用特定的统计指令来定期统计表中的数据信息，例如数据表大小，磁盘快数，索引大小，数据值范围等。例如IBM DB2收集SCT.Students表的信息的指令为Runstats on SCT.Students。
   • 代价估算：
     

四、并发控制

4.1. 为什么需要并发控制？

4.1.1 ACID原则

• A原子性：DBMS保证一个事务内的多个操作不可分割，即要么全部执行，要么都不执行，不能只执行一部分操作
• C一致性：DBMS保证多个事务并发不能出现数据的三种不一致(丢失修改、重复度错误、脏读)
• I隔离性：DBMS保证多个事务之间执行互相不影响，即使并发执行，也相当与分别先后执行多个事务。
• D持久性：DBMS保证已经提交的事务的影响是持久的，被撤销的事务的影响是可以恢复的。
• 丢失修改：两个事务同时update, 内存与磁盘同步时丢失。
• 不能重复度
• 脏读 ： 某个事务执行update后又回滚，导致其他事务读到脏数据。

4.2. 事务调度可串行性

4.2.1 可串行化

• 串行调度： 多个事务先后依次执行

• 并发调度： 多个事务内的操作交替执行
  +**并发调度正确定：**在给定初始数据库的情况下，一个并发调度得到的新数据库与分别串行执行这些事务结果一致。

• 可串行性： 对于一个调度，不管数据库初始状态如何，始终与某个串行调度的结果相同。

• 冲突可串行性： 对于一个调度，可以通过无冲突的交换操作次序，使其等价于一个串行调度。

• 冲突： 改变操作次序可能会导致结果改变
  

• 并发调度正确性： 某个调度得到的新数据库与分别串行执行这些事务得到的数据库完全一致，就是正确的。

• 冲突可串行性 $\subseteq$ 可串行性 $\subseteq$ 并发调度正确性

4.2.2 冲突可串行性判别算法

对于一个调度：

1. 构造一个前驱图
2. 结点是每个事务$T_i$，如果$T_i$与$T_j$的某一个操作发生了冲突，且$T_i$在$T_j$前执行，则画一条从$T_i$指向$T_j$的边。
3. 如果没有环，表示冲突可串行化
   

4.3. 并发控制方法

4.3.1. 基于封锁的并发控制方法

锁的作用：提供事务并发的控制手段，需要根据封锁协议才能保证事务调度的正确性。

• 锁类型：
  • 排他锁
  • 共享锁
  • 更新锁
  • 增量锁
• 封锁相容性矩阵
  
• 加解锁时机
  
• 如何产生一个正确的并发调度？
  • 两段封锁协议(2PL)：每个事务中分为加锁段、解锁段两个阶段，加锁段中不能出现解锁操作。

2. 基于时间戳的并发控制方法
3. 基于有效性确认的并发控制方法

五、物理存储

Oracle的物理存储架构如下图