Escenarios adecuados para el modelado EAV de modelos de valor de atributo de entidad

(La primera parte de esta sección es una referencia al artículo PRECIS [6] de Slave/Nadkarni en Medicina, para más detalles para el lector.)

Modelado EAV, según Los términos alternativos "Modelado de datos universal" o "Arquitectura abierta" han sido durante mucho tiempo una herramienta estándar para los modeladores de datos avanzados. Como cualquier tecnología avanzada, puede ser un arma de doble filo y debe utilizarse con precaución.

Además, el empleo de EAV no excluye el empleo de métodos tradicionales de modelado de bases de datos relacionales dentro de la misma arquitectura de base de datos. Las reglas de EMRS, como RBDMS y Cerner, utilizan su enfoque EAV de subesquema de datos clínicos, y la gran mayoría de las tablas en el esquema en realidad se modelan tradicionalmente con atributos como columnas individuales que representan filas, en lugar de filas.

El modelado de metadatos de sistemas EAV submodo encaja bien con el modelado tradicional debido a las interrelaciones entre los diversos componentes de los metadatos. En el sistema TrialDB, por ejemplo, el número de tablas de metadatos en el esquema supera a las tablas de datos en aproximadamente diez a uno, debido a que la corrección y coherencia de los metadatos son muy críticas para el funcionamiento correcto del sistema EAV, los diseñadores del sistema deben aprovecharlas al máximo; Todos los RDBMS proporcionan características como integridad referencial y restricciones programables sin reinventar completamente la rueda del motor RDBMS. Por lo tanto, la gran cantidad de tablas de metadatos que respaldan el diseño de EAV suelen estar en la tercera forma relacional normal. Los casos típicos de uso de modelos EAV son atributos muy escasos y heterogéneos, como registros médicos electrónicos (EMRS), como los parámetros clínicos mencionados anteriormente. Sin embargo, incluso aquí, es exacto afirmar que los principios del modelado EAV son aplicables a un subesquema de la base de datos y no a todo su contenido. (Por ejemplo, los datos demográficos de los pacientes se modelan de forma más natural como una columna para cada atributo, en una estructura relacional tradicional).

Por lo tanto, los parámetros de diseño relacionados con EAV y "relación" reflejan una comprensión incompleta del problema: Los diseños EAV solo deben emplearse cuando los atributos dispersos deben modelarse en un esquema basado en una base de datos: incluso aquí deben estar respaldados por tablas de metadatos 3NF. Hay relativamente pocos diseños de bases de datos que encuentren problemas con atributos escasos: esta es la razón por la que los casos en los que los diseños EAV son aplicables son relativamente raros. Incluso si encuentran un conjunto de tablas EAV, esa no es la única manera de abordar los datos dispersos: una solución basada en XML (que se analiza a continuación) es aplicable cuando el número máximo de atributos por entidad es relativamente modesto y la cantidad total de datos dispersos es también También leve. Un ejemplo de esta situación es el problema de capturar atributos variables para diferentes tipos de productos. Otra aplicación de EAV es el modelado de clases y propiedades que no son dispersas y son dinámicas, pero el número de filas de datos por clase será relativamente modesto (un par de cientos de filas como máximo, pero generalmente unas pocas docenas) también para desarrolladores de sistemas. Se requería una interfaz de usuario final basada en web con un tiempo de respuesta corto. "Dinámico" significa que es necesario definir y modificar continuamente nuevas clases y atributos para representar un modelo de datos en evolución. Esto puede ocurrir en campos científicos en rápida evolución, así como en el desarrollo de ontologías, especialmente durante las etapas de refinamiento de prototipos e iteraciones.

Si bien la creación de nuevas tablas y columnas para representar datos no requiere mucha mano de obra en una nueva categoría, la interfaz basada en web admite navegación o edición básica, y programación de validación basada en tipos y rangos. En este caso, una solución a largo plazo más fácil de mantener es crear una definición de clase y propiedad almacenada en un marco de metadatos y hacer que el software genere una interfaz de usuario básica para estos metadatos de forma dinámica.

Crear el marco EAV/CR, mencionado anteriormente, para resolver esta situación inusual. NOTA: El modelo de datos EAV no es necesario aquí, pero los diseñadores de sistemas pueden considerarlo una alternativa aceptable a la creación, digamos, de sesenta y dos o más tablas, que no contengan más de 20 000 filas. Aquí, debido a que el número de filas por clase es tan pequeño, las consideraciones de eficiencia son menos importantes con la indexación estándar de ID de clase/ID de atributo, la optimización de DBMS puede almacenar en caché fácilmente, en la memoria, pequeñas clases de datos cuando se ejecutan consultas relacionadas con esta clase o atributo.

En el caso de los atributos dinámicos, cabe señalar que el marco de descripción de recursos (RDF) se emplea como base para el trabajo de ontología relacionado con la Web Semántica.

RDF es un método general para representar información en forma de EAV: un triple RDF incluye un objeto, atributo y valor.

En conclusión, vale la pena citar el clásico de Jon Bentley, "Escribiendo soluciones efectivas" (Prentice-Hall). Al final del libro, Bentley advierte que hacer que el código sea más eficiente generalmente también lo hace más difícil de entender y mantener, por lo que las personas no tienen prisa por sintonizar y desconectar el código a menos que primero determinen que hay un *rendimiento* problema y tome medidas como el análisis de código para descubrir Se revela la ubicación exacta del cuello de botella. Una vez que haga esto, solo modificará el código específico que necesita para ejecutarse más rápido. Se aplican consideraciones similares al modelado EAV: se aplica solo a modelos relacionales tradicionales que a priori se sabe que son difíciles de manejar (como en los dominios de datos clínicos), o para descubrir subsistemas que, a medida que el sistema evoluciona, plantean importantes desafíos de mantenimiento.