我不确定这是否在 BCNF 中，但是老师告诉我INSTRUMENT在 BCNF 中.. 他在惹我吗？老师总是在什么是对什么是错上搞乱我的想法，让我不确定。他一直在说我已经清楚地想到的东西，我什至不明白他在说什么。
INSTRUMENT ( InstrumentID,InstrumentType, Tune, Performer, Adr, Phone, Availability)
NOTES ( TitleNr,Tune,Composer, Copies, Title, Performer)
那么这是标准化的吗？在 BCNF 中：
乐器( InstrumentID, InstrumentType, Tune, Availability, PerformerID*)
NOTES ( TitleNr, Title,Tune, Composer, Copies, PerformerID*)
PERFORMER ( PerformerID, Name, Adr, Phone)
调子在 INSTRUMENT 和 NOTES 中都有。两者都可以吗？
规范化适用于单个表；它基于功能依赖关系。
功能依赖是由数据决定的，而不是由列名决定的。你的导师没有给你任何数据。尝试仅通过列名来确定功能依赖关系是有风险的，即使列名得当。您的列命名不正确。
一个富有想象力的数据库设计者可能会为第一个演示 BCNF 的“仪器”表提出一个谓词和示例数据。
也许你的导师也不理解这些东西。不会是第一个。
每个范式都需要它前面的范式。
1 NF - 你的表只有原子值，即没有集合。
2 NF - 非密钥属性需要确定密钥的每个部分。
3 NF - 非关键属性不需要任何东西，但要确定关键。
3.5 NF - 如果一个非关键属性可以确定一个关键属性，他们必须创建一个唯一的元组。
我首先关心的是 TitleNr 代表什么。如果它是唯一 ID，则它不是 2 NF，因为非关键属性不需要确定 Title。
我的第二个担心是，如果包含 Tune，则 InstrumentID 不是合适的候选键。如果 Instrument.Tune 表示使用该特定乐器演奏的曲调，则一种乐器可以演奏多种曲调。最好将这些属性拆分到另一个表中，否则其他非关键属性将使其不是 2 NF。
如果它仅表示可用的 Tunes，则可以由 PerformerID 确定，它不是 Instrument 密钥的一部分。那么它不是3 NF。
它在 2NF 中，而不是 BCNF。
INSTRUMENT（InstrumentID、InstrumentType、Tune、Performer、Adr、Phone、Availability）
您确实需要知道功能依赖关系，但猜测一下，我会说adr和phone是表演者的属性，而不是乐器。如果属性不能（完整地）描述密钥，那么它不是 BCNF。
假设每个表演者最多有一个电话号码和地址。如果是这样，您将具有功能依赖性：
Performer -> phone, adr
也就是说，可能有多个乐器与同一表演者相关联，但在每种情况下，它们的电话和地址都是相同的（因此被冗余记录）。我猜 Instrument 关系的关键是InstrumentId，所以还有一个 FD 说每个乐器最多关联一个演奏者；
InstrumentId -> Performer
既然如此，属性phone和adr不直接依赖InstrumentId，而是通过间接依赖Performer。因此，在这个关系中，FDPerformer -> phone, adr是一个传递依赖。根据定义，任何包含传递依赖关系的关系都不能高于 2NF（第二范式）。所以它不在 3NF 中，也不在 BCNF 中。
2NF 不允许部分依赖。好消息是，由于键只是一个属性，因此您不必担心这里的部分依赖关系：您不能拥有单个属性的一部分。