其他人如何使用关系建模工具将逻辑模型或第三范式中的模型映射到使用EAV的数据库？
答案 0 :(得分：7)
EAV是一种非关系设计。您无法使用EAV实现任何普通表单，因为它无法成为关系。
EAV是Inner-Platform Effect反模式的一个例子。
如果您需要许多属性，可以考虑使用serializing to a blob XML并将该XML存储在CLOB列中。
答案 1 :(得分：1)
在关系中，可以有一个EAV（也称为属性值对或名称 - 值对）。它使用相当抽象的数据模型。在描述它之前，有几点需要注意。它很难查询，但效果不佳。 EAV通常用于审计表的关系。 EAV存储单个列的前映像（在其更改之前）。它逐个存储已更改的一列。如果五个属性发生变化，则EAV中将存储五行。此外，由于EAV中可能存在大的自然主键，因此通常使用镜像表而不是EAV。
可以在逻辑数据建模和关系中创建EAV。这可以通过三个相关的实体或表来完成：
基础实体是具有不同特征的实体。
“类型”实体只是一个由类型代码标识并包含描述和其他域特征的代码表。域指的是数据类型，长度，含义和度量单位等。它描述了脱离上下文的属性（即未分配的）。一个例子可能是净值金额，它是带有2位小数的数字8位数，右对齐，其描述是“表示客户总财务价值的值，包括液体和非液体金额”。
“value”实体是一个关联实体或表，由客户ID和属性类型代码[两个外键]标识，它具有一个value属性，用于为Customer指定Net Worth Amount类型并为其赋值，例如“$ 2,000,000”。 value列通常被赋予通用名称，例如Field。
但是，在SQL中，名称 - 值对有些难以查询，通常效果不佳。假设“value”实体有一个名为“Field”的属性。这是一个字符串。 SQL通常使用结果集标题的列名。说这个领域有净值。但是当它显示时，标题将被称为“字段”，而不是净值。字段是列的实际名称。它需要高级SQL才能获得所需的标头。可以通过将“类型”和“值”实体非规范化为一个来解决该问题。你有两个 - 一对多，一个基表和一个值表，而不是三个表。实际上，这实际上就是Cassandra的用法：列族中的列是一个完全展平的属性 - 值对。即使你在关系中进行非规范化，“field”列仍然被称为“Field”。
您还可以将三个实体平铺（非规范化）为关系中的一个表，但会出现冗余问题：客户ID [FK]，属性类型代码[FK]，客户基础属性，属性类型属性，字段（对于价值观）。我不是建议它;我只是说。
在数据建模的早期阶段，数据建模人员喜欢使用EAV，因为它们似乎是一个优雅，灵活的解决方案 - 直到DBA得到它们。因此，EAV有时用于逻辑模型，但应在物理模型中完全非规范化。当完全非规范化时，它与卡桑德拉有很强的相似性。我有时在逻辑和物理上使用EAV，上面列出了问题。我不知道如何在这些评论中添加图形，或者我会包含一个插图。