尝试标准化为 BCNF

Question

我不确定这是否在BCNF中，但老师告诉我INSTRUMENT在BCNF中。他是在逗我吗？老师总是让我分不清是非，让我不确定。他一直在说一些我已经想得很清楚的事情，但我什至不明白他在说什么。

INSTRUMENT（InstrumentID、 InstrumentType、调音、表演者、Adr、电话、可用性） 注释(TitleNr,Tune,作曲家、副本、标题、表演者)

那么这是标准化的吗？在 BCNF 中：

乐器（InstrumentID、InstrumentType、Tune、可用性、PerformerID*）
注释（TitleNr、标题、 曲调、作曲家、副本、表演者 ID*）
PERFORMER（PerformerID、姓名、地址、电话）

Tune 位于 INSTRUMENT 和 Notes 中。两者都可以吗？

Answer 1

每个范式都需要其前面的范式。

1 NF - 您的表只有原子值，即没有集合。

2 NF - 非密钥属性要求确定密钥的每个部分。

3 NF - 非关键属性除了要确定的关键之外不需要任何其他内容。

3.5 NF - 如果非键属性可以确定键属性，则它们必须创建唯一的元组。

我首先关心的是 TitleNr 代表什么。如果它是唯一 ID，则它不是 2 NF，因为非关键属性不需要确定标题。

我的第二个问题是，如果包含 Tune，则 InstrumentID 不是正确的候选键。如果 Instrument.Tune 代表该特定乐器演奏过的乐曲，则一台乐器可以演奏多首乐曲。最好将这些属性拆分到另一个表中，否则其他非关键属性将使其不是 2 NF。

如果它仅仅代表可用的曲调，那么它已经可以由 PerformerID 确定，而 PerformerID 不是乐器密钥的一部分。那么就不是3NF了。

Answer 2

标准化适用于单个表；它基于功能依赖性。

函数依赖性由数据决定，而不是由列名决定。你的老师没有给你任何数据。尝试仅通过列名称确定功能依赖关系是有风险的事情，即使列命名得很好。你的专栏命名不好。

富有想象力的数据库设计者可能会为演示 BCNF 的第一个“Instruments”表提出谓词和示例数据。

也许你的导师也不懂这些东西。不会是第一个。

Answer 3

它是 2NF，而不是 BCNF。

乐器（乐器 ID、乐器类型、调音、表演者、地址、电话、
可用性）

您确实需要了解功能依赖性，但猜测一下，我会说 adr 和 phone 是表演者的属性，而不是乐器的属性。如果属性没有（完整地）描述密钥，那么它就不是 BCNF。

假设每位表演者至多有一个电话号码和地址。如果是这样，您将具有功能依赖性：

Performer -> phone, adr

也就是说，可能有多个乐器与同一表演者关联，但在每种情况下，他们的电话和地址都是相同的（因此被冗余记录）。
我猜测乐器关系的关键是 InstrumentId，因此还有一个 FD 表示每个乐器最多关联一个表演者；

InstrumentId -> Performer

既然如此，属性 phone 和 adr 并不直接依赖于 InstrumentId，而是通过 Performer 间接依赖。因此，在这种关系中，FD表演者-> phone, adr 是一个传递依赖。根据定义，任何包含传递依赖关系的关系都不能高于 2NF（第二范式）。所以它不属于 3NF，也不属于 BCNF。

2NF 不允许部分依赖。好消息是，由于键只是一个属性，因此您不必担心此处的部分依赖关系：您不能拥有单个属性的一部分。