1

我有USER带有 schema的表USER(user_id, email, first_name, last_name, ...)。电子邮件是我数据库中的唯一值,user_id 是主键。因此,user_id 和 email 是候选键。这是否意味着我在这里有传递依赖(user_id -> email -> (first_name, last_name, ...)),因此数据库不在 NF3 中?

4

2 回答 2

1

注意Relational Database标签。

混淆一切的主要问题是,只有一个关系模型,然后是各种被别人宣传为“关系”的废话。

  1. EF Codd 博士唯一的原创关系模型
  • 这是一个坚如磐石的定义,自 1970 年 6 月以来一直没有改变,也不需要改变。真理是永恒的,它不会改变。它是商业平台提供商构建平台的基础,并且在 1980 年代就已经这样做了
  1. Date & Darwen & Fagin 版本,这是 1960 年代的记录归档系统,前数据库以及前关系:RM所取代的东西。加上来自关系模型的几个片段(不是整个概念)。大力宣传和营销为“关系”,这是不正确的。
  • 这是一个片段的集合,永远在变化。它们现在多达几个“关系代数”;17个不正常的“范式”(他们已经改变了原来的范式以适应自己的目的);等等

  • 关系模型中不存在以下术语,它们是用于提升其 RFS 中的片段以获得一点关系外观的术语。

    • “传递依赖”
    • “候选键”
  • 1960 年代的 RFS 以Record ID(yours is user_id) 为特征,它是一个物理(非逻辑)指针。这在RM中是明确禁止的,这是合乎逻辑的,并且脱离了之前的基于指针的系统。

  • 1960 年代 RFS 和RM之间的主要区别(不是唯一区别)是,而 RFS 使用物理指针关联物理记录,例如Record IDRM使用数据中出现的自然键关联数据的逻辑行(不是记录) .

  • 出现在 1990 年代的非商业平台提供商通常会参考这些新增内容或RM中禁止的供应条款,有时还会提供一些功能来缓解由此带来的痛苦。

关系模型是免费提供的(在那些日子里,只有合格的人才能尝试数据库设计)。但是,这些术语已过时,因此今天无法理解。它是开创性的,密集的。支持者指望这一点,以便将他们的方法推广为“关系”。


关系模型

我将回答关系模型。为了避免多次重复同一项目,我将按逻辑顺序处理问题。

  1. RM要求每一行(不是记录,因为它超出记录)是唯一的。

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

虽然Keys在选举前可能被粗略地称为“候选人”,但在选举之后他们不再是“候选人”,他们是失败者。

  • 使用“候选者”一词仅用于 (a) 保持不从“候选者”之一中选择主键的紧张局势(根据RM的要求),以及 (b) 因此允许非主键(例如作为一个捏造的Record IDuser_id作为一个PRIMARY KEY

  • Record ID数据中不存在字段,它是由系统制造的(;GUID; AUTO INCREMENT等)。这样的字段非常适合以物理术语 (RFS) 感知数据,就好像它是一个令人震惊的网格,因此抑制了将数据感知为相关的逻辑组件 ( RM )。

  • 真正的钥匙有许多重要的属性。将非键声明为 a PRIMARY KEY,这在 SQL 中是可能的,不会神奇地赋予非键任何这些属性。

  • 因此架构是USER(user_id, email, first_name, last_name, ...)
  1. 您已经认识到这email是一个唯一标识符。伟大的。事实上,对于该模式,它是唯一的 Key,因此您不必担心从许多可能中选择一个。

这是一个比较。

巴克塔


现在您要检查该表是否满足 3NF。德米特里的意图是正确的,尽管他的定义可能不正确。EF Codd 博士的 3NF,而不是伪装者:

  • 一行是第三范式,当且仅当每个非素数属性在功能上依赖于键、整个键且仅依赖于键。

  • RM只有“完整”的功能依赖,它不帮助那些将Key碎片化的人来处理他们的碎片。

  • 传递性是一个逻辑和数学术语,它没有在RM中减去,相反,它根本不适用,不是必需的,因为它处理整个 Key,而 RFS 处理 Key 的片段。

  • first_name, last_name, ...
    每个都在功能上依赖于email,而且只有email.

  • 因此满足 3NF。


1960 年代唱片归档系统

抱歉,我帮不了你,因为它是一个不断变化且不可靠的混乱,处理数据片段而不是识别原子,他们会无休止地争论,什么都解决不了。他们研究的概念不在RM中,因此被欺骗性地称为“关系”,同时保留了 1960 年面向记录的范式的基本部分:物理的附加字段和附加索引Record ID;和物理的参考Record ID。这两者都是RM禁止的。


注释

本节是根据 SO 指南呈现的,特别是:在您看到错误信息时纠正错误信息。我确实回复了评论,但他们一直在消失。因此我把它放在这里。

philipxy:
Codd 1971 年的 [论文]“Further normalization of the database relational model”在分解到更高 NF 的意义上引入了“规范化”,包括“FD”、“CK”、“其中一个 CK 被任意指定为 PK” , “2NF”表示“部分/全部 FD”,“3NF”表示“传递/非传递 FD”。

  1. 该引用来自 1971 年的论文,而不是 1970 年 6 月的论文The Relational Model。它们是两种不同的论文。因此确认:
  • 该内容在 1971 年的论文中

  • 1970 年 6 月的关系模型论文没有该内容。

因此,可以驳回 1971 年的论文

  1. 正如所证明的那样,Codd 在这十年(1970 年到 1980 年)期间写了大约 12 篇额外的论文,他试图让RM被接受。除了历史目的之外,它们没有任何价值,可以检验他对由RM引起的 DBMS 平台供应商动荡的反应方式:这是一种范式转变。

1971 年的论文以及“RM/Tasmania”文章和演示文稿的明确目的是帮助当时根深蒂固的 DBMS 平台用户在不改变平台、物理指针引用的情况下在他们的系统中实现一些关系能力范式(心态和实施)。

关系模型被接受之后,大约在 1985 年,当所有 DBMS 平台供应商开始转向提供 RDBMS 平台时,即。物理指针参考平台已经灭绝,1971 年的论文,以前对他们来说很近而且很珍贵,现在已经过时了。

因此,1971 年的论文可以再次被驳回

  1. 唯一与RM相关的文章(不是正式论文,但被广泛接受)是1985 年 ComputerWorld 文章,通常称为Codd 的十二条规则,它给出了 (a) DBMS 平台和 (b) 的规则一个数据库,被接受为真正的关系。那是为了克服 DBMS 平台供应商添加关系零碎然后将他们的产品标记为“关系”的问题。

  2. 还在迷茫吗?一个科学的人会:

  • 认识到RM与 1971 年的论文相矛盾,而 1971 年的论文与RM相矛盾,

  • 认识到它们不可能同时为真,

  • 适用非矛盾法

  • 取消 1971 年的论文

  1. Date、Darwen、Fagin 等人以及他们的所有追随者(作者、教授、讲师等)并不愚蠢。因此,以下证据起作用:
  • 所谓的问题 [4] 未得到解决,

  • RM的抑制(原子性;Codd 的三个 NF 不变;关系键;对关系键的“完全”功能依赖),

  • 1971 年过时论文的高度(碎片化;17 个 NF 不断变化的重新定义;物理RecordID作为“关键”;部分 FD 处理碎片等),

  • 声明 1971 年的论文(自 1985 年起已过时)与关系模型相矛盾,是“关系模型”。正如philipxy和其他人所证明的那样。

是不正确的,并且与原始关系模型不一致。

关系模型的制度化压制

它通过其他行为得到加强:

  • 在事实感知数据之前,将 Codd 的规则 1(从数据库中查看数据的事后视图)歪曲为权威,这就是“表”:

Erwin Snout:
从本质上讲,数据的关系模型只有一个“规则”:数据库中的所有信息都必须表示为关系元组中的属性值。

关系模型十二条规则中有超过 40 条规则。将它们简化为一个简洁的规则与RM不兼容。

  • 这消除了真正的数据建模的可能性

  • 永久使用完全过时的ERD进行数据分析和建模,它不支持关系模型的中心文章,复合关系键,从而保持对片段的感知

  • 禁止使用自 1985 年以来为关系模型设计的IDEF1X的使用,自 1993 年以来用于建模关系数据的 NIST 标准。它形式化了RM中的概念。

于 2019-11-30T07:08:17.090 回答
0

3NF定义

“所有非主属性必须只依赖于候选键。”

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

于 2019-11-29T08:27:14.160 回答