关系型数据库设计

• 关系模型由关系数据结构、关系操作集合和完整性约束三部分组成！设计关系数据结构需要用到关系模式，关系模式是五元组 R(U, D, DOM，F)，其中 U 是属性名集合，D 是数据域集合，DOM 是属性名到数据域的映射，F 是 U 上面的数据依赖集合，在进行关系模式的设计时往往只需要专注于 R(U, F) 就行了！

R(U, F);
U = {Sno, Sdept, Mname, Cno, Grade};
F = {Sno -> Sdept, Sdept -> Mname, (Sno, Cno) -> Grade};
以上设计模式存在4个显著问题：
1.数据冗余，一个院系(Sdept)只有一个主任(Mname)，但是每个学生记录中都要重复记录院系信息
2.更新异常，如果更换了院系主任，则要更新所有*，容易更新出错导致不一致
3.插入异常，如果没有学生，则也没法保存院系信息
4.删除异常，删除毕业学生信息以后，院系信息也没了
综上所述，这样的设计模式不是好的设计模式，应该改良！那么进入主题 -- 数据库设计范式

• 在讨论范式之前，先说一些概念：

• 函数依赖：在关系模式 R(U)，X和Y是U的子集，对于X上面的值 x ，只要 x 确定了，Y上面的值 y 就唯一确定了，这样子就说 X -> Y，也就是Y函数依赖于X或者X函数确定Y。

• 平凡函数依赖：X -> Y且 Y 真含于 X，则称 X -> Y 是平凡的函数依赖。这是一个必然命题！

• 非平凡函数依赖：X -> Y且 Y 不含于 X，则称 X -> Y 是非平凡的函数依赖。我们说的依赖是这种！

• 完全函数依赖：X -> Y且 X 的真子集不能确定 Y

• 部分函数依赖：X -> Y且存在X的真子集X1 -> Y

• 传递函数依赖：X -> Y，Y不含于X，Y -/-> X，Y -> Z，Z不含于Y，则称 X -传递-> Z

• 规范化（Normalization）：一个低一级范式的关系模式通过模式分解可以转化为若干个高一级范式的关系模式的集合，这个过程叫做规范化。

• 第一范式(1NF)：属性不可分。

• 第二范式（2NF）：关系模式R属于1NF，且每一个非主属性都完全依赖于任何一个候选码。

• 第三范式（3NF）：关系模式R属于1NF，不存在这样的码X，属性组Y和非主属性Z，使得它们之间存在传递函数依赖！

• BCNF：关系模式R属于1NF，若 X -> Y 且 Y 不含于 X 时 X 必包含码，则 R 符合 BCNF。

• 将E-R图转化为关系模式

一、直接将实体型转化为一个关系模式
二、1:1联系可以转化为一个独立的关系模式，也可以在任意一端实体中记录另一端实体的主键ID
三、1:n联系可以转化为一个独立的关系模式，也可以在n端那边的实体中记录1端实体的主键id
四、m:n联系转化为一个独立的关系模式
五、三个或者三个以上的多元联系可以转化为一个关系模式
六、拥有相同码的关系模式可合并

• 数据库并发调度的可串行性：如果一个并发调度的执行结果和任意一个串行调度的执行结果一样，那么这个并发调度可串行化调度。

• 不同事务对同一数据的读写操作和写写操作叫做冲突操作。不同事务的冲突操作和同一事务的两个操作是不能交换顺序的。

• 冲突可串行化调度：在一个调度 sc 中，通过交换不冲突的两个操作，而得到另外一个调度 sc' ，sc'是串行的，那么调度 sc 叫做冲突可串行调度。

• 两段锁协议：数据库系统通过两端锁协议确保每个调度都是可串行化调度，协议内容：事务在扩展阶段只能获取锁不能解锁，在收缩阶段只能释放锁不能获取锁。

• 可串行化调度包含符合两段锁协议的调度+冲突可串行化调度。