Question

我不确定这是否在BCNF，但是老师告诉我， INSTRUMENT 在BCNF。他在跟我说话吗？老师一直在弄乱我的想法是什么是对错，让我不确定。他一直在说我已经想到的东西，我甚至没有得到他说的话。

INSTRUMENT （InstrumentID, InstrumentType，Tune，Performer，Adr，Phone，Availability）注意（TitleNr,Tune,作曲家，副本，标题，表演者）

这是规范化的吗？在BCNF：

工具（InstrumentID，InstrumentType，Tune，Availability，PerformerID *）
注意（TitleNr, Title, Tune，Composer，Copies，PerformerID *）
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。

如果它仅表示可用的Tunes，那么PerformerID就已经可以确定，而PerformerID不是乐器键的一部分。那么它不是3 NF。

Answer 2

规范化适用于单个表格;它基于功能依赖。

功能依赖性由数据决定，而不是由列名决定。你的导师没有给你任何数据。试图通过列名确定功能依赖性是一项有风险的业务，即使列名称很好。您的列名称不太好。

富有想象力的数据库设计师可能会为第一个演示BCNF的“仪器”表提供谓词和样本数据。

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

Answer 3

它在2NF，而不是BCNF。

INSTRUMENT（InstrumentID，InstrumentType，Tune，Performer，Adr，Phone，定）

你真的需要知道功能依赖性，但猜测我会说adr和phone是表演者的属性，而不是乐器。如果属性没有描述密钥（完整地），那么它不是BCNF。

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

Performer -> phone, adr

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

InstrumentId -> Performer

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

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

试图规范化为BCNF

3 个答案: