三范式：数据库设计的重要原则 (数据库设计的三范式)

在数据库设计中，三范式是一项非常重要的原则。通过遵循这一原则，可以保证数据库的数据结构适当、高效，不仅能够提高数据查询的速度和准确性，还能够避免数据冗余和不一致。那么，什么是三范式呢？如何遵循三范式进行数据库设计呢？

什么是三范式？

三范式（3NF，Third Normal Form）是指在数据库设计中，一个关系型数据库表（即一个二维表格）必须满足以下三个条件：

1. 每个表列必须是一个原子值（即不可再分解的值）。

这意味着，应该将一个复杂的值分解为多个原子值，并将它们存储在不同的列中。例如，如果你想要存储一个人的地址，应该将地址信息分解为国家、省份、城市和街道等不同的列，而不是将整个地址存储在一个列中。

2. 表中的每个非主键列必须完全依赖于主键。

这意味着，如果一个表中有多个列与主键相关联，那么这些列之间必须满足互相独立、没有重叠，每个列只依赖于主键这个条件。如果一个列依赖于另一个列，则需要将其作为一个新的表存储，并将两个表之间建立关联。

3. 表中不能存在传递依赖。

这意味着，如果一个列依赖于非主键列，那么这个非主键列必须成为主键，或者与其它列一起作为新的表存储。例如，如果一个表中有一个列包含订单日期和订单时间，那么应该将这两个信息分解为两个不同的列，并将它们分别与订单编号建立关联。

为什么需要遵循三范式？

遵循三范式有以下几个好处：

1. 降低数据冗余和不一致

遵循三范式可以避免数据冗余和不一致，即同样的数据不会存储在多个地方，也不会受到多个操作的不同处理，从而保证了数据的一致性和完整性。

2. 提高数据查询的效率

遵循三范式可以使数据结构变得更加高效，查询数据的速度也会更快。因为数据结构简单，关联关系也更加清晰，查询数据时只需要关注主键等关键信息即可。

3. 容易维护和扩展

遵循三范式可以使数据库结构变得更加容易维护和扩展。由于每个表只存储了特定的信息，数据结构也更加清晰，可以降低修改和维护的成本。

如何遵循三范式进行数据库设计？

在进行数据库设计时，遵循三范式需要注意以下几个方面：

1. 确定实体和关系

在设计数据库时首先需要确定实体和关系。一个实体可以是一个物体、一个概念或一个事件，其属性用于描述该实体的特征。关系是不同实体之间的联系，可以是一对一、一对多或多对多的关系。

2. 识别主键

主键是用于唯一标识表中每个行的列。一般情况下，主键是一个自增数字，也可以是一个字符串或一个组合键。在确定主键时需要确保其唯一性和不可更改性，以确保数据的一致性和完整性。

3. 分解表和建立关系

通过将表分解为多个较小的表，并建立它们之间的关系，可以满足三范式的要求。在分解表时需要确保每个表只存储与该表名称相关的信息，并尽量减少数据冗余。在建立关系时需要考虑不同实体之间的关系，以确保数据的正确性和一致性。

4. 优化查询效率

为了提高数据查询的效率，需要对数据库进行优化。这包括使用索引、合理设计查询语句等方法。同时，可以使用数据仓库等技术来优化大数据的处理和查询效率。

三范式是数据库设计中非常重要的原则，通过遵循这一原则可以保证数据库的数据结构适当、高效，避免数据冗余和不一致，提高数据查询的速度和准确性，降低修改和维护的成本。在进行数据库设计时，需要注意确定实体和关系、识别主键、分解表和建立关系、优化查询效率等方面，以确保数据的正确性和高效性。

相关问题拓展阅读：

• 关于数据库三大设计范式浅析

关于数据库三大设计范式浅析

为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。

真斗扒拆正要明白”范式（NF）”是什么意思，首先看下教材中的定义，范式是“符合某一种级别的关系模式的，表示一个关系内部各属性之间的联系的合理化程度”。实际上可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。就像家里装修买建材，最环保的是E0级，其次是E1级，还有E2级等等。数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。一般在我们设计关系型数据库的时候，最多考虑到BCNF就够。符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。

在实际开发中最为常见的设计范式有三个：

首先是之一范式（1NF）。

符合1NF的关系（你可以理解为数据表。“关系”和“关系模式”的区别，类似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例，你可以把”关系”理解为此和一张带数据的表，而“关系模式”是这张数据表的表结构。1NF的定义为：符合1NF的关系中的每个属性都不可再分。表1所示的情况，就不符合1NF的要求。

表1

实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。如果我们要在RDBMS中表现表中的数据，就得设计为表2的形式：表2

表2

但是仅仅符合1NF的设计，仍然会存在数据冗余过大，插入异常，删除异常，修改异常的问题，例如对于表3中的设计：

每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大

假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的 —-—插入异常

假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）。——删除异常

假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据。——修改异常。

正因为仅符合1NF的数据库设计存在着这样空枣那样的问题，我们需要提高设计标准，去掉导致上述四种问题的因素，使其符合更高一级的范式（2NF），这就是所谓的“规范化”。

第二范式

第二范式在之一范式的基础之上更进一层。是指2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。

函数依赖：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。

表中的函数依赖关系例如：

系名 → 系主任

学号 → 系主任

（学号，课名） → 分数

但以下函数依赖关系则不成立：

学号 → 课名

学号 → 分数

课名 → 系主任

（学号，课名） → 姓名

码:假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。码也可以理解为主键。

第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。

订单信息表

这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。

而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。如下所示。

订单信息表

订单项目表

商品信息表

这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。

因此可以总结判断的方法是：

之一步：找出数据表中所有的码。

第二步：根据之一步所得到的码，找出所有的主属性。

第三步：数据表中，除去所有的主属性，剩下的就都是非主属性了。

第四步：查看是否存在非主属性对码的部分函数依赖。

第三范式

3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。

则就是第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。

订单信息表

客户信息表

这样在查询订单信息的时候，就可以使用客户编号来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减小了数据冗余。

由此可见，符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的。

数据库设计的三范式的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于数据库设计的三范式,三范式：数据库设计的重要原则,关于数据库三大设计范式浅析的信息别忘了在本站进行查找喔。

香港服务器首选树叶云，2H2G首月10元开通。
树叶云（www.IDC.Net）提供简单好用，价格厚道的香港/美国云服务器和独立服务器。IDC+ISP+ICP资质。ARIN和APNIC会员。成熟技术团队15年行业经验。