数据库7种范式

大家好，欢迎来到IT知识分享网。

在关系数据库设计中，存在多个范式，通常从第一范式（1NF）到更高阶的范式。以下是一些常见的数据库范式：

1. 第一范式(1NF)

确保每个表的每个列都包含原子值，不可再分。

• 每个表都应该有一个主键：保证表中的每一行都是唯一标识的。
• 表中的每一列都应该包含原子值：每个单元格中只能包含一个值，而不能包含多个值。

不满足第一范式的后果：

• 如果不符合第一范式，可能会导致数据冗余、更新异常和复杂的查询操作。

举例

违反第一范式的学生课程信息表：

上述表违反了第一范式，因为 “所修课程” 这一列包含了多个值。正确的设计应该是将每门课程放在单独的行中：

2. 第二范式(2NF)

确保表中的非主键列完全依赖于整个主键，而不是部分依赖。

也就是说2NF针对复合组件和部分依赖的情况。如果表中有一个复合组件(即有多个列组成的主键)，那么所有其他非主键列都必须完全依赖于这个复合组件。

举例：

以下表格是一个具有复合主键(StudentID, CourseID)且存在冗余的表格。因为 CourseName 和 Instructor 不完全依赖于整个复合主键，而只依赖于部分主键。

StudentCourses | StudentID | CourseID | CourseName | Instructor | |-----------|----------|------------|--------------| | 1 | 101 | Math | Prof. Smith | | 1 | 102 | English | Prof. Johnson| | 2 | 101 | Math | Prof. Smith | 

冗余分析：

在原始表格中，Math和Prof. Smith的信息被重复存储了两次(两次在StudentID为1和2的行中出现)，而这两门课实际上是相同的。这种冗余会导致以下问题：

1. 数据一致性：如果对Math或Prof. Smith的信息进行修改，需要在多个地方进行更新，容易出现数据不一致的情况。

2. 存储空间浪费： 存储相同的课程信息多次会浪费存储空间，尤其在大型数据库中可能成为一个问题。

3. 维护复杂性： 数据冗余增加了维护的复杂性，因为需要确保多个地方的数据保持一致。

通过拆分表格，我们可以消除这些冗余，如拆分后的Courses表格所示：

Students | StudentID | StudentName | |-----------|-------------| | 1 | John | | 2 | Jane | Courses | CourseID | CourseName | Instructor | |----------|------------|--------------| | 101 | Math | Prof. Smith | | 102 | English | Prof. Johnson| StudentCourses | StudentID | CourseID | |-----------|----------| | 1 | 101 | | 1 | 102 | | 2 | 101 | 

现在，每门课程只有一条记录，避免了在原表格中重复存储相同的课程信息。这有助于提高数据一致性、减少存储空间的浪费，并简化了维护过程。这就是通过第二范式的原则来消除冗余的方式。

3. 第三范式(3NF)

确保表中的每个非主键列不依赖于其他非主键列，即不存在传递依赖。

• 影响一致性： 3NF 要求表中的非主键列不能有传递依赖关系，进一步确保了数据的一致性。每个非主键列都直接依赖于主键，而不是依赖于其他非主键列。
• 减少冗余： 3NF 通过消除非主键列之间的传递依赖，减少了数据冗余。

举例：

考虑一个包含学生信息、课程信息和学生成绩的表格：

在上述表格中，(StudentID, CourseID) 是复合主键。这个表格满足第二范式，因为非主键列（例如 Instructor 和 Department）完全依赖于整个复合主键, 只有一个完整的(StudentID, CourseID)才能确定一个Instructor 或者Department  。然而，该表不满足第三范式，因为 Instructor 和Department列直接依赖于 CourseID，而 CourseID 又依赖于 StudentID。存在传递依赖关系，违反了第三范式的要求。

StudentCourses | StudentID | CourseID | Instructor | Department | |-----------|----------|--------------|--------------| | 1 | 101 | Prof. Smith | Computer Sci | | 1 | 102 | Prof. Johnson| English | | 2 | 101 | Prof. Smith | Computer Sci | 

为了满足第三范式，我们可以将表格拆分，将 Instructor 列从 StudentCourses 表中分离：

1. Courses

Courses | CourseID | Department | |----------|--------------| | 101 | Computer Sci | | 102 | English | 

2. StudentCourses

StudentCourses | StudentID | CourseID | |-----------|----------| | 1 | 101 | | 1 | 102 | | 2 | 101 | 

3. Instructors

Instructors | CourseID | Instructor | |----------|--------------| | 101 | Prof. Smith | | 102 | Prof. Johnson| 

4. 巴斯-科德规范形式(BCNF)

也就是说对表格里的每一个候选键，当他们作为主键时，每个非主属性都要完全依赖于该候选键，才算满足BCNF范式。候选键是可以唯一标识一行数据的最小组合。

• 主要关注消除关系中的部分依赖和传递依赖。
• 要求每个非主属性完全依赖于候选键，而不是只依赖于候选键的一部分。
• 通过分解表来消除部分依赖和传递依赖的影响，确保每个非主属性都直接依赖于所有的候选键。

示例：

Orders | OrderID | ProductID | ProductName | CustomerID | CustomerName | Price | |---------|-----------|-------------|------------|--------------|-------| | 1 | 101 | Laptop | 1001 | John | 1200 | | 2 | 102 | Printer | 1002 | Jane | 300 | | 3 | 101 | Laptop | 1003 | Bob | 1200 | 

在上述表格中，(OrderID, ProductID) 是候选键。但是，CustomerName 仅依赖于 CustomerID，而不依赖于整个候选键。为了满足 BCNF，可以将表格拆分：

Orders | OrderID | ProductID | CustomerID | Price | |---------|-----------|------------|-------| | 1 | 101 | 1001 | 1200 | | 2 | 102 | 1002 | 300 | | 3 | 101 | 1003 | 1200 | Customers | CustomerID | CustomerName | |------------|--------------| | 1001 | John | | 1002 | Jane | | 1003 | Bob | 

5. 第四范式(4NF)

处理多值依赖，确保每个非主键属性完全依赖于候选键，而不是依赖于候选键的一部分。

• 主要关注消除关系中的多值依赖。
• 多值依赖是指在关系中的非主属性之间存在的关系，其中一个非主属性的值可以决定另一个非主属性的值。
• 通过分解表来消除多值依赖，确保表中的每个非主属性都不依赖于其他非主属性的非主属性。

示例：

考虑一个表格 Employees：

Employees | EmployeeID | Department | Skills | |------------|--------------|-------------------| | 1 | HR | Communication, HR| | 2 | IT | Programming, IT | | 3 | Marketing | Marketing, Sales | 

在上述表格中，Skills 列包含多个值，表示一个员工可能有多个技能。为了满足第四范式，可以将表格拆分：

Employees | EmployeeID | Department | |------------|------------| | 1 | HR | | 2 | IT | | 3 | Marketing | EmployeeSkills | EmployeeID | Skill | |------------|--------------| | 1 | Communication| | 1 | HR | | 2 | Programming | | 2 | IT | | 3 | Marketing | | 3 | Sales | 

6. 第五范式(5NF)

处理联合依赖，确保每个非主键属性不依赖于候选键的某一部分。

示例：

考虑一个包含项目、部门和员工信息的表格：

Projects | ProjectID | ProjectName | DepartmentID | DepartmentName | EmployeeID | EmployeeName | |-----------|-------------|--------------|-----------------|------------|--------------| | 1 | ProjectA | 101 | HR | 1001 | John | | 2 | ProjectB | 102 | IT | 1002 | Jane | | 3 | ProjectC | 103 | Marketing | 1003 | Bob | 

在上述表格中，(ProjectID, DepartmentID) 是联合主键。如果考虑 (ProjectID, DepartmentID) -> EmployeeID 的联合依赖关系，那么我们可以将表格拆分

Projects | ProjectID | ProjectName | DepartmentID | |-----------|-------------|--------------| | 1 | ProjectA | 101 | | 2 | ProjectB | 102 | | 3 | ProjectC | 103 | Departments | DepartmentID | DepartmentName | |--------------|-----------------| | 101 | HR | | 102 | IT | | 103 | Marketing | Employees | EmployeeID | EmployeeName | |------------|--------------| | 1001 | John | | 1002 | Jane | | 1003 | Bob | ProjectEmployees | ProjectID | DepartmentID | EmployeeID | |-----------|--------------|------------| | 1 | 101 | 1001 | | 2 | 102 | 1002 | | 3 | 103 | 1003 | 

这样，联合依赖关系被消除，每个表都只包含必要的信息。

7. 第六范式(6NF)

处理超关系(超关系是一个关系中的某些属性是另一个关系的关系键)。

是关系数据库理论中的一个较为高级和少用的范式。它主要涉及到多值依赖的概念，通常在包含多值依赖的情况下才会考虑使用。

示例：

考虑一个包含课程、学生和成绩的表格：

Grades | CourseID | StudentID | Grade | |----------|-----------|-------| | 101 | 1001 | A | | 102 | 1002 | B | | 101 | 1003 | C | 

在上述表格中，(CourseID, StudentID) 是联合主键。如果考虑 CourseID -> Grade 的函数依赖关系，我们可以将表格拆分：

Courses | CourseID | CourseName | |----------|------------| | 101 | Math | | 102 | English | Students | StudentID | StudentName | |-----------|-------------| | 1001 | John | | 1002 | Jane | | 1003 | Bob | CourseGrades | CourseID | Grade | |----------|-------| | 101 | A | | 102 | B | | 101 | C | StudentCourseGrades | StudentID | CourseID | Grade | |-----------|----------|-------| | 1001 | 101 | A | | 1002 | 102 | B | | 1003 | 101 | C | 

8. 第七范式（7NF）

第七范式通常涉及到更复杂的概念，主要用于处理多值依赖。在实际应用中，很少需要考虑到第七范式，因为这个范式要求的条件非常严格，而且可能导致过多的表和复杂的查询。