问题标签 [3nf]

我正在努力思考如何证明 3NF。我实际上有答案，但如果有人知道这一点足以让我理解它，我将非常感激。好的，就这样：

1. 如果根据定义 2，R 在 3NF 中，根据定义 1，R 必须在 3NF 中。回想一下，如果根据定义 1，R 在 3NF 中，则必须满足以下两个条件。

i) 对于 R，我们在非键属性和通过其他非键属性的键之间没有任何传递函数依赖关系。

ii) 对于 R，我们在非键属性和键之间没有任何部分函数依赖关系。

假设 R 不满足 (i)。那么，我们必须有一个传递的FD：X→A，A→B，其中X是键，A和B是非键属性。但是根据定义 2，R 没有这种类型的 FD。（也就是说，A 必须是主属性或超级键。）矛盾。所以 R 必须满足 (i)。

假设 R 不满足 (ii)。那么，我们必须有一个键 X (S ⊂ X) 的子集 S，使得存在一个 S → A 的非键属性 A。但是，根据定义 2，S 必须是一个超键。矛盾。所以 R 必须满足 (ii)。因此，根据定义 1，R 在 3NF 中。

2. 如果根据定义 1，R 在 3NF 中，根据定义 2，R 必须在 3NF 中。

 假设根据定义 2，R 不在 3NF 中。那么，我们必须有一个 FD：X → A 使得 X 不是超键且 A 不是素数属性。考虑 R 的一个键 X'。我们必须有 X'→X→A。它是非键属性A和键X'之间通过X的传递FD。如果X是非键属性，则根据定义1，R不在3NF中。矛盾。如果 X 出现在 X' 中，我们有一个部分 FD。所以 R 不在 2NF 中，这与定义 1 相矛盾。

作为家庭作业的一部分，我被要求根据案例研究创建表格，并且所有表格都必须是 3NF。但是，我已经尝试并试图理解 3NF，但我只是没有掌握它的窍门，希望能得到一些帮助。

案例研究的要求是针对兽医诊所的：

1. 允许宠物预约
2. 记录宠物治疗
3. 记录哪位兽医进行了治疗
4. 记录企业出售的物品以提供信息，使企业能够生成库存清单以从供应商处购买

不需要：记录所有销售

到目前为止，我有以下表格：

职员：

员工地址表：

兽医表：

兽医护士：

预约表：

initial_appointment 表：

跟进预约：

病人：

产品：

product_sold:

供应商：

供应商地址：

存货：

谢谢！

我正在为 4NF 和多值依赖 (MVD) 的概念而苦苦挣扎。

我正在查看我目前正在学习的课程的补充书籍，其中一个示例如下。

该书指出星号指的是唯一键或复合属性键。

给定：R(A*,B,C*) 和集合 {(A,B):R,(B,C):R} 满足无损分解特性。

多值依赖 B->>C 是否成立？
B 绝对是唯一的键吗？
R 在 4NF 中吗？

我理解无损分解-如果您采用上述两组的自然连接-您将获得原始数据集，即在本例中为 A、B、C。

但是我只是无法掌握如何获取给定的信息并证明/确认 B->>C 成立或不成立。

我给我的教授发了一封电子邮件，告诉我我的困惑，他只是告诉我看一下他的笔记（我显然已经做过很多次了），但这让我无处可去。

我是数据库新手，我目前正在处理一项任务，我必须从已规范化为 3NF 的表数据创建 ERD。

我的问题是我有一个来自 1NF 的复合键，但所有非键属性似乎都依赖于两个主键。现在我正在尝试将它从 2NF 转换为 3NF，但我不确定我是否仍然可以拥有复合密钥。

假设，我有一个包含列的表：

• person_id（主键）
• 名
• 姓
• 生日

我对组合 {first_name, last_name} 也有一个唯一约束（我知道更多人可以有相同的名字，但我想让我的示例保持简单）。我想知道这个表是否是第三范式。

我的推理（编辑前）：

• 所有字段只能包含原子值，因此表是第一范式。
• 候选键是 1) person_id, 2) [first_name, last_name]
• 唯一的非主要属性是生日。
• 属性生日在功能上不依赖于候选键 1 的一部分（无论如何这是不可能的，因为候选键 1 中只有 1 个属性）
• 属性生日在功能上不依赖于候选键 2 的一部分
• 因此，该表是第二范式。
• 属性生日（是/不是）非传递依赖于候选键 1
• 属性生日不传递依赖于候选键 1

问题（编辑前）：

我无法回答的问题是生日是否非传递依赖于 person_id。从功能上讲，这个身份证号码和生日完全没有关系。

1. 这是否意味着存在传递依赖（生日取决于 [first_name, last_name]，每个组合 [first_name, last_name] 映射到一个 id），因此不在 3NF 中？
2. 这是否意味着根本没有依赖关系，因此不在 3NF 中？
3. 我是否误解了难懂的语言，这张表是 3NF 中的吗？

我的推理（编辑后）：

• 如果你知道 person_id，你就知道他的名字、姓氏和他的生日，所以有 FD {person_id} -> {first_name}、{person_id} -> {last_name} 和 {person_id} -> {birthday}。
• 如果你知道一个人的名字和姓氏，你就知道他的 person_id 和生日，所以有 FD {first_name, last_name} -> {person_id} 和 {first_name, last_name} -> {birthday}。

• 如果您知道一个人的生日，那么您对他的 person_id 或姓名一无所知，因此没有从生日到另一个（一组）属性的 FD。

• 所有字段只能包含原子值，因此表是第一范式。

• 候选键是 1) {person_id}, 2) {first_name, last_name}
• 唯一的非主要属性是 {birthday}。
• {birthday} 属性在 CK 1 的一部分上不是 FD（无论如何这是不可能的，因为 CK 1 中只有 1 个属性）
• 属性 {birthday} 在 CK 2 的一部分上不是 FD

• 因此，该表是第二范式。

• 有一个 FD {person_id} -> {birthday}，所以属性 {birthday} 是非传递依赖于 CK 1

• 有一个 FD {first_name, last_name} -> {birthday}，所以属性 {birthday} 非传递依赖于 CK 2
• 因此，该表是第三范式。

有一个依赖 {person_id} -> {first_name, last_name} -> {birthday}，但由于还有一个直接依赖 {person_id} -> {birthday}，所以这个依赖不是传递的。

问题（编辑后）：

我没有从书中预定义的一组 FD，所以我不确定 FD 是否正确。有人可以确认这一点，或者如果他们看起来不正确，请展示我如何在这个实际示例中找到 FD？

第三个推理（第二次编辑）：

FD：

• 如果你只知道一个人的person_id，你就知道他的名字、姓氏和他的生日（不能有多个人具有相同的person_id）
  • FD：{person_id} -> {first_name}
  • FD：{person_id} -> {last_name}
  • FD：{person_id} -> {birthday}
• 不再需要考虑包含 {person_id} 的超集
• 如果你只知道一个人的名字，你就不知道这个人的任何其他字段（可以有多个人的名字相同）
  • 不是 FD：{first_name} -> {person_id}
  • 不是 FD：{first_name} -> {last_name}
  • 不是 FD：{first_name} -> {birthday}
• 如果您只知道一个人的姓氏，则您不知道此人的任何其他字段（可以有多个具有相同姓氏的人）
  • 不是 FD：{last_name} -> {person_id}
  • 不是 FD：{last_name} -> {first_name}
  • 不是 FD：{last_name} -> {birthday}
• 如果你只知道一个人的生日，你不知道这个人的任何其他字段（可以有多个人的生日相同）
  • 不是 FD：{birthday} -> {person_id}
  • 不是 FD：{birthday} -> {first_name}
  • 不是 FD：{birthday} -> {last_name}
• 如果你知道一个人的 first_name 和 last_name，你就知道他的 person_id 和他的生日（不能有多个人具有相同的 first_name 和 last_name）
  • FD：{first_name, last_name} -> {person_id}
  • FD: {first_name, last_name} -> {birthday}
• 不再需要考虑包含 {first_name, last_name} 的超集
• 如果您知道一个人的名字和生日，则您不知道此人的任何其他字段（可能有多个人的名字和生日相同）
  • 不是 FD：{first_name,birthday} -> {person_id}
  • 不是 FD：{first_name,birthday} -> {last_name}
• 如果您知道一个人的姓氏和生日，则您不知道此人的任何其他字段（可以有多个具有相同姓氏和生日的人）
  • 不是 FD：{last_name,birthday} -> {person_id}
  • 不是 FD：{last_name,birthday} -> {first_name}

正常形式：

• 所有属性只能包含单个值，因此表是第一范式。

• 查看 FD，有两个候选键：1) {person_id}, 2) {first_name, last_name}

• 唯一的非主要属性是 {birthday}。
• {birthday} 属性在 CK 1 的一部分上不是 FD（无论如何这是不可能的，因为 CK 1 中只有 1 个属性）
• 属性 {birthday} 在 CK 2 的一部分上不是 FD（即没有 FD {first_name} -> {birthday} 或 FD {last_name} -> {birthday}）

• 因此，该表是第二范式。

• 当存在满足 S -> X 和 X -> T 而不是（X -> S）的 X 时，S 可传递地确定 T

• 让 S = CK1 = {person_id} 和 T = {birthday}。当 X = {first_name, last_name} 时，唯一的 X 使得 S -> X 和 X -> T。然而，那么 X -> S 也成立。因此，S 非传递地确定 T。
• 让 S = CK2 = {first_name, last_name} 和 T = {birthday}。当 X = {person_id} 时，唯一的 X 使得 S -> X 和 X -> T。然而，那么 X -> S 也成立。因此，S 非传递地确定 T。
• 因此，该表是第三范式。

我正在使用一个表，该表具有一个复合主键，该主键由两个 1NF 形式的属性（总共 10 个）组成。

• 在我的情况下，一个全功能依赖涉及依赖依赖于我的主键中的两个属性。
• 部分依赖依赖于主键中的任一属性。
• 传递依赖涉及功能依赖中的两个或多个非关键属性，其中一个非关键属性依赖于我的主键中的关键属性。

将传递依赖关系从表中拉出，似乎是在规范化之后这样做，但我的任务要求我们在绘制依赖关系图之前识别所有功能依赖关系（之后我们对表进行规范化）。括号标识主键属性：

• 每个课程 ID 只教授一门课程。
• 学生最多可修读 4 门课程。
• 每门课程最多可容纳 25 名学生。
• 每门课程仅由一名讲师教授。
• 每个学生可能只有一个专业。

我看过这篇文章，但我并不真正理解使用的术语（非平凡的函数依赖，超级键）

从我读过的内容来看，第二范式似乎与复合键有关，而第三范式与主键有关。

我不确定这是否正确。

所以第二范式 - 有一个复合键，表中的所有字段都必须与两个复合键字段相关。如果某些内容不相关，则应将其重构为另一个表。

第 3 范式 - 一切都必须依赖于主键 - 所以我猜在第 3 范式中只有 1 个键，而不是在可以有复合键的第 2 范式中？

任何建议表示赞赏。

我被分配了大学作业，其中一个问题是描述 3NF 的重要性。

我理解规范化是为了消除数据冗余。

任何帮助或资源都会有很大帮助。

嘿，我正在研究一个示例问题，我必须确定哪些给定的关系在 3NF/BCNF 中。

这些是关系：

R1(A,B,C,D,E)

F=(CE->ABC, AB->C, C->A)

R2(C,D,E,G)

F=(CD->GE, E->D)

现在根据答案，R1 在 3NF 中，R2 在 BCNF 中，在这两种情况下我都不明白为什么。

如果规则是： R1 如何处于 3NF 中：

X -> A，则 A 是 X 的子集

X 是一个超级键

A 是 R 的某个键的一部分

在 R1 中有 C->A = A 不是键的一部分，C 不是超键，A 显然不是子集。

对于 R2，BCNF 的规则是：

X → Y 是一个平凡的函数依赖 (Y ⊆ X)

X 是模式 R 的超级键

并且 E->D = E 不是超键，D 也不是 E 的子集。

答案是错误的还是我遗漏了什么？

非常感谢！

关系模式 R (ABCD)
功能依赖是：
AB -> D
CB -> D
A-> C
C -> A
最高范式 ???

我的理解 ：

候选键 = AB和BC

创建表时 AB 和 BC 都不能视为主键。那么让我们一一来吧。

对于键 AB ：
AB -> D ( Fully Functional Dependency , so no problem )
CB -> D ( ??? )
A -> C (partial Functional Dependency , as left side contains only part of key)
C -> A ( Functional Dependency , So no problem )

对于钥匙 BC

现在通过两个键，关系包含部分功能依赖。
那么它不应该在2NF中。
但答案是 3NF。
请纠正我。