我以为我理解范式答案

【问题标题】：I thought I understood Normal Forms我以为我理解范式
【发布时间】：2015-09-16 15:53:09
【问题描述】：

我正在在线学习 Web 开发文凭，并且刚刚进入数据库设计和开发领域。我以为我理解了范式，但我刚刚遇到了一个让我停下脚步的问题。

查看以下客户实体的属性列表：
Customer(cus_ID, name, address, mobile_phone)
为什么这个实体不在 3NF 中？

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

我是不是把 3NF 的整个概念都弄错了？

【问题讨论】：

我怀疑 address 可能会被规范化，因为不同的客户可能共享相同的地址。
一个客户可以有多个电话（以及多个客户有一个地址）。如果客户 ID 标识了一个家庭，那么每个 ID 也可以有多个名称。您需要更多信息才能得出一个好的答案。功能依赖是什么？属性之间关系的基数是什么？如果这是整个问题，那么这是一个糟糕的问题。你唯一的问题是过多地阅读给出的信息，而没有意识到它是不可回答的——这很难。
Re “如果没有客户，所有属性都不会存在，名称、地址和移动数据集都需要客户存在。”规范化与“必须存在”的实体或属性无关。它是关于（将关系拆分为投影）（消除某些）功能依赖和连接依赖。（实体-关系信息建模有一个“弱实体”的概念，但这与规范化无关。）所以看起来你“把 3NF 的整个概念弄错了”。
@Dai：分解，因为“不同的客户可能共享相同的地址”不是规范化。规范化不能添加新的属性（例如，如果你是这个意思，addressid）。也不需要删除 CK（候选键）上的 FD（功能依赖）（例如，删除地址并添加包含客户和地址的表，如果您是这个意思）。即移除一个CK 隐含的JD（连接依赖）。标准化为 5NF 被定义为没有 JD除了那些。如果共享一个地址的所有客户都必须共享一个 set 的所有地址（即一个 MVD，即 2-way JD），那么这违反了 4NF（但不是 3NF）。

标签： database normalization database-normalization

【解决方案1】：

多个客户可以有相同的地址。

【讨论】：

虽然这是真的，但它与规范化无关。

【解决方案2】：

一开始看起来很奇怪，但是您还没有定义地址甚至 id 中的内容。我想到的违反 3NF 的一些可能性是（除了您可能在此处获得的其他 cmets 和答案）：

如果id是手机号本身。
如果客户拥有多个手机或多个地址，企业有兴趣捕获Source of this point。
如果地址包含某些通讯方式，包括手机。
如果手机号码可以通过某种方式在用户之间传播。例如，号码在不同国家/地区/运营商之间可能不必是唯一的（我不是电信专家）。
如果地址包含国家、城市和州信息，并且手机号码可以包含区号作为其一部分（取决于国家、城市和州信息）。
李>

编辑：我最初包含了这一点，但@philipxy 在下面的注释中另有建议： “如果在此处未显示的数据库的其他部分中找到任何属性。”

【讨论】：

6 是错误的，应该删除。关系变量的归一化与其他关系变量无关。（设计质量确实涉及整个数据库。）

【解决方案3】：

从某种角度来看，该表不符合第三范式，因为它不是第一范式。 “手机？可能还有哪些其他类型的手机？ “地址” ？哪个地址 - 家庭、企业、游艇停靠的位置等？姓名 - 姓名的子字段是什么（名字、中间名、姓氏 - 哦，那里是否也有诸如 Dr. 或 Mr. 或 Herr Doktor Ingeneur 之类的头衔？）？

【讨论】：

我不知道我应该深入研究它，因为它很早就进入了数据库单元。我的想法也直接涉及多种电话的问题，但我的讲师说这根本不是我应该解决的问题，我觉得这是错误的。这些问题应该充分说明不同电话的可能性，地址的额外部分以及其他部分。
@Slappy & Bob Jarvis：涉及被视为异构或同质集合的属性的“规范化”或“1NF”概念与规范化无关。由于它用于规范化，所有关系变量都在 1NF 中。

【解决方案4】：

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

所以也许问题应该以不同的方式提出：

给定这个模式，在现实假设下，哪些是函数依赖关系？

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

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

【讨论】：