再谈三范式

以前写过一篇关于数据库设计三范式的文章，当时只是从网上查了一些资料和例子根据 自己的理解写的。昨天晚上7期的师姐给我们具体地讲了数据库设计的三范式，感觉我的理解又加深的一步。

先谈一下数据库中的“键”

超键：在关系中能唯一标识元组的属性集称为关系模式的超键。一个属性可以为作为一个超键，多个属性组合在一起也可以作为一个超键。

候选键：包含属性最少的超键

主键：任意一个候选键

外键： 如果公共关键字在一个关系中是主关键字，那么这个公共关键字被称为另一个关系的外键。外键其实表示的是表和表之间的一种依赖关系，通过外键约束可以保证数据的一致性

其实最终落实到数据库表可见的只有主键，其他的如超键和候选键都是为了确定一个主键

因为三范式和主键、外键是分不开的，所以以上先介绍一下“键”

下面重谈三范式

第一范式：保证表中的每项数据的原子性（即不可分割）

如下图所示

卡号	上机时间	下机时间
１２３４５６７８９０	２０１２－３－４　　１９：３０	２０１２－３－４　　２０：００

上表中上机时间字段和下机时间字段，如果对于日期和时间都是单独存取的，那么就有必要把他们分开作为两个字段，

卡号	上机日期	上机时间	下机日期	下机时间
１２３４５６７８９０	２０１２－３－４	１９：３０	２０１２－３－４	２０：００

假如日期和时间总是放在一起存储取，我觉得就没有把他们分开，其实原子性性是和具体的项目需求有关系的

第二范式：消除部分依赖，保证完全依赖（主要是针对复合主键而言）

如果数据表中的某个字段只依赖于复合主键的某一部分，而不是整个主键，那么这种依赖就称为部分依赖

第三范式：消除传递依赖（间接依赖）保证直接依赖

如果数据表中的主键推出了字段A，而且字段A又能推出字段B，那么这种依赖关系就属于传递依赖

数据库之所以要按照三范式去设计，目的就是要消除数据的冗余，数据的冗余会带来很多害处，如：数据的增删改不能保证数据的一致性

但是完全按照三范式设计的数据库不一定是好的数据库，有时候为了提高效率是需要适当的数据冗余的

总之一句话“权衡利弊看得失”，数据库具体怎样设计还要看具体的项目需求，既要考虑降低数据冗余带来的害处，又要考虑效率的问题。