数据库建表范式与反范式

范式：为了建立冗余较小，结构合理的数据库，设计数据库需要遵循的规则。

• 第一范式（确保每列保持原子性）

第一范式是最基本的范式，如果数据库中所有字段都是不可分解的原子值，说明满足第一范式。第一范式的合理遵循需要根据系统的实际需求来定。比如数据库经常用到的“地址”属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统需要访问属性中的“城市”部分，那么就需要将“地址”这个属性拆分为省、市、具体地址等多个部分进行存储。

• 第二范式（确保表中的每列都与主键相关）

首先满足第一范式，另外还需包含两部分内容：一：表必须有一个主键；二：没有包含在主键的列必须完全依赖于主键，而不能只依赖于主键的一部分。也就是说一个数据表中一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

如：订单信息表

订单编号	商品编号	商品名称	数量	单位	价格	客户	所属单位
001	1	产品一	1	个	100	张	xx
001	2	产品二	2	个	200	张	xx
002	3	产品三	1	个	50	李	xx

上述表中，以订单编号和商品编号作为联合主键，则这张表中商品名称、单位、价格等信息不与主键相关，只与编号相关，违反了第二范式 应该对订单信息表进行拆分，商品信息单独一张表，订单项目一张表，如下所示

订单信息表

订单编号	客户	所属单位
001	张	xx
002	李	xx

订单详情表

订单编号	商品编号	数量
001	1	1
001	2	2
002	3	1

商品信息表

商品编号	商品名称	单位	价格
1	产品一	个	100
2	产品二	个	200
3	产品三	个	50

• 第三范式（确保每列都和主键列直接相关，而不是间接相关）

概念说起来比较绕口，直接举例子说明：存在一个部门信息表，每个部门都有dep_id,dep_name,dep_des等信息。那么在员工表中列出dep_id后，dep_name,dep_des等信息就不能再加入员工信息表中。如果不存在部门信息表，则根据第三范式也应该构建，否则会有大量的数据冗余。

范式的优点：范式避免了数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦； 范式的缺点：范式往往需要进行多表连接，当数据量很大时，效率比较低

有范式，自然就有反范式，不满足范式的模型，就是反范式模型。当业务涉及的表非常多时，经常会有多表发生关系，并且对表的操作要时间上尽量的快，这时可以考虑使用反范式。但是反范式，对于更新数据来说，比较麻烦，容易出错。而且反范式会有很多的重复数据，或占用较多的内存，查询时可能会较多的使用group by或distinct等耗时耗性能的关键字。

终于把范式整理完了，开发了这么多年，范式的概念还是在大学中学到，但那时理解不深刻，早已把概念忘的一干二净。实际项目中，做db设计并没有强调说一定要遵循范式，都是根据业务混合使用不同的模式，将各种模式的优点最大的发挥

转载于:https://my.oschina.net/wuyiyi/blog/3042902