Database 具有唯一值的第三范式

我有表

USER

和模式

USER（用户id、电子邮件、名字、姓氏等）

。 电子邮件在我的数据库中是唯一的值，用户id是主键。因此，用户id和电子邮件是候选密钥。 这是否意味着我在这里有一个可传递的依赖关系（

user\u id->email->（first\u name，last\u name，…）

），因此数据库不在NF3中

“所有非素数属性必须仅依赖于候选密钥。”

---

如果您有两个候选关键点，那么它们自然会定义所有其他属性，这没关系。3NF的要点是两边没有带非键的FD。

注意

关系数据库

标记

主要的问题是，有一个关系模型，然后是各种各样的废话，被其他人认为是“关系”的，这使一切都变得混乱

E F Codd博士提出的唯一原始的关系模型

• 这是一个坚如磐石的定义，自1970年6月以来一直没有改变，也不需要改变。真理是永恒的，它不会改变。它是商业平台提供商构建平台的基础，在20世纪80年代就已经这样做了

Date&Darwen&Fagin版本，即20世纪60年代的记录归档系统，预数据库和预关系：RM所取代的东西。再加上关系模型中的几个片段（不是完整的概念）。以“关系”的形式大力推广和营销，这是不正确的

• 这是一个片段的集合，永远在变化。它们现在是多个“关系代数”；17种异常的“范式”（他们改变了原来的范式以适应自己的目的）；等等

• 以下术语在关系模型中不存在，它们是用于提升RFS中的片段以获得一点关系外观的术语
  • “传递依赖”
  • “候选密钥”
• 1960年代的RFS的特点是一个

  记录ID

  （您的是

  用户ID

  ），它是一个物理（而非逻辑）指针。这在RM中是明确禁止的，它是逻辑的，并且与之前基于指针的系统不同

• 1960年代的RFS和RM之间的主要区别（不是唯一的区别）是，RFS使用物理指针（如

  记录ID

  ）关联物理记录，RM使用数据中出现的自然键关联数据的逻辑行（不是记录）

• 20世纪90年代兴起的非商业平台提供商通常会参考这些新增内容，或提供RM中禁止的条款，有时还会提供一些功能来缓解这些新增内容带来的痛苦

是免费提供的（在那些日子里，只有合格的人才尝试数据库设计）。然而，这些术语已经过时，因此今天无法理解。它是种子，密集的。支持者依靠这一点，以便将他们的方法推广为“关系型”

---

关系模型 我将为关系模型负责。为了避免重复同一项，我将按逻辑顺序处理这些问题

RM要求每一行（不是记录，因为它超出了记录）都是唯一的

在RM中，为每个表选择一个或多个唯一键。每个键必须“由数据组成”。此外，每个密钥必须是非冗余的，即最小密钥。如果有多个键，则选择一个键作为主键，该键作为外键迁移到下级行。选择主键后，剩余的所有键都是备用键

在选举前，这些关键人物可能被笼统地称为“候选人”，但在选举后，他们不再是“候选人”，而是失败者

• 术语“候选者”的使用仅用于（a）维持不从其中一个“候选者”（根据RM的要求）中选择主键的紧张状态，以及（b）因此允许非键（例如伪造的

  记录ID

  或

  用户ID

  作为

  主键
  
  

• 数据中不存在

  记录ID

  字段，它是由系统制造的（

  GUID；AUTO INCREMENT

  ；等等）。这样的字段非常适合以物理术语（RFS）来感知数据，就好像它是一个令人惊愕的网格，因此抑制了将数据视为相关逻辑组件（RM）的感觉

• 真正的密钥有许多重要属性。在SQL中，将非密钥声明为

  主键

  ，不会神奇地赋予非密钥任何这些属性

• 因此，模式是

  用户（

  用户id，

  电子邮件，名字，姓氏，…）

您已经认识到，

电子邮件

是一个唯一的标识符。很好。事实上，对于该模式，它是唯一的关键，因此您不必担心从许多可能的选项中选择一个

这是一个比较

• 我所有的数据模型都在中呈现，这是自1993年以来建立关系数据库模型的标准

• 我的是初学者的必备读物

---

现在，您需要检查表是否满足3NF。Dmitry的意图是正确的，尽管他的定义可能不正确。E F Codd博士的3NF，而不是冒充者：

• 当每个非素数属性在功能上依赖于键、整个键以及除键以外的所有属性时，一行为第三范式。

• RM只有“完整”的功能依赖性，它不能帮助那些分割密钥的人处理