问题标签 [3nf]

假设一个关系模式R(A,B,C)和 FD 是

{A -> B, B -> C}

所以超级键是{A}, {A,B}

现在如果我们把它分解成3NF它将是

R1(A,B) 与 FD {A -> B} 和 R2(B,C) 与 FD {B -> C}

是在BCNF吗？我无法确定。既然B不是超级键in违反BCNF吗R？{B -> C}R2

我一直在阅读许多关于如何区分 3NF/BCNF 中的关系的不同资料。到目前为止，这是我的理解......

我将以这种关系为例...

R = {A, B, C, D, E}

和

F = {A -> B, B C - > E, E D -> A}.

首先，我们必须找到关系的键。我用这个视频来帮助我做到这一点。我得到了

Keys = {ACD, BCD, CDE}

现在要确保R在BCNF中，我们必须确保每个函数依赖项的左侧F都是Keys. 我们立即知道情况并非如此，因为第一个 FD 是A -> B并且A不是键之一。所以它不在 BCNF 中。

现在要确保R在3NF中，我们必须确保 in 中的每个功能依赖项的左侧F是其中一个，Keys 或者每个功能依赖项的右侧是其中F之一的子集Keys。如果您查看每个 FD 的右侧，它们B是E和A。这些都是 a 的子集Key，因此这意味着它在 3NF 中。

所以这是关系存在3NF但不在. BCNF这种方法正确吗？它可靠吗？我错过了什么吗？

这是我的ERD：

我试图规范化这个 ERD，下面是我到目前为止所做的：

我正在尝试规范化到第 3 范式，所以基本上我正在尝试实现功能依赖并消除过渡依赖。我有一些令我困惑的问题：

1. 在飞机表中，品牌和型号应该保持原样还是应该转移到新表中？
2. 在 Airport 表中，我应该将 ICAO 和 IATA 代码标识符转移到新表吗？
3. 航空公司表中的 IATA 和 ICAO 也是如此。
4. 考虑到 3NF，经理表是否需要任何更改？

问候

早安伙计们，

我正在努力查看如何将这些下表分解为 3NF，我知道基于规范化的规则，但看不到任何需要在此处移动的数据是表的外观：

PlaylistID, PlaylistName, TrackID, Trackname, AlbumID, AlbumTitle, GenreID, GenreName, TrackSeconds, TrackBytes

考虑以下关系模式：

我正在尝试完全规范化（以第三范式）并确定功能依赖关系。但是，通过无休止的研究，我无法解决如何：

1. 完全规范化关系模式
2. 确定功能依赖关系

我该怎么办？

我在一次采访中被问到这个问题。

在数据库中使用第三范式有什么缺点？
我知道它的主要优点是

1. 减少重复
2. 数据完整性

使用第三范式有什么缺点吗？

如果我们有一个关系模式 R(A, B, C, D)，具有一组依赖项：

如何将 R 分解为 BCNF 关系？唯一可行的方法似乎是丢弃其中一个 FD，不管我怎么想。还有其他方法吗？

我计划使用这个 SQL 模式来存储/生成各种运动的统计数据和球员数据。我想让它尽可能地不可知，但鉴于每项运动都有不同的得分和游戏玩法指标，我不得不在最后分解它。

我被困在这个问题上。这个问题的答案应该是什么：

关系方案 Student Performance (name, courseNo, rolINo,grade) 具有以下函数依赖关系：
name, courseNo, ->grade
rolINo, courseNo ->grade
name -> rolINo
rolINo -> name

这种关系方案的最高范式是

(a) 2 NF (b) 3 NF (c) BCNF (d) 4 NF

拥有这个数据库..需要识别部分和传递依赖...并为第 3 范式创建新表..我不知道我的回答是否正确，但有人可以帮助我吗？这是桌子。。

你能告诉我我的部分依赖是否正确..

member_num-

member_name,member_add,member_city,member_zipcode.....

邀请号码-

邀请日期，接受日期，晚餐日期，晚餐参加...

晚餐代码->晚餐描述..

主菜代码->主菜描述..

甜点代码->甜点描述..

我想我必须为第三范式创建新的属性和表格..但我对此很困惑..