为什么不应将邮政编码值放在 Boyce Codd 范式中？答案

【问题标题】：Why should zipcode values not be placed in Boyce Codd Normal Form?为什么不应将邮政编码值放在 Boyce Codd 范式中？
【发布时间】：2013-09-09 14:00:11
【问题描述】：

有人可以向我解释为什么邮政编码不应该放在 Boyce Codd 范式中吗？除了邮政编码在任何可预见的时间点都不太可能发生变化之外，真的还有其他的吗？

【问题讨论】：

你能举个例子说明你真正想问什么吗？
抱歉有点不清楚。我试图理解其中的原因，但除了邮政编码之外，我还找到了另一个很好的例子。一些不会经常更改的东西，以至于您会因为时间和精力而真正担心将这样的值拆分为数据表结构的 BCNF。
对不起，我还是不明白——例如表 ZipCode{Zip} KEY {ZIP} 在 6NF 中（因此也在 5、4、BCNF、3、2、1 中）。你到底想分裂什么？

【解决方案1】：

假设您说的是 2NF，而不是 3NF 和 BCNF 之间的细微差别（因为邮政编码似乎与 BCNF 无关），那么：
是的，而且它不必要地钝化，只节省了一个字节的存储空间（邮政编码是五个字符，可以存储在 5 个字节中，一个整数外键是 4 个字节），并且需要一个额外的连接来检索价值。

【讨论】：

归一化与存储大小无关！
如果涉及创建另一个表，使用外键从另一个表中获取值，就像这里一样，以满足 2NF，创建一个 ZipCode 表以避免重复非依赖数据，确实如此。
但是 2NF、BCNF 或任何其他 NF 都不需要将邮政编码替换为 4 字节整数，并且没有明显的理由将邮政编码属性本身移动到另一个表会消除任何依赖关系，否则违反任何 NF（可能除了 6NF）。同样，规范化与存储大小无关，并且与任何属性的数据类型或大小完全正交。

【解决方案2】：

Zipcode 是一个属性，而 BCNF 是一个由 relation 或一组关系满足的属性。作为一般规则，目标至少是 BCNF，除非并且直到你有充分的理由偏离它。在此基础上，我建议与邮政编码属性的关系应该在 BCNF 中。是什么让你不这么认为？

【讨论】：

【解决方案3】：

仅当您打算根据邮政编码查找其他信息（例如区域设置）时，才应将邮政编码放在 3NF 或 BCNF 中。在这种情况下，邮政编码成为“自然键”。

没有这种背景，似乎没有什么意义。在大多数应用程序中，邮政编码仅被视为一段文本，否则没有任何上下文含义。

【讨论】：

我明白了。除了邮政编码之外，还有什么情况会选择不理想地将数据库表放入 BCNF 中？
有很多。任何时候不希望或没有必要执行查找。
是的，例如 SSN。除非你是社会保障局。
@Robert，我不明白。您是在谈论将 SSN 或 Zipcode 分解为自己的关系吗？我看不出这与 BCNF 有什么关系。也许你可以举一个实际的例子来解释你的意思。
我也不明白这与 BCNF 具体有什么关系。在我看来，问题是：“为什么不将邮政编码存储在单独的表/关系中？” +1 的答案。