关系数据库设计三范式

为了建立冗余小，结构合理的数据库，设计数据库时必须遵循一定的规则，在关系数据库中这种规则叫做范式。

范式是符合某种设计要求的总结。

要设计一个结构合理的数据表，那么就必须满足一定的设计范式。

1、第一范式：确保每列都是原子的

按照业务场景的需求，确保每列都是不可再拆分的，原子列。

比如，数据表中有“地址”列，而该列在实际应用中，需要展示省份、城市等明细，那么我们在设计数据表时，就不能用一个大的“地址列”来充当，而是应该将“地址”列，拆分成“省份”、“城市”等原子列，这样才能满足需求。

这样也就满足了数据库设计的第一范式，可见，满足第一范式的数据表，确实更合理。

满足第一范式，可以提高数据库操作的效率。

2、第二范式：确保每列都和主键相关

第二范式是在第一范式的基础上更进了一层，即：确保每列都要和主键相关，而不是和部分主键相关（复合主键的情况）。

比如：我们有一个订单表，那么订单表中的非主键列，一定是和订单编号相关的。如果将用户信息都放入订单表，那么这样的设计就很糟糕。

满足第二范式，可以减少数据表无用的冗余，避免存储浪费，同时可以确保数据表关系脉络更加清晰。

3、第三范式，确保每列都和主键直接相关而非间接相关

第三范式是在第二范式的基础上更进了一层，其要求每列都和主键直接相关，而非间接相关。

比如：订单表中有：订单号（主键）、价格、购买人、购买人性别。我们分析可得：订单号和购买人ID相关，而购买人的性别和订单号没有直接关系，其关系是：订单号-》购买人-》购买人性别，这样的设计就不满足第三范式，我们需要将购买人性别放入用户表，然后通过购买人做关联。

满足第三范式，可以减少数据表的字段冗余。

总结：

一般情况下，OLTP类的系统，数据库设计还是尽量满足数据库设计范式，这样可以提高交易处理效率。

但是对于OLAP类的系统，或者数据分析类场景比较多的系统，在数据库设计时，往往无需完全遵循数据库设计范式，而是使用宽表（增加冗余）来满足查询分析。