其他人如何使用关系建模工具将逻辑模型或第三范式映射到使用 EAV 的数据库?
2 回答
在关系中,可能有一个 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,并解决了上述问题。我不知道如何在这些评论中添加图形,否则我会附上插图。