DB Chapter 9:Normalization

introduction to normalization

ER,Normalization都是设计数据库（生成表结构的）的方法
自顶向下：ER方法
自底向上：从属性玩起-->组成哪些实体
两者在现实生活中相辅相成

1NF,2NF,3NF,BCNF都是基于函数依赖产生的
nf--范式

数据冗余

不好的数据库模式存在数据冗余 =导致=>

• 插入异常:一个依赖于其他存在，当其他不存在，它没法被表达
• 更新异常:一个更新，到处得改
• 删除异常:一个依赖于其他存在，当其他被删除，则把它的信息也删了

数据冗余ppt

存在数据冗余的数据库模式是不规范的，如何将它规范呢？ 规范化为了解决数据冗余及其导致的问题

函数依赖

函数依赖定义

两组属性A,B，B依赖于A，当且仅当，A相同的时候,B肯定相同这个事实存在。

学号和姓名是两个属性，在北邮范围内，当学号相同的情况下，姓名肯定相同 ==> 姓名函数依赖于学号，学号函数决定姓名。  

函数依赖的特点

• 一直存在，不是瞬时的
• 一对一表达
• 是非频繁的 （学号函数决定学号，就是频繁的）

基本依赖

基本依赖-fd 语义和企业规则-->若干依赖的集成 -就是- 基本依赖

逻辑蕴含

建立在基本依赖的基础上，运用一系列阿式公理，进行一系列依赖的推广

闭包

建立在基本依赖的基础上，运用一系列阿式公理，进行所有可能的依赖的推广，这个全体的集合叫做闭包

求出来干什么

输入基本依赖 --> 生成闭包 --> 生成主键 --> 按照范式进行切分 --> 生成表结构

范式

1nf

unf 不规范的范式 交点不止一个 1nf ....交点只有一个

2nf

完全/部分函数依赖

a,b两组属性。a决定b，b依赖于a，若a的任何真子集都不能决定b的话，则称b是完全依赖于b的。若某个真子集就能决定b，则称b是部分函数依赖于b的。

2nf定义

在1nf的基础上，每一个非主属性都是完全函数依赖于主键的

将非2nf转化为2nf <=== 依赖保留，无损连接分解：

• 分解不能丢了原来的依赖
• 分解完了可以通过join回来

3nf

传递依赖

a决定b，b决定c ===> a决定c，c传递依赖于a

3nf定义

在一个数据库模式下，所有表下的非主属性都是完全依赖于主键，且是非传递依赖于主键的话，则属于3nf

--消除了数据项可再分-> 1nf -消除部分依赖---> 2nf ---消除了传递依赖-> 3nf === 没有冗余了

一般是基于3nf设计数据库的，可为什么工业中不达3nf的情况也很常见？

join很费劲，用冗余 换 性能

广义 --> 将范式中的主键换为候选键，要求更高了

BCnf不讲 不考