数据库范式和规范化

范式

• 第一范式（1NF）：要求属性值不可再分，即属性项不能由属性组合组成
• 第二范式（2NF）：引入主键，如果关系模式R为第一范式，并且R中每一个非主属性完全函数依赖于R的某个候选键，则R为第二范式模式。（主属性与非主属性：如果A是关系模式R的候选码的一个属性，则称A是R的主属性，否则称A是R的非主属性）（函数Y=f(X),则X决定Y，Y依赖于X，记作X->Y）
• 第三范式（3NF）：如果关系模式R为第二范式，并且每个非主属性都不传递依赖于R的候选键，则R为第三范式模式。部分依赖属于传递依赖，原因是候选码 ->候选码真子集->非主属性，如例1中，（学生号，课程号）->学生号->姓名。所以3NF比2NF规定更多，更高要求。
• BC范式（BCNF）：如果关系模式R为第一范式，并且每个非主属性都不传递依赖于R的候选键，则R为BCNF模式。

例1：判断2NF。

FD={学生号->姓名，学生号->性别，学生号->专业，课程号->课程名，课程号->课程学分，（学生号，课程号）->成绩}

第一步，寻找候选码——1。那些没有决定因素的属性（所以，学生号和课程号必包含在候选码中）；2。候选码能够决定其他所有属性（所以，{学生号，课程号}是一个候选码，且是唯一的候选码。

第二部，寻找部分依赖。姓名、性别、专业部分依赖于学生号，课程名、课程学分部分依赖于课程号，所以存在部分依赖。不是2NF。

*有一种情况必定是2NF——单属性候选码。

2NF消除方法：对每一个部分依赖建一张表。

S=(学生号，姓名，性别，专业）

C=（课程号，课程名，课程学分）

SC=（学生号，课程号，成绩）

 

例2：判断3NF。

FD={学号->姓名，学号->性别，学号->籍贯，学号->系号，系号->系名，系号->系电话，学号->宿舍号，宿舍号->宿舍电话}

因为候选码学号是单属性，必定不存在部分依赖，所以是2NF。但学号对系号所推出的系名，系电话，以及宿舍号所推出的宿舍电话都是传递依赖。所以不是3NF。

3NF消除方法：主码不动，把有直接函数依赖关系的非主码（系号，宿舍号）分解出去。

 

Normalization and Denormalization （标准化和非标准化）

这是两种设计数据库表的模式，Normalization对应的数据属于干净非冗余型，而Denormalization则允许数据冗余或者同样的数据存储于多处。下面主要列出了Normalization的优点和缺点，

优点：1、数据更新更迅速；

           2、数据存储空见通常更小；

           3、在查询时减少了distinct和group by的使用

缺点：1、查询时可能需要设计多个表，增加了join的使用；

           2、一些并要的值需要在每次查询时计算（比如各种率值）

综合以上的优缺点，Normalization模式比较适合的场合是更新操作比较频繁的应用，即write-heavy。

同样的Denormalization则适合于read-heavy。

 

关于属性

• 超键(super key):在关系中能唯一标识元组的属性集称为关系模式的超键。例如，在一个学生的表中，假设有“学号”、“姓名”、“相关信息”、“生日”等字段， 其中学号是唯一的，那么（学号）是一个超键，同时（学号，姓名，生日）的组合也是唯一的，所以也可以为一个超键。
• 候选键(candidate key):不含有多余属性的超键称为候选键
• 主键(primary key):用户选作元组标识的一个候选键称为主键