Database 在这个表中可以找到4个不同的函数依赖项吗？

我的教授让我在下表中找出4种不同的函数依赖关系：

公司（公司名称、街道地址、城市、邮编、州、首席执行官姓名）

“他还指出：每家公司都有一个不同的（唯一的）地址，意思是（街道、城市、邮编、州）一起构成一个键。不同的公司可能有相同的名字。每家公司只有一个CEO，一个人不能是多家公司的CEO。CEO的名字可能不唯一（可能有两个CEO同名）。要在具有属性（a、B、C、D）的表中计算4个函数依赖项：如果a->B，则显然a、C->B也是。这不应算作两个独立的依赖项。另一方面，a->B和a->C应算作两个不同的函数依赖项。”

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

首席执行官，公司名称->（街道地址，城市，邮编，州）

压缩->状态

---

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

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

每个公司都有不同的（唯一的）地址含义（街道、地址、城市、邮政编码、州）一起构成一个键

根据定义，这把钥匙意味着

• 街道地址、城市、邮政编码、州->首席执行官姓名
• 街道地址、城市、邮政编码、州->公司名称

这就是候选人的所有可能的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恰巧有着相同的名字。这符合FDs的描述，但清楚地表明{Company_Name，CEO_Name}不是候选密钥。伪造的数据还清楚地表明，{Company_Name，CEO_Name}不能是函数依赖项的左侧。给定{Company_Name，CEO_Name}的单个值，其他属性都没有且只有一个值

在删除了左边的属性Company_Name和CEO_Name之后，要“制造”另外两个功能依赖项的唯一方法是在候选关键字{Street_Address，City，Zip，State}中找到它们。不是因为候选密钥有什么特殊之处，而是因为这些是唯一剩下的属性

我猜你的老师希望你说

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

在美国（在“真实”世界中），“Zip->城市，州”不适用。邮政编码与运营商的路线和邮件递送方式有关；邮政编码与地理无关。一些城市（和邮政编码）跨越州边界。相当多的邮政编码横跨一个州内相邻的城市。随着美国邮政削减预算，我预计此类邮政编码的数量会增加

---

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

非常感谢你的回答！：）ZIP->State不是可传递的依赖项？因为城市->国家？？或者它不是一个可传递的依赖关系，因为在不同的州可以有同名的城市？？可传递的依赖关系是在非素数属性上定义的。你必须指出“（街道、地址、城市、邮政编码、州）一起构成一个键”意味着它们构成一个超级键，而不是候选键。候选密钥是不可约超密钥；如果

ZIP->City，State

，则有一个可简化的超键，而City和State并不是真正的主要属性。