主页 / dba / 问题 / 289717
Accepted
Naja
Asked: 2021-04-13 23:55:40 +0800 CST

如何识别功能依赖关系并根据属性规范化表？

  • 772

我无法识别构成特定表的功能依赖关系（FD）的属性组合。虽然我了解在给定 FD 时规范化过程是如何工作的，但我无法翻译和识别给定表的 FD。

我的任务是创建一家公司的数据库，用于跟踪销售/包裹等的所有费用。这自然意味着为公司存储客户信息以识别所有消费者。

CREATE TABLE Customers (
    id        integer primary key,
    address   text not null,
    name      text not null,
    email     text unique not null,
    phone     text unique not null,
    unique(name, address)
);

鉴于每个电话号码和电子邮件都与客户唯一关联，因此我选择代表客户表的信息。唯一约束允许来自同一家庭地址的多个人出现在表中。

我想看看我是否可以进一步规范化这个表，但是我无法识别属性来确定所需的 FD。

normalization dependencies

1 个回答

  1. Best Answer

    当且仅当 Y 由 X唯一确定时，一组属性 Y 在功能上依赖于另一组 X ，也就是说，您不能有两个不同的 Y 值与 X 的相同值相关联。因此，例如，假设电话number 始终只与一个人相关联，并且一个人始终只有一个地址，您可以说函数依赖phone -> address成立，因为给定某个电话号码，只有具有该号码的人的地址才能与其一起出现.

    因此，函数依赖以正式的方式指定了在您的数据库中建模的现实的一个重要事实。

    函数依赖的一个问题是你可以有很多，即使是小的关系。解决这个问题的一个聪明的方法是只定义一小组依赖关系，足以“捕获”关于某个现实的所有基本信息，因为我们可以以机械的方式从这个集合中导出所有其他依赖关系（并且有可以做到这一点的程序，例如通过应用著名的“阿姆斯特朗公理”）。然而，有时定义这样的“基本”函数依赖集并不容易，我们必须仔细查看我们正在建模的问题的规范。

    通常我们从所谓的“候选键”开始，即在关系中“自然”唯一的属性或属性集。由于它们是独一无二的，我们知道它们决定了所有其他属性。在您的示例中，您已经确定了四个候选键，id（主键）(name, address)、phone和email（已声明unique），所以我们已经可以这样说：

    id -> name, address, email, phone
name, address -> id
phone -> id
email -> id

    （注意，一个属性决定了一个候选键就足够了，因为从这个事实我们可以得出它决定了所有其他属性，即它唯一地决定了一个人）。

    然后我们可以查看属性组合中的某个其他属性是否唯一确定了其他属性或候选键（相当于确定了所有其他属性）。

    您的关系中还有其他（非平凡的、有趣的）函数依赖关系吗？可能不是，考虑到数据的明显语义（例如，两个不同的人可以有相同的地址，所以一个地址不能“唯一确定”任何东西，或者两个不同的人可以有相同的名字，等等）。因此，我们可以有一定程度的信心，这四个 FD 是 FD 的“基本”集合（从技术上讲，这称为关系的 FD 集合的“覆盖”）。

    所以从这个封面我们可以开始规范化关系（在这种情况下已经规范化了）。

    • 1

相关问题