将数据库放入第二范式
在过去的一个月中，我们研究了数据库表正常化的几个方面。 首先，我们讨论了数据库规范化的基本原则。 上次，我们探讨了第一范式（1NF）规定的基本要求。 现在，让我们继续我们的旅程，并涵盖第二范式（2NF）的原则。
回想2NF的一般要求：
- 除去适用于多行表格的数据的子集，并将它们放在不同的表格中。
- 通过使用外键在这些新表和他们的前辈之间建立关系。
这些规则可以用一个简单的语句来概括：2NF试图通过提取表来减少表中冗余数据的数量，将它放在新表中并创建这些表之间的关系 。
我们来看一个例子。 想象一下，在线商店将客户信息保存在数据库中。 他们可能有一个名为Customers的表，其中包含以下元素：
- CustNum
- 名字
- 姓
- 地址
- 市
- 州
- 压缩
简要看一下这个表格会发现少量的冗余数据。 我们将“海崖，纽约11579”和“迈阿密，佛罗里达州33157”分别储存两次。 现在，在我们的简单示例中，这看起来可能不是太多增加的存储空间，但如果我们的表中有成千上万行，则可以想象浪费的空间。 此外，如果Sea Cliff的邮政编码发生变化，我们需要在整个数据库的许多地方进行更改。
在符合2NF的数据库结构中，此冗余信息被提取并存储在单独的表中。 我们的新表（我们称之为ZIP）可能具有以下字段：
- 压缩
- 市
- 州
如果我们想要超级高效，我们甚至可以提前填写此表 - 邮局提供所有有效邮政编码及其城市/州关系的目录。 当然，你遇到过这种类型的数据库被利用的情况。 有人下订单可能会先要求您提供您的邮政编码，然后才知道您打来的城市和州。 这种布置减少了操作员的错误并提高了效率。
现在我们已经从Customers表中删除了重复的数据，我们已经满足了第二范式的第一条规则。 我们仍然需要使用外键将两个表连接在一起。 我们将使用邮政编码 （ ZIP表中的主键）来创建该关系。 这是我们的新Customers表：
- CustNum
- 名字
- 姓
- 地址
- 压缩
现在我们已经最小化了存储在数据库中的冗余信息的数量，并且我们的结构处于第二范式！
如果您想确保您的数据库已正常化，请浏览本系列中的其他文章：
- 数据库规范化基础
- 将数据库置于第一范式
- 将数据库置于第二范式
- 将数据库置于第三范式