实践千万条，基础第一条——数据库范式

求，否则，将有很多基本操作在这样的关系模式中实现不了。

　　　　第二范式：如果关系模式R满足第一范式，并且R的所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。

　　　　第三范式：如果关系模式R满足第二范式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF。

　　什么，定义太长了，还好下面有一个精简的版本：

　　　　第一范式：表中不能有表，列中不能有列。

　　　　第二范式：满足第一范式的基础上，消除非主属性对主属性的部分依赖。

　　　　第三范式：满足第二范式的基础上，消除非主属性对任一主属性的传递依赖。

　　以下将尝试对上面的释义做一个通俗的解释：

　　第一范式：表中不能有表，列中不能有列。这是对关系数据表的基本要求，同时相信也没有人能够在物理上突破限制，真的在表里建出另一张子表。然而，逻辑上的“列中不能有列”却常常被人忽略。例如，记录用户信息的用户表中有一个字段realname，记录用户姓名，这在中国倒很常见，但若是放眼全球，很多国家以firstname，lastname来标记姓名，仍然坚持以一个字段来记录姓名便会常常出现问题。因此，并不是所有关系表都能轻松达到严格的第一范式哦！

　　第二范式：举个反例，设计一张学分表，包含字段course_id(课程),stu_no(学号)，score(学分)，stu_name(姓名)。相信很多人看到这样的表结构很快就能感受到一股奇怪的力量，没错，就是stu_name乱入了，这张表的主属性是course_id和stu_no，score完全依赖于主属性，而stu_name却只依赖于stu_no不依赖于course_id，这便是部分依赖，因此，将stu_name移出表结构的过程就是消除非主属性对于主属性部分依赖的过程。

　　第三范式：仍然以例为证，设计一张订单表，order_id(订单号)，total_fee(总价)，customer_id(顾客id)，customer_name(顾客姓名)。其中主属性是order_id，其他属性全部依赖于order_id，因此可以认为当前表结构满足第二范式，然而，customer_id依赖于order_id，而customer_name又依赖于customer_id，这便导致了一条传递依赖，不满足第三范式，因此将customer_name移出表结构的过程就是消除非主属性对主属性的传递依赖的过程。

　　Tips：本质上，数据库范式的演变过程就是去除冗余数据的过程，在实践中，了解三大范式对于数据库的设计将会大有裨益，但切记不能钻牛角尖，因为业务场景的复杂度不在数据库范式讨论的范围之内，如果一味强求数据库的设计规范，很容易增加数据库的设计和程序编码的复杂度，因此，适当合理的数据冗余也是可以接受的哦！遗憾的是，“适当合理的数据冗余”并没有量化的概念哦！

实践千万条，基础第一条——数据库范式

标签：一个   col   并且   这就是我   eal   tom   关系型数据库   国家   去除