我有点卡住设计数据库的一部分。
我有一张名为Staff的表格。它有不同的属性：
StaffID
First Name
Last Name
Job Title
Department Number
Telephone Number
StaffID是此表中的主键。
我的问题是，可以根据电话号码找到任何信息（即每个工作人员都有不同的，唯一的电话号码）。
例如，这意味着当我们拥有First Name时，可以找到Job Title或Phone Number。但是，Phone Number不是主键，StaffID是。
我不确定这是否是一个传递依赖，并且应该通过分割表并使Staff table没有Phone Number而另一个表只有StaffID和{而通过3NF来修复{1}}。
答案 0 :(得分：1)
只有当两个以上不属于键的属性之间存在间接关系时，才会发生传递依赖。
在您的示例中，如您所解释的，StaffID是您的依赖项的一部分，这很好，因为它是主键。
另外，您可以查看显示传递依赖项错误的this问题。它可能有助于把事情放在眼里。
在您的表格中，如果您删除了工作人员，则会删除所有信息（这是因为您不需要它）。如果您将电话号码留在另一个表格中，例如，仅在Staff中删除条目，则会留下一个狂野的电话号码。但是，如果您的Staff表允许同一个人（但不同的部门）有多个条目，那么情况会有所不同。
过去帮助我的其他网站：
https://www.thoughtco.com/transitive-dependency-1019760 https://beginnersbook.com/2015/04/transitive-dependency-in-dbms/
有趣的是，他们总是遵循书中的例子：）
答案 1 :(得分：1)
在设计理论术语中，键是由依赖关系隐含的。如果PhoneNumber→StaffID和StaffID已知是密钥，那么我们可以推断出PhoneNumber也是一个密钥。如果是这种情况，则不会违反3NF，因为决定因素都是密钥。请注意，在此处选择StaffID作为主键是无关紧要的。规范化将所有键视为同等重要。
然而，在实际的数据库设计中，出现的问题是PhoneNumber是否真的有意义作为关键。换句话说，你真的想要强制执行像PhoneNumber→StaffID这样的依赖吗？如果在考虑之后，您决定依赖性不适用，那么您可以放弃该依赖关系（通过不将PhoneNumber作为密钥），并且该表仍将满足您已经离开的依赖关系集的3NF。
这就是为什么像PhoneNumber→StaffID这样的依赖可能不是一个现实的选择：当我加入现在的公司时，我第一天就得到了员工ID;直到两天后我才收到电话号码。
答案 2 :(得分：0)
这不是因为手机与姓名或姓氏之间没有依赖关系，如果你知道你不能知道电话号码的名字，那就不一样了，例如，型号和制造商，如果你知道模型是野马然后你知道制造商是福特，而其他方式，你知道福特是野马
对于您提到的列，我将为部门和职称分别设置表，因为它们不依赖于PK StaffID。把它想象为删除潜在的冗余，你可以在那里拥有五千人，并将作业标题重复一千次，这是一个需要自己的表（2NF）的信号。
答案 3 :(得分：0)
传递依赖性意味着您具有（一组）属性，这些属性完全由来自（一组）属性A - >的一组确定。 B然后从B - >; C，而你不能从B - >;甲
在你的情况下，你确实有（StaffId） - ＆gt; （PhoneNumber）和（PhoneNumber） - ＆gt; （STAFFID是）。这意味着你有A - ＆gt; B和B - ＆gt; A因此在这一步你已经可以排除传递依赖。
如果您愿意，可以说PhoneNumber将成为PK的另一个候选人。
作为背景，传递依赖的问题是这样的：假设你有一个由＆＃34; Book Title＆＃34;组成的表。 （主键），＆＃34;作者＆＃34;和＆＃34;作者的性别＆＃34;。那你肯定有一个传递依赖BT - ＆gt; A，A - ＆gt; GoA，因此BT - ＆gt;果阿
现在假设你的一位作者是＆＃34; Andy Smith＆＃34;，Andy是Andreas的简称。安德烈亚斯去改变性别，现在是安德里亚。显然你不需要改名，＆＃34; Andy＆＃34;适用于＆＃34; Andrea＆＃34;。但你必须改变性别。您必须为表格中的许多条目（即该作者的所有书籍）执行此操作。
在这种情况下，您可以通过创建一个新表来解决问题＆＃34;作者＆＃34;，显然，然后您只有一行安迪。
希望清除它。很容易看出，在您的示例中，由于电话号码的更改，您不得不更改许多行的星座。这是StaffId和PhoneNumber之间简单的1：1关系，没有任何问题。两者都是候选键。