Database 我以为我懂正规形式

我在网上学习网络开发的文凭，刚刚进入数据库设计和开发领域。我原以为我理解范式，但我刚刚遇到了一个问题，这个问题使我停滞不前

查看客户实体的以下属性列表：

Customer(cus_ID, name, address, mobile_phone)

为什么该实体不在3NF中

据我所知，它是在3NF。如果没有客户，所有属性都不存在，名称、地址和移动数据集要求客户存在

---

我刚刚把3NF的整个概念搞错了吗？

多个客户可能有同一个地址。

一开始看起来很奇怪，但你还没有定义地址，甚至没有定义id。脑海中出现的违反3NF的一些可能性是（除了你可能在这里得到的其他评论和答案）：

如果id是移动电话号码本身

如果客户有一部以上的手机或一个以上的地址，企业有兴趣捕获

如果地址包括一些通信方式，包括移动电话

如果手机号码可以在用户之间传播。例如，数字可能不必在国家/运营商之间是唯一的（我不是电信专家）

如果地址包含国家、城市和州信息，并且移动电话号码允许包含区号作为其一部分（这取决于国家、城市和州信息）

编辑： 我最初包含了这一点，但@philipxy在下面的注释中提出了其他建议：

---

“如果在此处未显示的数据库的其他部分中找到任何属性。”

从某种角度来看，此表不符合第三范式，因为它不是第一范式。“移动”电话？可能还有什么其他类型的手机？“地址”？哪一个地址-家、公司、游艇停靠地等？姓名-姓名的子字段是什么（第一、中间、最后和哦，是否也有诸如Dr.或Mr.或Herr Doktor Ingeneur之类的头衔？）

前面给出的每个答案都会对数据的含义做出假设。但是要知道一个模式是否在3NF中，唯一正确的答案是：“向我展示模式的函数依赖关系，然后我可以证明模式是否在3NF中”。这是因为3FN是一个正式的概念，只有在正式的上下文中才有意义

因此，也许这个问题应该以不同的方式提出：

在这种模式下，在现实的假设下，哪些是功能依赖性

然后从这些函数依赖中，我们可以知道，而不是推测一个标准形式

---

因此，在我看来，一门没有人教你什么是函数依赖关系，并问你某个关系是否在3NF中的课程不是一门好课程。

我怀疑可能

地址
可以规范化，因为不同的客户可能共享同一地址。一个客户可能有多部手机（以及具有单个地址的多个客户）。如果客户ID标识了一个系列，那么每个ID也可以有多个名称。您需要更多信息才能得出一个好的答案。功能依赖性是什么？属性之间关系的基本属性是什么？如果这是整个问题，那么这是一个坏问题。您唯一的问题是阅读对所提供的信息进行了大量分析，但没有意识到这是不可回答的——这很难。Re“如果没有客户，所有属性都不会存在，名称、地址和移动数据集都要求客户存在。”规范化不是关于“必须存在”的实体或属性。而是关于（将关系拆分为投影）（消除某些）功能依赖项和连接依赖项。（实体关系信息建模有一个“弱实体”的概念，但与规范化无关。）因此看起来您“把3NF的整个概念搞错了”。@Dai:分解是因为“不同的客户可能共享同一个地址”不是规范化。规范化不能添加新属性（如addressid，如果你这么说的话）。也不要求删除CK（候选键）上的FD（功能依赖项）（如删除地址，并添加一个带有客户和地址的表，如果你这么说的话）。即删除JD（连接依赖项）由CK暗示。规范化为5NF定义为除这些JD之外没有JD。如果共享一个地址的所有客户都必须共享一个集合的所有地址（即MVD ie双向JD），则违反4NF（但不是3NF）.我不知道我是否应该深入研究它，因为它在数据库单元中还处于早期阶段。我的头脑也直接想到了多种类型手机的问题，但我的讲师说这根本不是我应该解决的问题，我觉得这是错的。这些问题应该充分体现出d的可能性不同的电话，地址的额外部分等等。@Slappy&bobjarvis:normalized或1NF的概念“涉及被视为异类或同质集合的属性与规范化无关。因为在规范化中使用了它，所以所有关系变量都在1NF中。6是错误的，应该删除。关系变量的规范化与其他关系变量无关。（设计质量确实涉及整个数据库。）虽然这是事实，但与规范化无关。