【问题标题】:Determining candidate keys with functional dependencies simple确定具有功能依赖关系的候选键很简单
【发布时间】:2012-11-29 15:57:07
【问题描述】:

设R(A,B,C,D,E)为关系模式,F = {A→C, B→D, C→E, E→A},找出所有候选键。

由于无法映射,我认为此系列中不存在 CK。 B 或 D 除了 B -> D 之外的任何其他关系。这是否意味着没有候选键?虽然我能够将 A 映射到除 B 和 D 之外的所有其他实体。

【问题讨论】:

  • 每个关系 [schema] 总是至少有一个候选键。因此,如果您在任何练习中都认为结论是“这里没有钥匙”,那么您就错了。

标签: database relational-database functional-dependencies


【解决方案1】:

标准化的第一步是找到关系的所有键。以下是一些有助于找到钥匙的事实:

  1. 如果一个属性不在任何 FD 中,那么它在每个键中。

  2. 如果某个属性出现在 FD 的右侧,但从未出现在左侧,则它永远不会出现在键中。

  3. 如果某个属性出现在 FD 的左侧,但从未出现在右侧,则它存在于每个键中。

  4. 如果某个属性同时出现在 FD 的右侧和 FD 的左侧,则无法说明该属性。

要查找键,请确定上述每种情况下的属性。第一种和第三种情况中的那些必须在每个键中。称这组属性为核心。计算由核心确定的属性。这称为核心的闭合。如果所有的属性都在封闭的核中,那么核不仅是一把钥匙,它也是唯一的钥匙。如果关闭的核心不是整个属性集,那么就会丢失一些。写下这组属性,并删除上面第二组中的任何属性(即,它出现在 FD 的右侧,但从不出现在左侧)。这些是外在属性。要获得一把钥匙,必须向核心添加一个或多个外部属性。因此,将它们添加到核心,一次添加一个,然后一次添加两个,以此类推,直到找到每个键。

【讨论】:

    【解决方案2】:

    共有三个候选键。

    B 不会出现在任何函数依赖项的右侧。这意味着 B 必须是每个候选键的一部分。我认为单独并不能保证至少有一个候选键,但是通过检查应该清楚AB是这里的三个候选键之一。

    您的教科书应至少包含一种算法,用于确定所有候选键的集合。如果幸运的话,它包括一种适用于纸和铅笔的算法,以及另一种适用于通过编程实现自动化的算法。

    【讨论】:

    • 感谢您的澄清,我已确定 AB 、 CB 和 EB 是我的问题的候选键。
    • 没错。三个候选键是 AB、BC 和 BE。教科书作业传统上按字母顺序排列属性名称,但属性顺序在关系模型中实际上没有意义。
    【解决方案3】:

    由于 B 不在右手边,所以 B 应该是候选键的一部分,并且 A 和 C 出现在两侧,因此它们可以与 B 形成超级键。在映射上 AB 和 BC 是超级键并且因为候选键是最小的超级键,所以 AB 和 BC 是候选键。

    【讨论】:

      【解决方案4】:

      在所有功能依赖项中严格仅位于左侧的每个属性都是必须构成每个候选键的一部分的属性。

      下一步是实现单独这样一个属性是否可以生成,或者确定模式内的所有属性。如果是,则该属性是其原始独立形式的候选键。如果不是,则将该属性与其他每个属性分组,一次一个,一次两个,依此类推。所有这些遍历整个属性集的最小集合都可以称为候选键

      【讨论】:

        猜你喜欢
        • 2011-12-08
        • 1970-01-01
        • 2021-10-30
        • 2016-03-26
        • 2012-12-17
        • 2018-08-24
        • 2021-09-10
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多