其他人如何使用关系建模工具将逻辑模型或第三范式映射到使用 EAV 的数据库？
【问题讨论】：
标签： oracle database-design uml entity-relationship entity-attribute-value
EAV 是一种非关系型设计。您无法使用 EAV 实现 任何 范式，因为它不是关系。
EAV 是 Inner-Platform Effect 反模式的一个示例。
如果您需要许多属性，可以考虑 XML 的 serializing to a blob 并将该 XML 存储在 CLOB 列中。
【讨论】：
在关系中，可以有一个 EAV（也称为属性值对或名称-值对）。它使用相当抽象的数据模型。在描述它之前，有几个关于它的警告。很难查询，而且表现不佳。 EAV 通常用于审计表的关系中。 EAV 存储单个列的前图像（在它更改之前）。它一一存储更改的一列。如果五个属性发生变化，则 EAV 中将存储五行。此外，由于 EAV 中可能存在较大的自然主键，因此通常使用镜像表而不是 EAV。
可以在逻辑数据建模和关系数据中创建 EAV。这可以通过三个相关的实体或表来完成：
基础实体是具有不同特征的实体。
“类型”实体只是一个由类型代码标识并包含描述和其他域特征的代码表。域是指数据类型、长度、含义和度量单位等。它描述了脱离上下文（即未分配）的属性。一个例子可以是净值金额，它是一个 8 位数字，小数点后 2 位，右对齐，它的描述是“代表客户总财务价值的值，包括流动和非流动金额”。
“值”实体是一个关联实体或表，由客户 ID 和属性类型代码 [都是外键] 标识，具有一个值属性，该属性将净值金额类型分配给客户并为其赋予一个值，例如“2,000,000 美元”。值列通常被赋予一个通用名称，例如 Field。
但是，在 SQL 中，名称-值对有些难以查询，并且通常性能不佳。假设“值”实体有一个名为“字段”的属性。这是一个字符串。 SQL 通常使用列名作为结果集标题。假设该领域有净值。但是当它显示时，标题将被称为“字段”，而不是净值。字段是列的实际名称。需要高级 SQL 才能获得所需的标头。这个问题可以通过将“类型”和“值”实体非规范化为一个来解决。而不是三个表，而是两个表——一对多，一个基表和一个值表。实际上，Cassandra 本质上就是这样做的：列族中的列是完全展平的属性值对。即使您在关系中进行非规范化，“字段”列仍然称为“字段”。
您还可以将三个实体扁平化（非规范化）到一个关系表中，但会出现冗余问题：客户 ID[FK]、属性类型代码 [FK]、客户基础属性、属性类型属性、字段（对于值）。我不建议这样做；我只是说。
在数据建模的早期，数据建模人员喜欢使用 EAV，因为它们看起来是一种优雅、灵活的解决方案——直到 DBA 开始使用它们。因此，EAV 有时用于逻辑模型，但应在物理模型中完全非规范化。当完全非规范化时，它与 Cassandra 非常相似。我有时在逻辑和物理上都使用 EAV，并解决了上述问题。我不知道如何在这些 cmets 中添加图形，否则我会添加插图。
【讨论】：