yih*_*rns 4 normalization database-design terminology relational-theory denormalization
因此，在工作场所，我们目前将审计日志存储在不同的表中，具体取决于它是什么，例如登录/访问信息、配置更改等。
这些都是独立的数据，没有外键或任何关系。一些列是相似的，例如 ID（显然）、日期时间、进行更改的用户名等，而其他列则不同。
最近，我被要求将所有表合并为一个，其中相似的列将被保留，而不同的列将在 JSON 中，存储在一个 CLOB 列中。
有人告诉我，这个过程称为“规范化”——我们正在将许多表转换为“规范形式”。
现在，我不是数据库专家，但这似乎与我在数据库介绍课程中学到的关于规范化的知识不符。还是我只是无知？
不，您被要求完成的任务——将 (a) 属于两个或更多不同基表的列排列在 (b) 单个基表中——不被称为规范化（对于编写它的人来说也不是规范化）。
关于关系模型，由EF Codd 博士创建，规范化是由设计人员在数据库抽象逻辑级别执行的基于科学的过程，包括：
通过第一范式分解具有一个或多个属性（列）的关系（表）配置有非原子1域（类型），以便将所有相关域（类型）固定为简单或原子、数据操作和通过使用的数据库管理系统（简称为 DBMS）提供的数据子语言（例如 SQL）的表达工具，可以更容易地声明收缩；和
通过基于连续范式的拆分，摆脱关系（表）的属性（列）之间的不良依赖关系，以避免更新异常。
当然，设计者必须考虑所考虑的关系（表）和属性（列）所承载的含义。上述含义是根据在抽象概念级别上发生的建模练习来分配的，具体取决于感兴趣的业务环境的特定信息特征和规则。在那里，在概念级别，建模者执行与业务相关的直接关联的结构方面（实体类型和属性）的集成。这些概念元素随后通过上述关系（表）和属性（列）在逻辑级布局中表示，规范化有助于测试逻辑级表示的合理性。
反过来，反规范化也是一种在逻辑层面上应用的基于科学的程序，基本上，设计者采用符合某种范式的关系（表）并生成符合范式的关系（表）紧接在前一个“之下”；例如，一个处于第三范式的关系（表）经过了重组到它的第二范式，所以这个过程是顺序的。对符合第一范式的关系（表）进行反规范化会生成未规范化的关系（表）。
尽管在某些上下文中，术语“非规范化”被非正式地（并且不幸地）用于命名设计人员决定以特别的方式放置表格的方法，该表格包括例如保留保留的“摘要”列计算值和/或列属于并且也包含在其他表中，但这绝对是一个与关系模型的“基于理论的”标准形式无关的操作过程。您描述的任务（即，在同一个表中混合一些代表在概念级别没有直接关联的方面的列）似乎与术语“非规范化”的这种非正式（不幸）使用兼容，但请注意，作为记录，我强烈建议在提到这种方法时不要使用它，因为它只会增加歧义和混淆。
1域（有点类似于类型）原子性与在相关数据库中使用关系（表）的属性（列）的方式有很大关系。阿非原子域是包含具有其自己特定的意义，并且需要单独的约束和/或将参与数据操纵操作访问封闭在所述子结构（例如，SELECT或UPDATE值子部分的一个或多个子结构使用 WHERE 子句合并 DBMS 函数的操作——让我们说，SUBSTRING() ——通过“接触”值子部分来超越域原子性）。
在 1970 年题为“大型共享数据库的数据关系模型”的开创性论文中，Codd 博士阐述了具有接受关系（表）作为值的域的关系（表）示例；换句话说，相关关系（表）在其某些属性中包含“嵌套”关系（表）。在实践中，这种域需要使用 TABLE 数据类型设置的列，如果不作为原子处理，则涉及明显的复杂性（列、约束、行和相应操作的递归“嵌套”）。为了将这些关系从上述复杂性中解放出来，他提出正常化，设计者通过该过程将非简单（即非原子）域分解为原子域，从而以更方便的（第一范式）形式获得关系（表）。值得注意的是，与前面的段落一致，使用接受关系（表）作为值的域定义的属性（列）并不是唯一可以被认为是非原子的。
这样，如果您提到的参与组合过程的每一列都将始终受到约束并作为单个不可分割的单元在值操作中使用，即从不与值子部分相关，那么它们的类型将被管理原子地；如果不是，这样的组合过程将产生未规范化的表，即不符合第一范式的表，因此也不符合进一步的范式，因此需要真正的关系规范化。