什么是数据库的正常forms，你怎么能轻松地应用它们，你可以举个例子吗？
在关系数据库devise中，存在数据库规范化或简单规范化的概念，这是组织列（属性）和表（关系）以减less数据冗余和提高数据完整性的过程。 （如维基百科上所写）。
由于大多数文章都是技术性的，因此难以理解，所以我要求某人根据关于1NF，2NF，3NF，甚至3.5NF（Boyce-Codd）的含义以及某人可能如何思考的例子，写一个更容易理解的解释以便随时应用这些基本规则，因为在devise关系数据库时，它们似乎是要记住的最重要的事情。
1NF是常规forms中最基本的一种 – 表中的每个单元格必须只包含一条信息，并且不能有重复的行。
2NF和3NF都依赖于主键。 回想一下，主键可以由多个列组成。 正如克里斯在回答中所说：
数据取决于关键[1NF]，整个关键[2NF]，只有关键[3NF]（所以帮助我Codd ）。
2NF
假设你有一个包含某个学期课程的表格，你有以下数据：
|-----Primary Key----| uh oh | V CourseID | SemesterID | #Places | Course Name | ------------------------------------------------| IT101 | 2009-1 | 100 | Programming | IT101 | 2009-2 | 100 | Programming | IT102 | 2009-1 | 200 | Databases | IT102 | 2010-1 | 150 | Databases | IT103 | 2009-2 | 120 | Web Design | 这不是在2NF ，因为第四列不依赖于整个键 – 但只有一部分。 课程名称取决于课程的ID，但是与哪个学期无关。因此，如您所见，我们有重复的信息 – 几行告诉我们IT101正在编程，而IT102是数据库。 所以我们通过将课程名称移动到另一个表格中来解决这个问题，CourseID是ENTIRE键。
Primary Key | CourseID | Course Name | ---------------------------| IT101 | Programming | IT102 | Databases | IT103 | Web Design |
没有冗余！
3NF
好的，我们假设我们还将课程的老师的姓名和关于他们的一些细节添加到关系数据库中：
|-----Primary Key----| uh oh | V Course | Semester | #Places | TeacherID | TeacherName | ---------------------------------------------------------------| IT101 | 2009-1 | 100 | 332 | Mr Jones | IT101 | 2009-2 | 100 | 332 | Mr Jones | IT102 | 2009-1 | 200 | 495 | Mr Bentley | IT102 | 2010-1 | 150 | 332 | Mr Jones | IT103 | 2009-2 | 120 | 242 | Mrs Smith |
现在希望教师名是依赖TeacherID的 – 显然这不是3NF 。 为了解决这个问题，我们做了和2NF一样的工作 – 从这个表中取出TeacherName字段，并将其放在TeacherID作为关键字的位置。
Primary Key | TeacherID | TeacherName | ---------------------------| 332 | Mr Jones | 495 | Mr Bentley | 242 | Mrs Smith |
没有冗余！
需要记住的一件重要的事情是，如果某种东西不在1NF中，那么它不在2NF或3NF中。 所以每个额外的范式都需要一般的下限范式，再加上一些必须满足的额外条件。
我对于确切的措辞从来没有过好的记忆，但是在我的数据库课上，我认为教授总是这样说：
数据取决于密钥[1NF]，整个密钥[2NF]以及除了密钥[3NF]之外的任何内容。
这是一个快速，坦率的屠杀反应，但在一句话：
1NF：您的表格被组织为一组无序的数据，并且没有重复的列。
2NF：由于另一列，您不会重复表格的一列中的数据。
3NF：表格中的每一列只与您的表格关键字相关 – 表格中没有描述表格中另一列不是关键字的列。
有关更多详细信息，请参阅wikipedia …
1NF：每列只有一个值
2NF：表中的所有非主键列应依赖于整个主键。
3NF：表中的所有非主键列应该直接取决于整个主键。
我已经在这里更详细地写了一篇文章
