[TOC]
埃德加·弗兰克·科德（Edgar Frank Codd E.F Codd， 1923年8月23日－2003年4月18日）
范式的作用：解决如何建表，建几张表的问题。
一个好的设计模式，应该不会发生插入异常/删除异常/更新异常，数据冗余也应该尽可能的少。
关系模式三元组：$R<U, F>$ U: 属性组，属性集合，F: U 上的函数依赖
- 学号 —> 姓名，姓名依赖于学号，姓名也完全取决于学号，所以姓名完全函数依赖于学号。姓名 = f(学号)
- (学号，性别) —> 姓名，姓名依赖于(学号，性别) ，但是姓名并不是完全依赖于学号与性别，姓名只是对学号和性别部分函数依赖
- X —> Y Y —> Z : X —> Z，Z 对 X 传递函数依赖
一组能唯一确定一条元组的属性集合。如果候选码不止一个，那么则选定其中的一个为主码（Primary Key）。
主码中的属性称为主属性。
如果一个属性或者属性组 X 并非 关系模式R 的码，但 X 是另一个关系模式（一张表就是一个关系模式）的码，那么则称 X 是 R 的外码（外键）。
- 数据冗余（系主任存储冗余）
- 更新异常（数据冗余导致更新表的时候带来债务，例如更换系主任时，必须修改每一条学生数据）
- 插入异常（如果一个系刚成立，没有学生，就无法将该系及其系主任的信息存入数据库）
- 删除异常（删除学生的时候，会把系和系主任也删除了）
范式就是关系型数据库的规范化。
范式：符合某一种级别的关系模式的集合。
第一范式：每一个属性都是不可分的数据项。
第二范式：若 R 属于 1NF，且每一个非主属性完全函数依赖于码，则 R 属于 2NF。一个关系模式（表）不属于 2NF，会产生 插入异常，修改异常，删除异常等问题。
第三范式：每一个非主属性，既不部分依赖于码，也不传递依赖于码。图6.5的关系模式，由于存在传递函数依赖，所以需要将其拆开。
注意：并不是规范化程度越高，关系就越优，当查询设计到多表查询时，连接运算会导致查询效率降低。有时候，第二范式，甚至第一范式，是比较折中的选择
Transaction：用户定义的一个数据库操作脚本，这些操作要么全做要么全不做，是一个原子操作。在关系型数据库中，一个事务可以是一条 SQL语句或一个存储过程。
Transaction 举例：从账户 A 中取出一万元，存入账户 B。需要定义一个 transaction，包含两个操作，从 A 中减去一万元，然后想 B 中加入一万元。
Transaction 的三个命令
- begin transaction
- commit：提交事务的所有操作，将事务中所有对数据库的更新写入磁盘，事务正常结束
- rollback：撤销事务的执行，回滚到初始状态
Transaction 的四大特性：ACID
- 原子性（Atomicity）
- 一致性（Consistency）：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态
- 隔离性（Isolation）：一个事务的隔离并不会被其他事务干扰
- 持续性（Durability）：transaction 一旦提交，其改变就应该是持久性的
多个事务交叉运行，需要数据库管理系统拥有并发控制机制，一个事务被迫中断，则需要 DBMS 拥有中断恢复机制。
事务意外中断在所难免，那么如何进行现场的恢复？
恢复的原理：冗余。（数据备份和日志）
MySQL 数据实时同步到 Elasticsearch 的技术方案选型和思考（外键）
规范化：关系型数据库中通过一系列数据库范式来减少数据冗余、增强数据一致性的策略。
规范化的特征：符合第二或第三范式，窄表，关系表
规范化的问题：涉及多表的复杂查询，要么多次查询数据库，要么连接查询
去规范化的措施：宽表，视图(其实也是宽表)，数据迁移(宽表)
数据库操作分为两种：
-
OLTP online transaction processing
线上请求。
OLTP 是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。传统的INSERT、Update、DELETE等都属于OLTP，主要是涉及事务处理。
-
OLAP online analytical processing
后台分析。
OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。SELECT中的count(*)、MAX()、MIN()、Group By、Order By等函数都属于OLAP的范畴。
-
Hybrid Transactional/Analytical Processing
OLTP + OLAP
MPP：massive parallel processing 大规模并行计算