2.数据库范式

1. 第一范式（1NF）：属性不可分

1.1 第一范式的定义为：符合1NF的关系中的每个属性都不可再分

1NF 告诉我们字段属性需要是原子性的

例子:

如上图所示的情况，就不符合1NF的要求。

实际上，1NF是所有关系型数据库的最基本要求，只要在RDBMS中已经存在的数据表，一定是符合1NF的。如果我们要在RDBMS中表现表中的数据，

就得设计为如下图的形式：

1.2 第一范式产生的问题

1. 数据冗余过大
2. 插入异常
3. 删除异常
4. 修改异常。

2.第二范式（2NF）：符合1NF，并且非主属性完全依赖于主码。

2NF 告诉我们一张表就是一个独立的对象，一张表只表达一个意思。

举例：

定义了一个名为 Orders 的关系，表示订单和订单行的信息：

违反了第二范式，因为有非主键属性仅依赖于候选键（或主键）的一部分。例如，可以仅通过orderid找到订单的 orderdate，以及 customerid 和 companyname，而没有必要再去使用productid。

修改：

3. 第三范式（3NF）：符合2NF，并且非主键外的所有字段必须互不依赖。

举例：定义了一个名为 Orders 的关系，表示订单和订单行的信息：

此时的Orders关系包含 orderid、orderdate、customerid 和 companyname 属性，主键定义为 orderid。customerid 和companyname均依赖于主键——orderid。

例如，你需要通过orderid主键来查找代表订单中客户的customerid，同样，你需要通过 orderid 主键查找订单中客户的公司名称（companyname）。然而， customerid和companyname也是互相依靠的。为满足第三范式，可以改写如下：

3.4 小结：

关于数据表的设计，有三个范式要遵循。

(1)第一范式(1NF) ，确保每列保持原子性，数据库的每一列都是不可分割的原子数据项，不可再分的最小数据单元,而不能是集合、数组、记录等非原子数据项。

(2) 第二范式(2NF) ，确保每列都和主键完全依赖，尤其在复合主键的情况下，非主键部分不应该依赖于部分主键。

(3)第三范式(3NF) 确保每列都和主键列直接相关，而不是间接相关

范式的优点:

数据的标准化有助于消除数据库中的数据冗余，第三范式(3NF) 通常被认为在性能、扩展性和数据完整性方面达到了最好的平衡。

范式的缺点:

• 范式的使用，可能降低查询的效率。因为范式等级越高，设计出来的数据表就越多、越精细,数据的冗余度就越低，进行数据查询的时候就可能需要关联多张表，这不但代价昂贵，也可能使一些索引策略无效。
• 范式只是提出了设计的标准，实际上设计数据表时,未必一定要符合这些标准。
• 开发中，我们会出现为了性能和读取效率违反范式化的原则，通过增加少量的冗余或重复的数据来提高数据库的读性能，减少关联查询, join 表的次数,实现空间换取时间的目的。因此在实际的设计过程中要理论结合实际，灵活运用。

4. 反范式化

4.1 规范化 vs 性能

1. 为满足某种商业目标 , 数据库性能比规范化数据库更重要
2. 在数据规范化的同时 , 要综合考虑数据库的性能
3. 通过在给定的表中添加额外的字段，以大量减少需要从中搜索信息所需的时间
4. 通过在给定的表中插入计算列，以方便查询

4.2 反范式的新问题

1. 存储 空间变大了
2. 一个表中字段做了修改，另一个表中冗余的字段也需要做同步修改，否则 数据不一致
3. 若采用存储过程来支持数据的更新、删除等额外操作，如果更新频繁，会非常 消耗系统资源
4. 在 数据量小 的情况下，反范式不能体现性能的优势，可能还会让数据库的设计更加 复杂

4.3 反范式的适用场景

当冗余信息有价值或者能 大幅度提高查询效率 的时候，我们才会采取反范式的优化。