1

我的教授要求在下表中找到 4 个不同的函数依赖项：

公司（Company_Name、Street_Address、City、Zip、State、CEO_Name）

“他还给了一个注释：每个公司都有不同的（唯一的）地址含义（Street_Address、City、Zip、State）共同构成一个密钥。不同的公司可能有相同的名称。每个公司只有一个 CEO，而一个人不能担任多个公司的 CEO。CEO 的名字可能不唯一（可能有 2 个 CEO 同名）。用属性（A、B、C、D）计算一个表中的 4 个函数依赖关系：如果 A -> B 然后显然 A, C -> B 也是如此。这不应该算作 2 个独立的依赖项。另一方面，A -> B 和 A -> C 应该算作 2 个不同的功能依赖项。

但在我看来，没有 4 个函数依赖。

  1. CEO，公司名称 ->（街道地址、城市、邮编、州）
  2. 压缩 -> 状态

但由于两家公司可以具有相同的名称，因此还应该有一个主键，例如“Company_Number”。但是创建已知表不是任务......

4

1 回答 1

0

函数依赖回答了这样一个问题：“给 X 一个单一的值，我们是否只知道一个 Y 的值？” Eitehr X 或 Y 可能是属性集，而不仅仅是单个属性。阅读此答案时请记住这一点。

每个公司都有不同的（唯一的）地址含义（Street_Address、City、Zip、State）共同构成一个密钥。

根据定义，该键意味着

  • Street_Address、城市、邮编、州 -> CEO_Name
  • Street_Address、城市、邮编、州 -> Company_Name

这就是候选键 {Street_Address, City, Zip, State} 的所有可能的 FD。四个中的两个——中途回家。

您将 {CEO_Name, Company_name} 标识为函数依赖项的左侧。在这种特殊情况下，您还将其标识为候选键。让我们看一些虚构的数据。

Company_Name  CEO_Name    Street_Address  City      State  Zip
--
Wibble, Inc.  Mary Smith  123 E Main St   Anytown   PA     00001
Wibble, Inc.  Mary Smith  456 S Darn St   Sometown  WY     10000

该数据描述了两个碰巧同名的不同公司，有两个不同的 CEO 碰巧同名。这符合 FD 的描述，但清楚地表明 {Company_Name, CEO_Name}不是候选键。伪造的数据还清楚地表明 {Company_Name, CEO_Name} 不能是函数依赖的左侧。给定 {Company_Name, CEO_Name} 的单个值，对于任何其他属性，我们没有一个且只有一个值。

消除了作为左侧可能性的 Company_Name 和 CEO_Name 属性后，“制造”另外两个函数依赖项的唯一方法是在候选键 {Street_Address, City, Zip, State} 中找到它们。不是因为候选键有什么特别之处，而是因为这些是唯一剩下的属性。

我的猜测是你的老师希望你说

  • 邮编 -> 城市
  • 邮编 -> 状态

在美国（在“真实”世界中），“Zip -> City, State”不成立。邮政编码与承运人如何驾驶他们的路线和递送邮件有关；邮政编码与地理无关。一些城市（和邮政编码）跨越州界。相当多的邮政编码跨越一个州内的相邻城市。随着 USPS 削减预算，我预计此类邮政编码的数量会增加。

但在学术界，由于教学原因，这种现实世界的行为常常被忽视。这就是为什么我敢打赌你的老师期待 {Zip -> City, State}。

于 2013-06-01T14:31:24.870 回答