oracle database-design uml entity-relationship entity-attribute-value

oracle - Modelado de datos para EAV



database-design uml (2)

¿Cómo usan otras herramientas de modelado relacional para mapear un modelo lógico o uno en tercera forma normal a una base de datos que usa EAV?


EAV es un diseño no relacional. No puede lograr ninguna forma normal con EAV, porque no es una relación.

EAV es un ejemplo del antipatrón de efecto de plataforma interna .

Si necesita muchos atributos, podría considerar la serialización en un blob de XML y almacenar ese XML en una columna CLOB .


En relacional, es posible tener un EAV (también llamado par de valor de atributo o par de nombre-valor). Utiliza un modelo de datos bastante abstracto. Antes de describirlo, hay varias advertencias al respecto. es difícil de consultar y no funciona bien. EAV a menudo se utilizan en relacional para tablas de auditoría. El EAV almacena la imagen anterior de una sola columna (antes de que cambiara). Almacena una a una la columna que cambió. Si se modificaran cinco atributos, se almacenarían cinco filas en el EAV. Además, debido a una clave primaria natural potencialmente grande en EAV, a menudo se usan tablas espejo en lugar de EAV.

Un EAV se puede crear en el modelado de datos lógicos y en relacional. Esto se puede hacer con tres entidades o tablas relacionadas:

  • La entidad base (como el cliente), que análogamente a una familia de columnas.
  • Una entidad de "tipo", que describe el atributo y sus características tales como Importe del valor neto,
  • Una entidad de "valor", que asigna el atributo a una instancia de una entidad base y le da un valor.

La entidad base es la entidad que tiene las características variables.

La entidad "tipo" es simplemente una tabla de códigos identificada por un código de tipo y que contiene una descripción y otras características de dominio. El dominio se refiere al tipo de datos, la longitud, el significado y las unidades de medida, etc. Describe el atributo fuera de contexto (es decir, sin asignar). Un ejemplo podría ser el Valor neto Importe, que es un número de 8 dígitos con 2 decimales, justificado a la derecha, y su descripción es "un valor que representa el valor financiero total de un cliente, incluidas las cantidades líquidas y no líquidas".

La entidad "valor" es una entidad o tabla asociativa, identificada por la identificación del cliente y el código de tipo de atributo [ambas claves foráneas], que tiene un atributo de valor que asigna la Cantidad del Patrimonio Neto al Cliente y le da un valor, como "$ 2,000,000". La columna de valor a menudo recibe un nombre genérico como Campo.

Sin embargo, en SQL, los pares de nombre-valor son algo difíciles de consultar y, en general, no funcionan bien. Diga que la entidad "valor" tiene un atributo llamado "Campo". Esta es una cadena de caracteres. SQL generalmente usa el nombre de la columna para los encabezados del conjunto de resultados. Digamos que el campo tiene valor neto. Pero cuando se muestra, el encabezado se llamará "Campo", no patrimonio neto. Field es el nombre real de la columna. Se necesita SQL avanzado para obtener el encabezado deseado. Este problema podría abordarse mediante la desnormalización de las entidades de "tipo" y "valor" en una sola. En lugar de tener tres tablas, tiene dos: una a varias, una tabla base y una tabla de valores. En realidad, así es básicamente como lo hace Cassandra: las columnas en una familia de columnas son un par de valores-atributos completamente planos. Incluso si se desnormaliza en relación, la columna "campo" todavía se llama "Campo".

También podría aplanar (desnormalizar) las tres entidades en una tabla en relación, pero habría problemas de redundancia: ID de cliente [FK], Código de tipo de atributo [FK], atributo (s) de base de cliente, atributos de Tipo de atributo, Campo (para el valores). No lo estoy aconsejando; Sólo digo.

En los primeros días del modelado de datos, a los modeladores de datos les encantaba utilizar los EAV porque parecían ser una solución elegante y flexible, hasta que los DBA los tenían en sus manos. En consecuencia, EAV a veces se utiliza para un modelo lógico, pero debe ser totalmente desnormalizado en el físico. Cuando está totalmente desnormalizado, tiene un gran parecido con Cassandra. He usado EAV en ambos casos lógico y físico, con los problemas identificados anteriormente. No sé cómo agregar un gráfico en estos comentarios o incluiría una ilustración.