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