【问题标题】:How to decompose a relation into BCNF?如何将关系分解为 BCNF?
【发布时间】:2016-04-10 20:50:33
【问题描述】:

假设我们有一个relation,其中:

病人决定医生,医院决定医生,医生决定医院。我们如何将其分解为 BCNF?

{医生患者}、{患者医院}或

{医生、医院}、{患者医院}或

{医生,医院},{医生,患者}

在我对关系的理解中,它必须是 3NF,如果 X → Y 在 R 中成立,则关系中的每个依赖项都必须满足以下条件之一:X → Y 在函数上是微不足道的依赖 X 是R.

那么 {Doctor, Hospital}、{Doctor, Patient} 会是正确的选择吗?

【问题讨论】:

  • 一个关系“不需要在 3nf 中”加上其余的都在 BCNF 中;其余的保证 BCNF (& 3NF)。虽然你已经把剩下的弄乱了。因此,请查找 BCNF 的定义并编辑您的问题..

标签: dependencies key relation functional-dependencies bcnf


【解决方案1】:

首先,我认为你误解了这个数字。其中使用的符号通常被解释为描述以下两个函数依赖关系:

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中。

【讨论】:

    猜你喜欢
    • 2018-03-20
    • 1970-01-01
    • 1970-01-01
    • 2014-11-24
    • 1970-01-01
    • 2013-03-08
    • 2012-12-14
    相关资源
    最近更新 更多