假设我们有一个关系:
病人决定医生,医院决定医生,医生决定医院。我们如何将其分解为 BCNF?
{医生,病人}, {病人,医院} 或
{医生, 医院 }, {病人,医院} 或
{医生, 医院 }, {医生 , 病人}
根据我对关系的理解,它必须是 3NF,如果 X → Y 在 R 中成立,则关系中的每个依赖项必须满足以下条件之一:X → Y 在功能上是平凡的依赖 X 是 R 的超键。
那么 { Doctor , Hospital}, { Doctor, Patient } 会是正确的选择吗?
假设我们有一个关系:
病人决定医生,医院决定医生,医生决定医院。我们如何将其分解为 BCNF?
{医生,病人}, {病人,医院} 或
{医生, 医院 }, {病人,医院} 或
{医生, 医院 }, {医生 , 病人}
根据我对关系的理解,它必须是 3NF,如果 X → Y 在 R 中成立,则关系中的每个依赖项必须满足以下条件之一:X → Y 在功能上是平凡的依赖 X 是 R 的超键。
那么 { Doctor , Hospital}, { Doctor, Patient } 会是正确的选择吗?
首先,我认为你误解了这个数字。其中使用的符号通常被解释为描述以下两个函数依赖关系:
Patient, Hospital → Doctor (1)
Doctor → Hospital (2)
功能依赖 (1) 意味着为某个医院的每个患者分配一个唯一的医生,而 (2) 意味着每个医生在一个唯一的医院工作。在你的解释中,相反,每个医院都唯一确定一个医生,即任何医院只有一个医生!
因此,鉴于上述解释,让我们看看关系是否在 BCNF 中。如果每个行列式都是(超)键,则关系在 BCNF 中,并且很明显是依赖关系:
Doctor → Hospital
违反了这个条件,因为 Doctor 不是超级键(即它不能确定所有属性)。事实上,这种关系有两个候选键:(Patient, Hospital) 和 (Patient, Doctor)。
因此,BCNF 中这种关系的分解如下:
R1 <(Doctor, Hospital), { Doctor → Hospital }>
R2 <(Doctor, Patient), { }>
(所以你的猜测是正确的)。
但是请注意,这种分解有一个令人不快的特性:函数依赖的丢失!其实依赖:
Patient, Hospital → Doctor
丢失,也就是说它在生成的数据库中无法执行。这意味着可以将有关患者的信息插入到患者所在的医院之外的医生中!
最后请注意,由于 Doctor 是一个主要属性(即它属于候选键),初始关系已经在 3NF 中。