Un modelo de entidad-atributo-valor ( EAV ) es un modelo de datos optimizado para el almacenamiento eficiente en cuanto a espacio de valores de propiedades o datos dispersos (o ad hoc) , pensado para situaciones en las que los patrones de uso en tiempo de ejecución son arbitrarios, están sujetos a variaciones del usuario o son imprevisibles de otro modo utilizando un diseño fijo. El caso de uso está dirigido a aplicaciones que ofrecen un sistema grande o rico de tipos de propiedades definidos, que a su vez son apropiados para un amplio conjunto de entidades, pero donde normalmente solo se instancia (o persiste) una selección pequeña y específica de estas para una entidad dada. Por lo tanto, este tipo de modelo de datos se relaciona con la noción matemática de una matriz dispersa . EAV también se conoce como modelo de objeto-atributo-valor , modelo de base de datos vertical y esquema abierto .
Esta representación de datos es análoga a los métodos de almacenamiento de matrices dispersas que ahorran espacio , donde solo se almacenan valores no vacíos. En un modelo de datos EAV, cada par atributo-valor es un hecho que describe una entidad, y una fila en una tabla EAV almacena un solo hecho. Las tablas EAV suelen describirse como "largas y delgadas": "largas" se refiere a la cantidad de filas, "delgadas" a las pocas columnas.
Los datos se registran en tres columnas:
Consideremos cómo se intentaría representar un registro clínico de propósito general en una base de datos relacional. Claramente, no es factible crear una tabla (o un conjunto de tablas) con miles de columnas, porque la gran mayoría de las columnas serían null . Para complicar las cosas, en un registro médico longitudinal que sigue al paciente a lo largo del tiempo, puede haber múltiples valores del mismo parámetro: la altura y el peso de un niño, por ejemplo, cambian a medida que el niño crece. Finalmente, el universo de hallazgos clínicos sigue creciendo: por ejemplo, surgen enfermedades y se idean nuevas pruebas de laboratorio; esto requeriría la adición constante de columnas y la revisión constante de la interfaz de usuario. El término "volatilidad de atributos" a veces se utiliza para describir los problemas o situaciones que surgen cuando la lista de atributos disponibles o sus definiciones deben evolucionar con el tiempo.
A continuación se muestra una selección de filas de una tabla EAV para los hallazgos clínicos de una visita al médico por fiebre en la mañana del 1 de mayo de 1998. Las entradas que se muestran entre corchetes angulares son referencias a entradas en otras tablas, que se muestran aquí como texto en lugar de como valores de clave externa codificados para facilitar la comprensión. En este ejemplo, los valores son todos valores literales, pero también podrían ser listas de valores predefinidos. Estas últimas son particularmente útiles cuando se sabe que los valores posibles son limitados (es decir, enumerables ).
El siguiente ejemplo ilustra los síntomas y hallazgos que podrían observarse en un paciente con neumonía .
Los datos de EAV descritos anteriormente son comparables al contenido de un recibo de venta de un supermercado (que se reflejaría en una tabla de partidas de venta en una base de datos). El recibo enumera solo los detalles de los artículos realmente comprados, en lugar de enumerar todos los productos de la tienda que el cliente podría haber comprado pero no lo hizo. Al igual que los hallazgos clínicos de un paciente determinado, el recibo de venta es una representación compacta de datos inherentemente dispersos.
El modelado de filas , [ aclaración necesaria ] donde los hechos sobre algo (en este caso, una transacción de venta) se registran como múltiples filas en lugar de múltiples columnas , es una técnica de modelado de datos estándar. Las diferencias entre el modelado de filas y el EAV (que puede considerarse una generalización del modelado de filas) son:
En un repositorio de datos clínicos, el modelado de filas también encuentra numerosos usos; el subesquema de pruebas de laboratorio generalmente se modela de esta manera, porque los resultados de las pruebas de laboratorio suelen ser numéricos o pueden codificarse numéricamente.
A continuación se enumeran las circunstancias en las que sería necesario ir más allá del modelado de filas estándar a EAV:
Algunas clases ("híbridas") tienen algunos atributos que no son dispersos (presentes en todos o en la mayoría de los casos), mientras que otros atributos son muy variables y dispersos. Estos últimos son adecuados para el modelado EAV. Por ejemplo, las descripciones de productos fabricados por una corporación conglomerada dependen de la categoría del producto; por ejemplo, los atributos necesarios para describir una marca de bombilla son bastante diferentes de los necesarios para describir un dispositivo de diagnóstico por imágenes, pero ambos tienen atributos comunes, como la unidad de embalaje y el coste por artículo.
En los datos clínicos, la entidad es típicamente un evento clínico, como se describió anteriormente. En entornos más generales, la entidad es una clave externa en una tabla de "objetos" que registra información común sobre cada "objeto" (cosa) en la base de datos: como mínimo, un nombre preferido y una breve descripción, así como la categoría/clase de entidad a la que pertenece. A cada registro (objeto) en esta tabla se le asigna un ID de objeto generado por máquina.
El método de la "tabla de objetos" fue desarrollado por Tom Slezak y sus colegas de los Laboratorios Lawrence Livermore para la base de datos del cromosoma 19 y ahora es el estándar en la mayoría de las bases de datos bioinformáticas de gran tamaño. El uso de una tabla de objetos no obliga al uso simultáneo de un diseño EAV: se pueden utilizar tablas convencionales para almacenar los detalles específicos de la categoría de cada objeto.
La principal ventaja de una tabla central de objetos es que, al contar con una tabla complementaria de sinónimos y palabras clave de objetos, se puede proporcionar un mecanismo de búsqueda estándar similar al de Google en todo el sistema, donde el usuario puede encontrar información sobre cualquier objeto de interés sin tener que especificar primero la categoría a la que pertenece. (Esto es importante en los sistemas de biociencias, donde una palabra clave como "acetilcolina" podría referirse a la molécula en sí, que es un neurotransmisor, o al receptor biológico al que se une).
En la tabla EAV, esto es solo un ID de atributo, una clave externa en una tabla de definiciones de atributos, como se indicó anteriormente. Sin embargo, normalmente hay varias tablas de metadatos que contienen información relacionada con los atributos, y se analizarán en breve.
La conversión de todos los valores en cadenas, como en el ejemplo de datos EAV anterior, da como resultado una estructura simple, pero no escalable: se requieren interconversiones de tipos de datos constantes si uno quiere hacer algo con los valores, y un índice en la columna de valores de una tabla EAV es esencialmente inútil. Además, no es conveniente almacenar datos binarios grandes, como imágenes, en formato codificado Base64 en la misma tabla que cadenas o enteros pequeños. Por lo tanto, los sistemas más grandes utilizan tablas EAV separadas para cada tipo de datos (incluidos los objetos binarios grandes , "BLOB"), con los metadatos para un atributo determinado que identifican la tabla EAV en la que se almacenarán sus datos. Este enfoque es en realidad bastante eficiente porque la modesta cantidad de metadatos de atributos para una clase o formulario determinado con el que un usuario elige trabajar se puede almacenar en caché fácilmente en la memoria. Sin embargo, requiere mover datos de una tabla a otra si se cambia el tipo de datos de un atributo.
EAV, como un medio de propósito general de representación de conocimiento , se originó con el concepto de " listas de asociación " ( pares atributo-valor ). Comúnmente utilizados hoy en día, estos fueron introducidos por primera vez en el lenguaje LISP . [1] Los pares atributo-valor se utilizan ampliamente para diversas aplicaciones, como archivos de configuración (usando una sintaxis simple como atributo = valor ). Un ejemplo de uso no basado en bases de datos de EAV está en UIMA (Arquitectura de gestión de información no estructurada), un estándar ahora administrado por la Fundación Apache y empleado en áreas como el procesamiento del lenguaje natural . El software que analiza texto generalmente marca ("anota") un segmento: el ejemplo proporcionado en el tutorial de UIMA es un programa que realiza el reconocimiento de entidad nombrada (NER) en un documento, anotando el segmento de texto "Presidente Bush" con el triple anotación-atributo-valor (Persona, Nombre_completo, "George W. Bush") . [2] Dichas anotaciones pueden almacenarse en una tabla de base de datos.
Si bien el EAV no tiene una conexión directa con los pares AV, Stead y Hammond parecen ser los primeros en haber concebido su uso para el almacenamiento persistente de datos arbitrariamente complejos. [3] Los primeros sistemas de registros médicos que emplearon EAV fueron el registro médico electrónico de Regenstrief (el esfuerzo liderado por Clement MacDonald), [4] el sistema TMR (The Medical Record) de William Stead y Ed Hammond y el Repositorio de datos clínicos HELP (CDR) creado por el grupo de Homer Warner en el Hospital LDS, Salt Lake City, Utah. [5] [6] (El sistema Regenstrief en realidad utilizó un diseño de Paciente-Atributo-Marca de Tiempo-Valor: el uso de la marca de tiempo admitía la recuperación de valores para un paciente/atributo determinado en orden cronológico). Todos estos sistemas, desarrollados en la década de 1970, se lanzaron antes de que estuvieran disponibles los sistemas comerciales basados en el modelo de base de datos relacional de EF Codd , aunque HELP fue mucho más tarde portado a una arquitectura relacional y comercializado por la corporación 3M. (Nótese que si bien el artículo histórico de Codd se publicó en 1970, su tono fuertemente matemático tuvo el desafortunado efecto de disminuir su accesibilidad entre los tipos no informáticos y, en consecuencia, retrasó la aceptación del modelo en los círculos de TI y proveedores de software. El valor de la contribución posterior de Christopher J. Date , colega de Codd en IBM, en traducir estas ideas a un lenguaje accesible, acompañado de ejemplos simples que ilustraban su poder, no se puede exagerar).
Un grupo del Centro Médico Columbia-Presbyterian fue el primero en utilizar un motor de base de datos relacional como base de un sistema EAV. [7]
El sistema de gestión de datos de estudios clínicos de código abierto TrialDB de Nadkarni et al. fue el primero en utilizar múltiples tablas EAV, una para cada tipo de datos DBMS . [8]
El marco EAV/CR, diseñado principalmente por Luis Marenco y Prakash Nadkarni, superpuso los principios de la orientación a objetos sobre EAV; [9] se basó en el enfoque de tabla de objetos de Tom Slezak (descrito anteriormente en la sección "Entidad"). SenseLab, una base de datos de neurociencia de acceso público, está construida con el marco EAV/CR.
El término "base de datos EAV" se refiere a un diseño de base de datos en el que una proporción significativa de los datos se modela como EAV. Sin embargo, incluso en una base de datos descrita como "basada en EAV", algunas tablas del sistema son tablas relacionales tradicionales.
Como se señaló anteriormente, el modelado EAV tiene sentido para categorías de datos, como los hallazgos clínicos, donde los atributos son numerosos y dispersos. Cuando estas condiciones no se cumplen, es preferible el modelado relacional estándar (es decir, una columna por atributo); el uso de EAV no significa abandonar el sentido común o los principios de un buen diseño relacional. En los sistemas de registros clínicos, los subesquemas que tratan con la demografía y la facturación de los pacientes suelen modelarse de manera convencional. (Si bien la mayoría de los esquemas de bases de datos de proveedores son propietarios, VistA , el sistema utilizado en todo el sistema médico del Departamento de Asuntos de Veteranos (VA) de los Estados Unidos, conocido como Administración de Salud de Veteranos (VHA), [10] es de código abierto y su esquema es fácilmente inspeccionable, aunque utiliza un motor de base de datos MUMPS en lugar de una base de datos relacional).
Como se explicó brevemente, una base de datos EAV es esencialmente imposible de mantener sin numerosas tablas de soporte que contengan metadatos de soporte . Las tablas de metadatos, que normalmente superan en número a las tablas EAV por un factor de al menos tres o más, suelen ser tablas relacionales estándar. [8] [9] Un ejemplo de una tabla de metadatos es la tabla de definiciones de atributos mencionada anteriormente.
En un diseño EAV simple, los valores de un atributo son tipos de datos simples o primitivos en lo que respecta al motor de la base de datos. Sin embargo, en sistemas EAV utilizados para la representación de datos muy diversos, es posible que un objeto determinado (instancia de clase) pueda tener subestructura: es decir, algunos de sus atributos pueden representar otros tipos de objetos, que a su vez pueden tener subestructura, hasta un nivel arbitrario de complejidad. Un automóvil, por ejemplo, tiene un motor, una transmisión, etc., y el motor tiene componentes como cilindros. (La subestructura permisible para una clase dada se define dentro de los metadatos de atributos del sistema, como se analiza más adelante. Así, por ejemplo, el atributo "memoria de acceso aleatorio" podría aplicarse a la clase "computadora", pero no a la clase "motor").
Para representar la subestructura, se incorpora una tabla EAV especial donde la columna de valores contiene referencias a otras entidades del sistema (es decir, valores de clave externa en la tabla de objetos). Para obtener toda la información sobre un objeto dado se requiere un recorrido recursivo de los metadatos, seguido de un recorrido recursivo de los datos que se detiene cuando cada atributo recuperado es simple (atómico). El recorrido recursivo es necesario ya sea que los detalles de una clase individual se representen en forma convencional o EAV; dicho recorrido se realiza en sistemas relacionales de objetos estándar, por ejemplo. En la práctica, el número de niveles de recursión tiende a ser relativamente modesto para la mayoría de las clases, por lo que las penalizaciones de rendimiento debido a la recursión son modestas, especialmente con la indexación de identificadores de objetos.
EAV/CR (EAV con clases y relaciones) [11] [12] [13] se refiere a un marco que admite subestructuras complejas. Su nombre es un tanto inapropiado: si bien fue una consecuencia del trabajo sobre sistemas EAV, en la práctica, muchas o incluso la mayoría de las clases en un sistema de este tipo se pueden representar en forma relacional estándar, en función de si los atributos son dispersos o densos. EAV/CR se caracteriza realmente por sus metadatos muy detallados, que son lo suficientemente ricos como para admitir la generación automática de interfaces de navegación para clases individuales sin tener que escribir código de interfaz de usuario clase por clase. La base de dichas interfaces de navegación es que es posible generar un lote de consultas SQL dinámicas que es independiente de la clase del objeto, consultando primero sus metadatos y utilizando la información de metadatos para generar una secuencia de consultas contra las tablas de datos, y algunas de estas consultas pueden ser arbitrariamente recursivas. Este enfoque funciona bien para consultas de objeto a objeto, como en las interfaces de navegación basadas en la Web donde al hacer clic en el nombre de un objeto aparecen todos los detalles del objeto en una página separada: los metadatos asociados con la clase de ese objeto también facilitan la presentación de los detalles del objeto, porque incluyen títulos de atributos individuales, el orden en que deben presentarse y cómo deben agruparse.
Un enfoque de EAV/CR es permitir que las columnas contengan estructuras JSON , que de esta manera proporcionan la estructura de clase necesaria. Por ejemplo, PostgreSQL , a partir de la versión 9.4, ofrece compatibilidad con columnas binarias JSON (JSONB), lo que permite consultar, indexar y unir atributos JSON.
En palabras del Prof. Dr. Daniel Masys (anteriormente Presidente del Departamento de Informática Médica de la Universidad de Vanderbilt), los desafíos de trabajar con EAV surgen del hecho de que en una base de datos EAV, el "esquema físico" (la forma en que se almacenan los datos) es radicalmente diferente del "esquema lógico" - la forma en que los usuarios, y muchas aplicaciones de software como los paquetes de estadísticas, lo consideran, es decir, como filas y columnas convencionales para clases individuales. (Dado que una tabla EAV mezcla conceptualmente manzanas, naranjas, pomelos y chop suey, si desea realizar cualquier análisis de los datos utilizando software estándar disponible en el mercado, en la mayoría de los casos debe convertir subconjuntos de ellos en forma de columnas. [14] El proceso de hacer esto, llamado pivoteo , es lo suficientemente importante como para ser discutido por separado).
Los metadatos ayudan a realizar la maniobra que permite a los usuarios interactuar con el sistema en términos del esquema lógico en lugar del físico: el software consulta continuamente los metadatos para diversas operaciones, como presentación de datos, validación interactiva, extracción masiva de datos y consultas ad hoc . Los metadatos se pueden utilizar para personalizar el comportamiento del sistema.
Los sistemas EAV sacrifican la simplicidad de la estructura física y lógica de los datos por la complejidad de sus metadatos, lo que, entre otras cosas, cumple la función que cumplen las restricciones de la base de datos y la integridad referencial en los diseños de bases de datos estándar. Este sacrificio suele ser conveniente, porque en el esquema mixto típico de los sistemas de producción, los datos de las tablas relacionales convencionales también pueden beneficiarse de funciones como la generación automática de interfaces. La estructura de los metadatos es lo suficientemente compleja como para incluir su propio subesquema dentro de la base de datos: varias claves externas en las tablas de datos hacen referencia a tablas dentro de este subesquema. Este subesquema es relacional estándar, y se utilizan al máximo características como las restricciones y la integridad referencial.
La corrección del contenido de los metadatos, en términos del comportamiento previsto del sistema, es fundamental y la tarea de garantizar la corrección significa que, al crear un sistema EAV, se deben realizar considerables esfuerzos de diseño para construir interfaces de usuario para la edición de metadatos que puedan ser utilizadas por personas del equipo que conocen el dominio del problema (por ejemplo, medicina clínica) pero que no son necesariamente programadores. (Históricamente, una de las principales razones por las que el sistema TMR pre-relacional no pudo ser adoptado en sitios distintos a su institución de origen fue que todos los metadatos se almacenaban en un solo archivo con una estructura no intuitiva. Personalizar el comportamiento del sistema alterando el contenido de este archivo, sin provocar que el sistema se estropeara, era una tarea tan delicada que los autores del sistema solo confiaban en sí mismos para hacerlo).
Cuando se implementa un sistema EAV a través de RDF , el lenguaje de esquema RDF puede utilizarse convenientemente para expresar dichos metadatos. Esta información de esquema puede ser utilizada por el motor de base de datos EAV para reorganizar dinámicamente su estructura de tabla interna para lograr la mejor eficiencia. [15]
Algunas advertencias finales sobre los metadatos:
La validación, presentación y agrupación de metadatos hacen posible la creación de marcos de código que admiten la generación automática de interfaces de usuario tanto para la exploración de datos como para la edición interactiva. En un sistema de producción que se distribuye a través de la Web, la tarea de validación de datos EAV se traslada esencialmente del nivel de back-end/base de datos (que no tiene poder con respecto a esta tarea) al nivel intermedio/servidor Web. Si bien la validación de back-end siempre es ideal, porque es imposible subvertirla intentando ingresar datos directamente en una tabla, la validación de nivel intermedio a través de un marco genérico es bastante viable, aunque se debe dedicar una cantidad significativa de esfuerzo de diseño de software a construir el marco primero. La disponibilidad de marcos de código abierto que se puedan estudiar y modificar para necesidades individuales puede ayudar mucho a evitar la reinvención de la rueda. [ cita requerida ]
(La primera parte de esta sección es un resumen del artículo de referencia Dinu/Nadkarni en Central, [18] al que se dirige al lector para obtener más detalles).
El modelado EAV, conocido también como " modelado de datos genéricos " o "esquema abierto", ha sido durante mucho tiempo una herramienta estándar para los modeladores de datos avanzados. Como cualquier técnica avanzada, puede tener doble filo y debe utilizarse con prudencia.
Además, el uso de EAV no excluye el uso de métodos de modelado de bases de datos relacionales tradicionales dentro del mismo esquema de base de datos. En los registros médicos electrónicos que dependen de un RDBMS, como Cerner , que utiliza un método EAV para su subesquema de datos clínicos, la gran mayoría de las tablas del esquema están de hecho modeladas de manera tradicional, con atributos representados como columnas individuales en lugar de filas.
De hecho, el modelado del subesquema de metadatos de un sistema EAV se adapta muy bien al modelado tradicional, debido a las interrelaciones entre los diversos componentes de los metadatos. En el sistema TrialDB, por ejemplo, la cantidad de tablas de metadatos en el esquema supera a las tablas de datos en una proporción de aproximadamente diez a uno. Debido a que la exactitud y la consistencia de los metadatos son fundamentales para el funcionamiento correcto de un sistema EAV, el diseñador del sistema desea aprovechar al máximo todas las características que brindan los RDBMS, como la integridad referencial y las restricciones programables, en lugar de tener que reinventar la rueda del motor RDBMS. En consecuencia, las numerosas tablas de metadatos que respaldan los diseños EAV suelen estar en forma relacional de tercera normal.
Los sistemas de registros médicos electrónicos comerciales (EHR) utilizan el modelado de filas para clases de datos como diagnósticos, procedimientos quirúrgicos realizados y resultados de pruebas de laboratorio, que se separan en tablas separadas. En cada tabla, la "entidad" es una combinación del ID del paciente y la fecha/hora en que se realizó el diagnóstico (o la cirugía o prueba de laboratorio); el atributo es una clave externa en una tabla de búsqueda especialmente designada que contiene un vocabulario controlado, por ejemplo, ICD-10 para diagnósticos, Terminología de procedimientos actuales para procedimientos quirúrgicos, con un conjunto de atributos de valor. (Por ejemplo, para los resultados de pruebas de laboratorio, se puede registrar el valor medido, ya sea que esté en el rango normal, bajo o alto, el ID de la persona responsable de realizar la prueba, la fecha/hora en que se realizó la prueba, etc.) Como se dijo anteriormente, este no es un enfoque EAV completo porque el dominio de los atributos para una tabla dada está restringido, al igual que el dominio de los ID de productos en la tabla de Ventas de un supermercado estaría restringido al dominio de Productos en una tabla de Productos.
Sin embargo, para capturar datos sobre parámetros que no siempre están definidos en vocabularios estándar, los EHR también proporcionan un mecanismo EAV "puro", donde los usuarios avanzados especialmente designados pueden definir nuevos atributos, su tipo de datos, valores máximos y mínimos permitidos (o conjunto de valores/códigos permitidos), y luego permitir que otros capturen datos basados en estos atributos. En el EHR Epic (TM), este mecanismo se denomina "hojas de flujo" y se usa comúnmente para capturar datos de observación de enfermería de pacientes hospitalizados.
El caso típico de uso del modelo EAV es para atributos muy dispersos y heterogéneos, como los parámetros clínicos en la historia clínica electrónica (HCE), como se indicó anteriormente. Sin embargo, incluso en este caso es preciso afirmar que el principio de modelado EAV se aplica a un subesquema de la base de datos en lugar de a todo su contenido. (Los datos demográficos de los pacientes, por ejemplo, se modelan de forma más natural en una estructura relacional tradicional de una columna por atributo).
En consecuencia, los argumentos sobre el diseño EAV frente al diseño "relacional" reflejan una comprensión incompleta del problema: un diseño EAV debería emplearse sólo para ese subesquema de una base de datos donde se necesitan modelar atributos dispersos: incluso en este caso, deben estar respaldados por tablas de metadatos de tercera forma normal . Hay relativamente pocos problemas de diseño de bases de datos donde se encuentran atributos dispersos: es por eso que las circunstancias en las que se aplica el diseño EAV son relativamente raras. Incluso cuando se encuentran, un conjunto de tablas EAV 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 el volumen total de datos dispersos también es igualmente modesto. Un ejemplo de esta situación son los problemas de captura de atributos variables para diferentes tipos de productos.
Los atributos dispersos también pueden ocurrir en situaciones de comercio electrónico donde una organización compra o vende un conjunto amplio y muy diverso de productos, y los detalles de las categorías individuales de productos son muy variables.
Otra aplicación de EAV es el modelado de clases y atributos que, si bien no son dispersos, son dinámicos, pero donde el número de filas de datos por clase será relativamente modesto (un par de cientos de filas como máximo, pero por lo general unas pocas docenas) y el desarrollador del sistema también debe proporcionar una interfaz de usuario final basada en la Web en un plazo de entrega muy breve. "Dinámico" significa que se deben definir y modificar continuamente nuevas clases y atributos para representar un modelo de datos en evolución. Este escenario puede darse en campos científicos de rápida evolución, así como en el desarrollo de ontologías, especialmente durante las fases de creación de prototipos y refinamiento iterativo.
Si bien la creación de nuevas tablas y columnas para representar una nueva categoría de datos no requiere mucho trabajo, la programación de interfaces basadas en la Web que admitan la exploración o la edición básica con validación basada en tipos y rangos sí lo requiere. En tal caso, una solución a largo plazo más sostenible es crear un marco en el que las definiciones de clases y atributos se almacenen en metadatos y el software genere una interfaz de usuario básica a partir de estos metadatos de forma dinámica.
El marco EAV/CR, mencionado anteriormente, fue creado para abordar esta misma situación. Tenga en cuenta que un modelo de datos EAV no es esencial en este caso, pero el diseñador del sistema puede considerarlo una alternativa aceptable para crear, por ejemplo, sesenta o más tablas que contengan un total de no más de dos mil filas. En este caso, 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 por ID de clase/ID de atributo, los optimizadores de DBMS pueden almacenar fácilmente en caché los datos de una clase pequeña en la memoria al ejecutar una consulta que involucre esa clase o atributo.
En el escenario de atributos dinámicos, vale la pena señalar que se está empleando el marco de descripción de recursos (RDF) como base del trabajo de ontología relacionado con la Web semántica. RDF, que se concibió como un método general de representación de información, es una forma de EAV: un triple RDF comprende un objeto, una propiedad y un valor.
Al final del libro de Jon Bentley "Writing Efficient Programs", el autor advierte que hacer que el código sea más eficiente en general también lo hace más difícil de entender y mantener, y por eso uno no se apresura a modificar el código a menos que primero haya determinado que hay un problema de rendimiento y que medidas como el perfilado del código hayan señalado la ubicación exacta del cuello de botella. Una vez que lo haya hecho, modifique sólo el código específico que necesita ejecutarse más rápido. Consideraciones similares se aplican al modelado EAV: se aplica sólo al subsistema donde se sabe a priori que el modelado relacional tradicional es difícil de manejar (como en el dominio de los datos clínicos), o se descubre, durante la evolución del sistema, que plantea desafíos de mantenimiento significativos. El gurú de las bases de datos (y actualmente vicepresidente de tecnologías básicas en Oracle Corporation) Tom Kyte, [19] por ejemplo, señala correctamente los inconvenientes de emplear EAV en escenarios comerciales tradicionales y señala que la mera "flexibilidad" no es un criterio suficiente para emplear EAV. (Sin embargo, hace la afirmación general de que se debe evitar el EAV en todas las circunstancias, a pesar de que la propia división de Ciencias de la Salud de Oracle utiliza EAV para modelar los atributos de los datos clínicos en sus sistemas comerciales ClinTrial [20] y Oracle Clinical [21] ) .
El talón de Aquiles de EAV es la dificultad de trabajar con grandes volúmenes de datos EAV. A menudo es necesario realizar conversiones transitorias o permanentes entre representaciones de los mismos datos modeladas en columnas y en filas o en EAV; esto puede ser propenso a errores si se hace manualmente y también consumir mucha CPU. Los marcos genéricos que utilizan metadatos de atributos y agrupación de atributos abordan la primera limitación, pero no la segunda; su uso es más o menos obligatorio en el caso de esquemas mixtos que contienen una mezcla de datos relacionales convencionales y EAV, donde el cociente de error puede ser muy significativo.
La operación de conversión se denomina pivoteo . El pivoteo no solo es necesario para los datos EAV, sino también para cualquier forma de datos modelados en filas. (Por ejemplo, las implementaciones del algoritmo Apriori para análisis de asociación, ampliamente utilizado para procesar datos de ventas de supermercados para identificar otros productos que los compradores de un producto determinado también tienen probabilidades de comprar, pivotean los datos modelados en filas como un primer paso). Muchos motores de bases de datos tienen extensiones SQL propietarias para facilitar el pivoteo, y paquetes como Microsoft Excel también lo admiten. A continuación se consideran las circunstancias en las que es necesario el pivoteo.
Sin embargo, la estructura del modelo de datos EAV es un candidato perfecto para la división relacional, véase álgebra relacional . Con una buena estrategia de indexación, es posible obtener un tiempo de respuesta de menos de unos pocos cientos de milisegundos en una tabla EAV de mil millones de filas. Peter Larsson, MVP de Microsoft SQL Server, ha demostrado esto en una computadora portátil y ha puesto la solución a disposición del público en general. [22]
Obviamente, sin importar el enfoque que tome, la consulta de EAV no será tan rápida como la consulta de datos relacionales modelados en columnas estándar para ciertos tipos de consulta, de la misma manera que el acceso a elementos en matrices dispersas no es tan rápido como el de matrices no dispersas si estas últimas caben completamente en la memoria principal. (Las matrices dispersas, representadas mediante estructuras como listas enlazadas, requieren un recorrido de lista para acceder a un elemento en una posición XY dada, mientras que el acceso a elementos en matrices representadas como matrices 2-D se puede realizar mediante operaciones rápidas de registro de CPU). Sin embargo, si eligió el enfoque EAV correctamente para el problema que estaba tratando de resolver, este es el precio que paga; en este sentido, el modelado EAV es un ejemplo de una compensación de espacio (y mantenimiento del esquema) versus tiempo de CPU.
Originalmente postulado por Maier, Ullman y Vardi, [23] el "Modelo Universal de Datos" (UDM) busca simplificar la consulta de un esquema relacional complejo por parte de usuarios ingenuos, creando la ilusión de que todo está almacenado en una única "tabla universal" gigante. Esto se logra utilizando relaciones entre tablas, de modo que el usuario no necesita preocuparse por qué tabla contiene qué atributo. Sin embargo, CJ Date [24] señaló que en circunstancias en las que una tabla está relacionada de forma múltiple con otra (como en las bases de datos de genealogía, donde el padre y la madre de un individuo también son individuos, o en algunas bases de datos comerciales donde todas las direcciones se almacenan de forma centralizada y una organización puede tener diferentes direcciones de oficina y direcciones de envío), no hay suficientes metadatos dentro del esquema de la base de datos para especificar uniones inequívocas. Cuando se ha comercializado UDM, como en SAP BusinessObjects , esta limitación se soluciona mediante la creación de "Universos", que son vistas relacionales con uniones predefinidas entre conjuntos de tablas: el desarrollador de "Universos" elimina la ambigüedad de las uniones ambiguas al incluir la tabla relacionada de forma múltiple en una vista varias veces utilizando diferentes alias.
Aparte de la forma en que se modelan explícitamente los datos (UDM simplemente utiliza vistas relacionales para interceder entre el usuario y el esquema de la base de datos), EAV se diferencia de los modelos de datos universales en que también se aplica a sistemas transaccionales, no solo a sistemas orientados a consultas (solo lectura) como en UDM. Además, cuando se utilizan como base para sistemas de consulta de datos clínicos, las implementaciones de EAV no necesariamente protegen al usuario de tener que especificar la clase de un objeto de interés. En el almacén de datos clínicos i2b2 basado en EAV, [25] por ejemplo, cuando el usuario busca un término, tiene la opción de especificar la categoría de datos en la que está interesado. Por ejemplo, la frase " litio " puede referirse tanto al medicamento (que se utiliza para tratar el trastorno bipolar ) como a un análisis de laboratorio para el nivel de litio en la sangre del paciente. (El nivel de litio en la sangre debe controlarse cuidadosamente: demasiada cantidad del medicamento causa efectos secundarios graves, mientras que muy poca es ineficaz).
Una implementación de esquema abierto puede usar una columna XML en una tabla para capturar la información variable/dispersa. [26] Se pueden aplicar ideas similares a bases de datos que admiten columnas con valores JSON : los datos jerárquicos dispersos se pueden representar como JSON. Si la base de datos tiene soporte JSON, como PostgreSQL y (parcialmente) SQL Server 2016 y posteriores, entonces se pueden consultar, indexar y unir atributos. Esto puede ofrecer mejoras de rendimiento de más de 1000 veces en comparación con implementaciones EAV ingenuas, [27] pero no necesariamente hace que la aplicación de base de datos en general sea más robusta.
Tenga en cuenta que existen dos formas de almacenar datos XML o JSON: una es almacenarlos como una cadena simple, opaca para el servidor de base de datos; la otra es utilizar un servidor de base de datos que pueda "ver dentro" de la estructura. Obviamente, almacenar cadenas opacas tiene algunas desventajas graves: no se pueden consultar directamente, no se puede formar un índice en función de su contenido y es imposible realizar uniones en función del contenido.
La creación de una aplicación que tenga que gestionar datos se vuelve extremadamente complicada cuando se utilizan modelos EAV, debido a la extensión de la infraestructura que se debe desarrollar en términos de tablas de metadatos y código del marco de aplicación. El uso de XML resuelve el problema de la validación de datos basada en servidor (que debe realizarse mediante código de nivel intermedio y basado en navegador en marcos basados en EAV), pero tiene las siguientes desventajas:
Todos los inconvenientes anteriores se pueden solucionar creando una capa de metadatos y código de aplicación, pero al crearla, la "ventaja" original de no tener que crear un marco de trabajo ha desaparecido. El hecho es que modelar atributos de datos dispersos de forma robusta es un problema de diseño de aplicaciones de bases de datos difícil, sin importar el enfoque de almacenamiento que se utilice. Sin embargo, el trabajo de Sarka [26] demuestra la viabilidad de utilizar un campo XML en lugar de tablas EAV relacionales específicas de tipo para la capa de almacenamiento de datos, y en situaciones en las que el número de atributos por entidad es modesto (por ejemplo, atributos de producto variables para diferentes tipos de productos), la solución basada en XML es más compacta que una basada en tablas EAV. (XML en sí mismo puede considerarse un medio de representación de datos de atributo-valor, aunque se basa en texto estructurado en lugar de tablas relacionales).
Existen otros enfoques para la representación de datos estructurados en árbol, ya sea XML , JSON u otros formatos, como el modelo de conjuntos anidados , en una base de datos relacional. Por otro lado, los proveedores de bases de datos han comenzado a incluir soporte para JSON y XML en sus estructuras de datos y funciones de consulta, como en IBM Db2 , donde los datos XML se almacenan como XML separado de las tablas, utilizando consultas XPath como parte de las sentencias SQL, o en PostgreSQL , con un tipo de datos JSON [28] que se puede indexar y consultar. Estos desarrollos completan, mejoran o sustituyen el enfoque del modelo EAV.
Los usos de JSON y XML no son necesariamente los mismos que el uso de un modelo EAV, aunque pueden superponerse. XML es preferible a EAV para datos arbitrariamente jerárquicos que son relativamente modestos en volumen para una sola entidad: no está destinado a escalar hasta el nivel de varios gigabytes con respecto al rendimiento de manipulación de datos. [ cita requerida ] XML no se ocupa per se del problema de los atributos dispersos, y cuando el modelo de datos subyacente a la información que se va a representar se puede descomponer directamente en una estructura relacional, XML es más adecuado como medio de intercambio de datos que como mecanismo de almacenamiento primario. EAV, como se dijo anteriormente, es específicamente (y solo) aplicable al escenario de atributos dispersos. Cuando tal escenario se cumple, el uso de tablas de valores de atributos específicos del tipo de datos que se pueden indexar por entidad, por atributo y por valor y manipular a través de instrucciones SQL simples es mucho más escalable que el uso de una estructura de árbol XML. [ cita requerida ] El Google App Engine, mencionado anteriormente, [ cita requerida ] utiliza tablas de valores fuertemente tipados por una buena razón. [ cita requerida ]
Un enfoque alternativo para gestionar los diversos problemas que se encuentran con los datos estructurados con EAV es emplear una base de datos de grafos . Estos representan entidades como los nodos de un grafo o hipergrafo , y atributos como enlaces o bordes de ese grafo. El problema de las uniones de tablas se aborda proporcionando lenguajes de consulta específicos para grafos, como Apache TinkerPop, [29] o el comparador de patrones de espacio atómico OpenCog . [30]
Otra alternativa es utilizar el almacén SPARQL .
La versión 9.4 de PostgreSQL incluye compatibilidad con columnas binarias JSON (JSONB), que se pueden consultar, indexar y unir. Esto permite mejoras de rendimiento por factores de mil o más en comparación con los diseños de tablas EAV tradicionales. [27]
Un esquema de base de datos basado en JSONB siempre tiene menos tablas: se pueden anidar pares atributo-valor en campos de tipo JSONB de la tabla Entity. Esto hace que el esquema de base de datos sea fácil de comprender y las consultas SQL sean concisas. [31] El código de programación para manipular los objetos de la base de datos en la capa de abstracción resulta mucho más corto. [32]
Microsoft SQL Server 2008 ofrece una alternativa (propietaria) a EAV. [33] Las columnas con un tipo de datos atómico (por ejemplo, columnas numéricas, varchar o datetime) se pueden designar como dispersas simplemente incluyendo la palabra SPARSE en la definición de columna de la instrucción CREATE TABLE. Las columnas dispersas optimizan el almacenamiento de valores NULL (que ahora no ocupan espacio en absoluto) y son útiles cuando la mayoría de los registros en una tabla tendrán valores NULL para esa columna. Los índices en columnas dispersas también se optimizan: solo se indexan aquellas filas con valores. Además, el contenido de todas las columnas dispersas en una fila particular de una tabla se puede agregar colectivamente en una sola columna XML (un conjunto de columnas), cuyo contenido tiene la forma [<column-name>column contents </column-name>]*....De hecho, si se define un conjunto de columnas para una tabla como parte de una instrucción CREATE TABLE, todas las columnas dispersas definidas posteriormente normalmente se agregan a él. Esto tiene la interesante consecuencia de que la sentencia SQL SELECT * from <tablename>no devolverá las columnas dispersas individuales, sino que las concatenará todas en una única columna XML cuyo nombre es el del conjunto de columnas (que, por lo tanto, actúa como una columna virtual calculada). Las columnas dispersas son convenientes para aplicaciones comerciales como la información de productos, donde los atributos aplicables pueden ser muy variables según el tipo de producto, pero donde el número total de atributos variables por tipo de producto es relativamente modesto.
Sin embargo, este enfoque para modelar atributos dispersos tiene varias limitaciones: los DBMS rivales, en particular, han optado por no adoptar esta idea para sus propios motores. Las limitaciones incluyen:
Muchos proveedores de computación en la nube ofrecen almacenes de datos basados en el modelo EAV, donde un número arbitrario de atributos se puede asociar con una entidad dada. Roger Jennings proporciona una comparación en profundidad [34] de estos. En la oferta de Amazon, SimpleDB, el tipo de datos está limitado a cadenas, y los datos que intrínsecamente no son cadenas deben convertirse en cadenas (por ejemplo, los números deben rellenarse con ceros iniciales) si desea realizar operaciones como ordenar. La oferta de Microsoft, Windows Azure Table Storage, ofrece un conjunto limitado de tipos de datos: byte[], bool, DateTime, double, Guid, int, long y string [1]. Google App Engine [2] ofrece la mayor variedad de tipos de datos: además de dividir los datos numéricos en int, long o float, también define tipos de datos personalizados como número de teléfono, dirección de correo electrónico, geocodificación e hipervínculo. Google, pero no Amazon ni Microsoft, le permite definir metadatos que evitarían que atributos no válidos se asocien con una clase particular de entidad, permitiéndole crear un modelo de metadatos.
Google permite operar con los datos mediante un subconjunto de SQL; Microsoft ofrece una sintaxis de consulta basada en URL que se abstrae mediante un proveedor LINQ ; Amazon ofrece una sintaxis más limitada. Es preocupante que, actualmente (abril de 2010), los tres motores no dispongan de soporte integrado para combinar diferentes entidades mediante uniones. Dichas operaciones deben ser realizadas por el código de la aplicación. Esto puede no ser un problema si los servidores de aplicaciones están ubicados junto con los servidores de datos en el centro de datos del proveedor, pero se generaría mucho tráfico de red si ambos estuvieran separados geográficamente.
Un enfoque EAV se justifica solo cuando los atributos que se están modelando son numerosos y dispersos: si los datos que se capturan no cumplen este requisito, el enfoque EAV predeterminado de los proveedores de la nube a menudo no es adecuado para las aplicaciones que requieren una verdadera base de datos de back-end (en lugar de simplemente un medio de almacenamiento de datos persistente). Adaptar la gran mayoría de las aplicaciones de bases de datos existentes, que utilizan un enfoque de modelado de datos tradicional, a una arquitectura de nube de tipo EAV requeriría una cirugía mayor. Microsoft descubrió, por ejemplo, que su base de desarrolladores de aplicaciones de bases de datos era en gran medida reacia a invertir tal esfuerzo. Por lo tanto, en 2010, Microsoft lanzó una oferta premium, SQL Server Azure, un motor relacional completamente funcional y accesible desde la nube que permite la portabilidad de aplicaciones de bases de datos existentes con solo cambios modestos. A principios de la década de 2020, el servicio permite tamaños de bases de datos físicas de nivel estándar de hasta 8 TB, [35] con ofertas de "hiperescala" y "críticas para el negocio" también disponibles.