初步
范式的定义（根据1971年“数据库关系模型的进一步规范化”的介绍被称为第一范式）和关系范式的定义本身在1970年发表在科学论文中，数据库管理，即实践的基础上，“数据的关系模型的大型共享数据银行”通过创建（RM为了简洁）EF科德博士，谁是图灵奖的获得者，并在关于关系框架的权力。
是的，对Codd博士的著作有很多解释，解释，论述，偏离和意见，但是我个人更喜欢坚持原始出处，我强烈建议您自己进行分析，以便得出自己的结论。
我当然不完全理解RM，但是我对RM的了解使我赞赏其卓越性，远见，意图和范围，尽管几十年后人们可以注意到它有一些轻微的错误，但并没有减少，无论如何，它的天才和优雅。在其领域中，RM以独特的方式经受住了时间的考验，并且无与伦比。
强调上述不精确性的举动是（使用慈善用语）不公平，因为从相当远的距离来看，这种开创性的材料需要进行一些改进和扩展，是的，但是作品的主体是坚如磐石的。非常有构想（实际上，科德博士自己做了大部分（即使不是全部）这样的改进和扩展）。
我继续不断地重新阅读RM，以增强对这种特殊知识来源的理解（并且我对每一次重新阅读的理解都在不断增长）；目的是站在巨人的肩膀上。
关系表
重要的是要注意，由于关系是抽象资源，因此Codd博士设想了以表格形式表示关系的实用性（他最初使用术语“数组表示”，但随后使用“表”或“ r表”），因此关系数据库（RDB）的用户，设计者和管理员可以以更加熟悉或具体的方式与他们联系。因此，在RDB实现的上下文中，使用表作为关系的简写是有效的，只要上述表格代表实际关系即可。此功能非常明显-尽管很明显-因为在评估表是否表示符合第一范式（1NF）的关系之前，它必须准确表示一个关系。
RM自然包含表必须确定的属性，表实际上是否要描述关系，但在此我将对它们进行非正式且朴实的解释（另一种，是的！）：
- 它必须有一个名称（数据库结构中的每个特定关系都必须与其余名称区分开）。
- 它的每一行都必须精确描述相关关系的一个元组。
- 其行的顺序根本不重要。
- 它的每个列必须具有一个名称，该名称代表所关注关系的确切一个域的含义，并且所述名称必须与表的其余列的名称不同（一列必须唯一区分并且必须带有具有独特的含义，是的，数据库建模人员和业务专家在准确定义每个重要领域中所扮演的角色至关重要）
- 其列的顺序没有任何意义。
- 其所有行的列数必须相同。
- 它必须至少具有一列或列的一种组合，以唯一地标识通过行描述的每个元组；这样，所有行都必须是不同的（是的，这强调了声明至少一个KEY的重要性，并且当有两个或多个KEY时，应根据实际原因将一个定义为PRIMARY，而其余的可以是被视为ALTERNATE；但是，是的，在做出决定之前，每个KEY都是“ PRIMARY”定义的“候选”。
拥有一个实际上代表一个关系的表是至关重要的，因为当它经历一种关系类型的操作时，结果又是一个代表关系的表。以这种方式，所述表的行为是可预测的。
原子域（列）
在RM的第一部分中，Codd博士介绍了几个关系样本，以介绍一些概念。因此，为了理解原子域的含义，让我们从RM的以下摘录开始，其中摘录了一些相关点：
到目前为止，我们已经讨论了在简单域上定义的关系的示例，这些域的元素是原子（不可分解）值。非原子值可以在关系框架内讨论。因此，某些领域可能具有关系作为元素。这些关系又可以在非简单域上定义，依此类推。
通过这种方式，可以说每个上述说明关系都适合两种，例如A或B：
种类A仅将由域（列）构成的关系（表）分组，该域（列）在其每个元组（行）中仅包含简单值，即，此类域（列）不包含关系（表）作为值，其中此上下文意味着值是原子性的，因为它们无法连续分解为新的关系（表）。因此，此类关系是已归一化的关系，即它们符合1NF，其形式是可取的。
类型B仅由关系（表）集成，该关系（表）具有一个或多个域（列），这些域在每个元组（行）中将关系作为值保存，并且表示所述值是非原子的，因为它们随后可以分解为新的关系（表格），即它们是可分解的。因此，这种关系是不规范的，即它们侵犯了1NF，处于不受欢迎的形式。
正常化
Codd博士在下面的段落中介绍了RM中有关规范化的部分：
可以通过上述类型的二维列均匀数组在存储中表示其域都非常简单的关系。与一个或多个非简单域的关系需要一些更复杂的数据结构。由于这个原因（以及下面要引用的其他原因），消除非简单域的可能性似乎值得研究！实际上，有一个非常简单的消除过程，我们称之为标准化。
然后他继续显示：
一组非标准化的关系（它的域包含关系作为值，即它们是非原子的；即它们不是简单的）
一组规范化的关系（即，已分解的关系；即，将关系重视的域分解为表示它们是原子的简单关系的域）
然后他描述了从非规范化关系中获得规范化关系的过程。
在这方面，他用来说明规范化练习和练习说明本身的关系非常清楚，我再次建议您自己分析它们（并且我也希望这会鼓励一些读者阅读本书）。
他成功地指出：
标准化类型的进一步操作是可能的。本文不讨论这些。
而且，上述操作（即第二和第三范式（2NF和3NF））实际上在“数据库关系模型的进一步规范化”中进行了详细介绍，并且如上所述，在本文进行介绍（以及以后的印刷和出版）之后， ，原始范式被称为第一范式。
正如从业人员可以看到的那样，具有非规范化的关系（表）将（几乎总是不必要的）卷积引入RDB实现中。
满足1NF的关系简化了约束和数据操作的定义，可以通过数据子语言来实现，这种数据子语言比未规范化的关系（表）所需的复杂程度要低，正如Codd博士在以下几行中指出的那样：
如上所述，采用数据的关系模型允许基于所应用的谓词演算来开发通用数据子语言。如果关系的集合为正常形式，则一阶谓词演算就足够了。这种语言将为所有其他拟议的数据语言提供语言能力的标准，并且本身将是嵌入（以适当的语法修改）各种宿主语言（编程，命令或问题导向）的强大候选者。[…]
[…]
数据子语言的普遍性在于其描述能力（而不是其计算能力）。
迷惑
从我的观点来看，困惑出现了，由于（a）中上述的过量的解释，解释等等，关于1NF和所述 RM本身，因为（b）的进一步尝试重新定义 1NF该状态具有关系如果域的值对应于每个元组，则这些域的值又是符合 1NF的关系。
我对你的其他观点
行之间不应有任何关系，除非它们符合相同的标题。
我不确定我是否正确理解了该语句的意图，但是除了要遵循相同的标头之外，关系（表）的（元组）行之间必须存在连接，因为它们中的每一行都应该是关于关系（表）应该表示的特定实体类型（根据感兴趣的业务上下文定义）的特定出现。
列之间也应该没有关系，但是我认为这是较高范式的主题。
我也不知道我是否正确地解释了该陈述的含义，但实际上，根据我对前一个方面的回答，关系（表）的域（列）之间也必须存在关系，这就是为什么它是一个关系（关系模型和RDB具体实现的基本结构）的原因。
为了举例说明，关于假设关系（表）
Salary (PersonNumber, EffectiveDate, Amount)
元组（行）
会传达意思
The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z
因此，Salary关系（表）的每个元组（行）必须适合上述断言的结构，并且不同之处在于将替换相关域（列）值，但是（a）之间必须存在关系所有Salary域（列）以及（b）每个元组（行）的所有对应值之间；这样的关系是必不可少的。
较高范式（2NF和3NF）可用于消除关系（表）的域（列）之间的功能依赖性，它们有助于避免域（列）之间的不良 连接，因为所述不良连接允许引入更新异常。2NF和3NF都有助于在某些RDB实现中测试关系（表）结构的合理性。