判断属于第几范式的例题

在关系数据库设计中，范式理论是一种重要的概念框架。范式理论通过多个规范化过程，将复杂的实体关系模型拆分成更小、更简单的数据表结构，以减少数据冗余、避免数据更新异常，并提高数据库的性能和可维护性。根据范式理论，一个更高级别的范式必定符合一个更低级别范式的要求，因此，从低到高依次为第一范式（1NF）、第二范式（2NF）、第三范式（3NF）和巴斯-科德范式（BCNF）。

但在实际数据库设计中，设计者往往需要根据具体的应用需求，进行权衡和取舍，不一定遵循完全的范式化设计。因此，在判断数据库结构是否符合某一范式时，除了单纯依据范式的定义外，还需考虑具体问题的实际情况，综合分析各方面风险和效益。下面，我们以几个例题来说明如何判断一个关系是否符合某一范式。

例1：考试成绩表

给出一个考试成绩表，包括学生姓名、学号、考试科目和成绩四个属性。其中，学号和考试科目作为主码，学生姓名与考试科目联合作为外键分别指向学生表和科目表，如图1所示。请问该表满足哪些范式？

图1 考试成绩表结构

分析：

- 第一范式（1NF）：每个属性不可再分，每个属性的取值为原子值。该表满足1NF。

- 第二范式（2NF）：属性没有部分依赖于主码。在该表中，学号和考试科目组成主码，其他属性均完全依赖于主码，因此该表满足2NF。

- 第三范式（3NF）：属性不存在传递依赖关系。在该表中，学生姓名与考试科目两个属性同时依赖于主码，因此存在传递依赖关系。需要将学生姓名与考试科目分别提取到学生表和科目表中，再通过外键建立对应关系，形成三个表：学生表、科目表和考试成绩表。这样，考试成绩表就可以达到3NF。

总结：

考试成绩表在满足1NF和2NF的基础上，需要进行拆分，以达到3NF。

例2：职员信息表

给出一个职员信息表，包括职员编号、职员姓名、上司编号、所属部门、入职日期和薪资六个属性。其中，上司编号和所属部门为非主属性，职员编号为主码，如图2所示。请问该表满足哪些范式？

图2 职员信息表结构

分析：

- 第一范式（1NF）：每个属性不可再分，每个属性的取值为原子值。该表满足1NF。

- 第二范式（2NF）：属性没有部分依赖于主码。在该表中，所有属性都完全依赖于主码，因此该表满足2NF。

- 第三范式（3NF）：属性不存在传递依赖关系。在该表中，上司编号和部门名称两个非主属性同时依赖于主码，因此存在传递依赖关系。需要将上司编号和部门名称分别提取到上司表和部门表中，再通过外键建立对应关系，形成三个表：职员表、上司表和部门表。这样，职员信息表可以达到3NF。

总结：

职员信息表在满足1NF和2NF的基础上，需要进行拆分，以达到3NF。

例3：订单商品表

给出一个订单商品表，包括订单编号、商品编号、商品名称、商品单价、商品数量和商品金额六个属性。其中，订单编号和商品编号作为主码，如图3所示。请问该表满足哪些范式？

图3 订单商品表结构

分析：

- 第一范式（1NF）：每个属性不可再分，每个属性的取值为原子值。该表满足1NF。

- 第二范式（2NF）：属性没有部分依赖于主码。在该表中，所有属性都完全依赖于主码，因此该表满足2NF。

- 第三范式（3NF）：属性不存在传递依赖关系。在该表中，商品名称、商品单价、商品数量和商品金额四个属性都相互依赖，不存在传递依赖关系。因此，该表已经满足3NF。

总结：

订单商品表已经满足1NF、2NF和3NF。

综上，判断一个关系是否符合某一范式，需要了解范式理论的基本要求，同时结合具体实际情况，分析数据的依赖关系和规范化可能带来的利弊。在实际数据库设计中，不一定要追求完全的范式化，而应该找到一个平衡点，既保证数据的有效性和一致性，又兼顾应用程序的灵活性和性能要求。