3NF 中的规范化是否适用于由多个候选键组成的模式？
Is normalization in 3NF applicable on a schema consisting of multiple candidate keys?
我有一个包含以下属性的关系：
Employee:
Emp_Id(Primary Key), Name, E_mail, Phone_Number, Date_Of_Joining, Address
我假设两个人可以拥有相同的 Name 或 Address， 但 不相同 E_mail 或 Phone_Number's（即它们应该是唯一的）。
所以，根据我所知道的规范化table；我需要将 E-mail 和 Phone_Number 信息分开成单独的 table （对于 3NF）：
来自 3NF:
The third normal form (3NF) is a normal form used in database
normalization. 3NF was originally defined by E.F. Codd in 1971.[2]
Codd's definition states that a table is in 3NF if and only if both of
the following conditions hold:
- The relation R (table) is in second normal form (2NF)
- Every non-prime
attribute of R is non-transitively dependent on every key of R.
所以我将主要的 table 分成这些结果 tables:
E_Mail Information: E_Mail_Id(Primary Key), E_Mail Address, ...
Contact/Phone Number Information: Phone_Id(Primary Key), Phone_Number, ...
（新）Employee:
Emp_Id(Primary Key), Name, E_mail_Id(foreign key), Phone_Number_Id(foreign key), Date_Of_Joining, Address
我的问题是
如果不划分上面给出的关系来实现3NF，我们是否可以让Employee保持原样而没有运行出问题了(这个问题只是针对我上面描述的例子)?
即使在除掉 table 之后，我们也可能有值，尽管外键是唯一的（由于一对一关系），因此被视为候选键（新)Employee 关系是 E_mail_Id 和 Phone_Number_Id。那么他们不会违反 3NF 吗？
重申你的假设
这并不是为了改变您的假设，而只是为了澄清它们。
您有一个关系模式：
Employee: Emp_Id, Name, E_mail, Phone_Number, Date_Of_Joining , Address
并且您为了这个问题的目的规定：
- 每位员工都有一个唯一的电子邮件地址。
- 每位员工都有一个 phone 号码，这对他们来说是独一无二的。
因此，对于此架构，您有三个 'prime attributes'（以 Codd 的表示法表示）或三个候选键：
Emp_IdE_mailPhone_number
给定一个员工ID，唯一确定该员工；给定 phone 编号，员工是唯一确定的；给定电子邮件地址，员工是唯一确定的。
你的关系模式是 3NF
如果以上所述是对关系模式的正确解释，那么您对 "I need to separate E-mail and Phone_Number information into a separate table (for 3NF)" 的观察是错误的。没必要分开。
在规定的条件下，你的关系模式已经是3NF；实际上，它也是 BCNF（Boyce-Codd 范式）。关系是 2NF，没有传递依赖。
问题 1 的答案
是的 — 您可以保留 table 原样，因为它已经在 3NF 中。
问题 2 的答案
否 — 因为 3NF 不需要单个候选密钥，您似乎认为这是必要的。此外，没有特别要求将电子邮件 ID 存储在主 table 中；电子邮件地址 table 将有一个主键，即员工 ID，不需要电子邮件 ID 号，因为电子邮件地址对员工来说是唯一的（根据此问题的参与规则）。 phone 数字也是如此。
在实践中，员工可能有多个电子邮件地址，并且可能有多个 phone 号码，即使只是供他们私人使用（与公司电子邮件地址和公司 phone 号码分开）。在这种情况下，您将有一个特定员工的 'non-empty list of email addresses' 和一个 'non-empty list of phone numbers'，然后您将需要单独的 table 来记录它们。 Phone号是Phone信息table的主键，Employee ID是phone号table中的FK；电子邮件地址将是电子邮件 table 的主键，员工 ID 将是电子邮件地址 table.
中的外键
您的关系模式必须以某种方式列出这些多个条目，这不会是 1NF，更不用说 2NF 或 3NF（在一些关于如何表示列表的合理假设下）。 'non-empty' 标准需要谨慎执行。
我有一个包含以下属性的关系：
Employee:
Emp_Id(Primary Key), Name, E_mail, Phone_Number, Date_Of_Joining, Address
我假设两个人可以拥有相同的 Name 或 Address， 但 不相同 E_mail 或 Phone_Number's（即它们应该是唯一的）。
所以，根据我所知道的规范化table；我需要将 E-mail 和 Phone_Number 信息分开成单独的 table （对于 3NF）：
来自 3NF:
The third normal form (3NF) is a normal form used in database normalization. 3NF was originally defined by E.F. Codd in 1971.[2] Codd's definition states that a table is in 3NF if and only if both of the following conditions hold:
- The relation R (table) is in second normal form (2NF)
- Every non-prime attribute of R is non-transitively dependent on every key of R.
所以我将主要的 table 分成这些结果 tables:
E_Mail Information: E_Mail_Id(Primary Key), E_Mail Address, ...
Contact/Phone Number Information: Phone_Id(Primary Key), Phone_Number, ...
（新）Employee:
Emp_Id(Primary Key), Name, E_mail_Id(foreign key), Phone_Number_Id(foreign key), Date_Of_Joining, Address
我的问题是
如果不划分上面给出的关系来实现3NF，我们是否可以让
Employee保持原样而没有运行出问题了(这个问题只是针对我上面描述的例子)?即使在除掉 table 之后，我们也可能有值，尽管外键是唯一的（由于一对一关系），因此被视为候选键（新)
Employee关系是E_mail_Id和Phone_Number_Id。那么他们不会违反 3NF 吗？
重申你的假设
这并不是为了改变您的假设，而只是为了澄清它们。
您有一个关系模式：
Employee: Emp_Id, Name, E_mail, Phone_Number, Date_Of_Joining , Address
并且您为了这个问题的目的规定：
- 每位员工都有一个唯一的电子邮件地址。
- 每位员工都有一个 phone 号码，这对他们来说是独一无二的。
因此，对于此架构，您有三个 'prime attributes'（以 Codd 的表示法表示）或三个候选键：
Emp_IdE_mailPhone_number
给定一个员工ID，唯一确定该员工；给定 phone 编号，员工是唯一确定的；给定电子邮件地址，员工是唯一确定的。
你的关系模式是 3NF
如果以上所述是对关系模式的正确解释，那么您对 "I need to separate E-mail and Phone_Number information into a separate table (for 3NF)" 的观察是错误的。没必要分开。
在规定的条件下，你的关系模式已经是3NF；实际上，它也是 BCNF（Boyce-Codd 范式）。关系是 2NF，没有传递依赖。
问题 1 的答案
是的 — 您可以保留 table 原样，因为它已经在 3NF 中。
问题 2 的答案
否 — 因为 3NF 不需要单个候选密钥，您似乎认为这是必要的。此外，没有特别要求将电子邮件 ID 存储在主 table 中；电子邮件地址 table 将有一个主键，即员工 ID，不需要电子邮件 ID 号，因为电子邮件地址对员工来说是唯一的（根据此问题的参与规则）。 phone 数字也是如此。
在实践中，员工可能有多个电子邮件地址，并且可能有多个 phone 号码，即使只是供他们私人使用（与公司电子邮件地址和公司 phone 号码分开）。在这种情况下，您将有一个特定员工的 'non-empty list of email addresses' 和一个 'non-empty list of phone numbers'，然后您将需要单独的 table 来记录它们。 Phone号是Phone信息table的主键，Employee ID是phone号table中的FK；电子邮件地址将是电子邮件 table 的主键，员工 ID 将是电子邮件地址 table.
中的外键您的关系模式必须以某种方式列出这些多个条目，这不会是 1NF，更不用说 2NF 或 3NF（在一些关于如何表示列表的合理假设下）。 'non-empty' 标准需要谨慎执行。