Hispanopedia Wiki
Articulo de referencia

Modelo entidad-atributo-valor

Un modelo entidad-atributo-valor ( EAV ) es un modelo de datos optimizado para el almacenamiento eficiente en espacio de valores de datos o propiedades dispersos o ad hoc , dise...

Hispanopedia WikiContenido en espanolLectura gratuita

Un modelo entidad-atributo-valor ( EAV ) es un modelo de datos optimizado para el almacenamiento eficiente en espacio de valores de datos o propiedades dispersos o ad hoc , diseñado para situaciones donde los patrones de uso en tiempo de ejecución son arbitrarios, están sujetos a variaciones del usuario o son imprevisibles con un diseño fijo. Este caso de uso se dirige a aplicaciones que ofrecen un sistema amplio o complejo 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 pequeña selección 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 matriz dispersa . El EAV también se conoce como modelo objeto-atributo-valor , modelo de base de datos vertical y esquema abierto .

Estructura de datos

Esta representación de datos es análoga a los métodos de almacenamiento de matrices dispersas que optimizan el 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 único hecho. Las tablas EAV suelen describirse como "largas y estrechas": "largas" se refiere al número de filas y "estrechas" a la cantidad de columnas.

Los datos se registran en tres columnas:

  • La entidad : el elemento que se describe.
  • El atributo o parámetro se implementa normalmente como una clave externa en una tabla de definiciones de atributos. Esta tabla puede contener las siguientes columnas: un ID de atributo, nombre del atributo, descripción, tipo de datos y columnas que facilitan la validación de la entrada, como la longitud máxima de la cadena y la expresión regular, el conjunto de valores permitidos, etc.
  • El valor del atributo.

Ejemplo

Consideremos cómo se representaría un registro clínico general en una base de datos relacional. Es evidente que crear una tabla (o un conjunto de tablas) con miles de columnas no es factible, ya que la gran mayoría serían nulas . Para complicar aún más las cosas, en un registro médico longitudinal que sigue al paciente a lo largo del tiempo, puede haber múltiples valores para un mismo parámetro: la altura y el peso de un niño, por ejemplo, cambian a medida que crece. Finalmente, el universo de hallazgos clínicos sigue creciendo: por ejemplo, surgen enfermedades y se diseñan nuevas pruebas de laboratorio; esto requeriría la adición constante de columnas y la revisión continua de la interfaz de usuario. El término "volatilidad de atributos" se utiliza a veces para describir los problemas o situaciones que surgen cuando la lista de atributos disponibles o sus definiciones necesitan evolucionar con el tiempo.

A continuación se muestra una selección de filas de una tabla EAV con los hallazgos clínicos de una visita al médico por fiebre la mañana del 1 de mayo de 1998. Las entradas entre corchetes angulares son referencias a entradas de otras tablas, que se muestran aquí como texto en lugar de como valores de clave externa codificados para facilitar su comprensión. En este ejemplo, todos los valores son literales, pero también podrían ser listas de valores predefinidas. Estas últimas son especialmente útiles cuando se sabe que los valores posibles son limitados (es decir, enumerables ).

  • La entidad . Para los hallazgos clínicos, la entidad es el evento del paciente : una clave externa en una tabla que contiene como mínimo un ID de paciente y una o más marcas de tiempo (por ejemplo, la fecha y hora de inicio y fin del examen) que registran cuándo ocurrió el evento que se describe.
  • El atributo o parámetro : una clave externa en una tabla de definiciones de atributos (en este ejemplo, definiciones de hallazgos clínicos). Como mínimo, la tabla de definiciones de atributos contendría las siguientes columnas: un ID de atributo, nombre del atributo, descripción, tipo de datos , unidades de medida y columnas que faciliten la validación de la entrada, por ejemplo, longitud máxima de la cadena y expresión regular, valores máximos y mínimos permitidos, conjunto de valores permitidos, etc.
  • El valor del atributo. Esto dependería del tipo de dato, y en breve explicaremos cómo se almacenan los valores.

El siguiente ejemplo ilustra los síntomas que podrían observarse en un paciente con neumonía .

Los datos EAV descritos anteriormente son comparables al contenido de un recibo de compra de supermercado (que se reflejaría en una tabla de artículos de venta en una base de datos). El recibo solo detalla los artículos comprados, en lugar de enumerar todos los productos que el cliente podría haber comprado pero no adquirió. Al igual que los hallazgos clínicos de un paciente, el recibo de compra es una representación compacta de datos inherentemente dispersos.

  • La "entidad" es el ID de venta/transacción  , una clave externa que apunta a una tabla de transacciones de venta. Esto se usa para etiquetar cada artículo internamente, aunque en el recibo la información sobre la venta aparece en la parte superior (ubicación de la tienda, fecha y hora de la venta) y en la parte inferior (valor total de la venta).
  • El atributo es una clave externa que apunta a una tabla de productos, desde donde se consulta la descripción, el precio unitario, los descuentos y las promociones, etc. (Los productos son tan volátiles como los hallazgos clínicos, o incluso más: cada mes se lanzan nuevos productos, mientras que otros se retiran del mercado si la aceptación del consumidor es baja. Ningún diseñador de bases de datos competente codificaría productos individuales como Doritos o Coca-Cola Light como columnas en una tabla).
  • Los "valores" son la cantidad comprada y el precio total de cada artículo.

El modelado por filas , donde los datos sobre algo (en este caso, una transacción de venta) se registran como varias filas en lugar de varias columnas , es una técnica estándar de modelado de datos. Las diferencias entre el modelado por filas y EAV (que puede considerarse una generalización del modelado por filas) son:

  • Una tabla modelada por filas es homogénea en los hechos que describe: una tabla de artículos describe únicamente los productos vendidos. Por el contrario, una tabla EAV contiene prácticamente cualquier tipo de hecho.
  • El tipo de datos de la columna o columnas de valores en una tabla modelada por filas viene predeterminado por la naturaleza de los datos que registra. En cambio, en una tabla EAV, el tipo de datos conceptual de un valor en una fila específica depende del atributo de esa fila. Por lo tanto, en sistemas de producción, permitir la entrada directa de datos en una tabla EAV sería un desastre, ya que el propio motor de la base de datos no podría realizar una validación de entrada robusta. Más adelante veremos cómo es posible crear marcos genéricos que realicen la mayoría de las tareas de validación de entrada, sin necesidad de una codificación interminable atributo por atributo.

En un repositorio de datos clínicos, el modelado de filas también tiene numerosos usos; el subesquema de pruebas de laboratorio se modela típicamente de esta manera, porque los resultados de las pruebas de laboratorio suelen ser numéricos o pueden codificarse numéricamente.

Las circunstancias en las que sería necesario ir más allá del modelado de filas estándar para utilizar EAV se enumeran a continuación:

  • El tipo de datos de los atributos individuales varía (como se observa en los hallazgos clínicos).
  • Las categorías de datos son numerosas, en constante crecimiento o fluctuación, pero el número de instancias (registros/filas) dentro de cada categoría es muy reducido. En este caso, con el modelado convencional, el diagrama entidad-relación de la base de datos podría tener cientos de tablas: las tablas que contienen miles o millones de filas/instancias se destacan visualmente al mismo nivel que aquellas con muy pocas filas. Estas últimas son candidatas para su conversión a una representación EAV. Esta situación se presenta en entornos de modelado de ontologías , donde las categorías ("clases") a menudo deben crearse sobre la marcha, y algunas clases suelen eliminarse en ciclos posteriores de prototipado.

Ciertas clases ("híbridas") poseen atributos que no son dispersos (es decir, presentes en todos o la mayoría de los casos), mientras que otros atributos son altamente variables y dispersos. Estos últimos son adecuados para el modelado EAV. Por ejemplo, las descripciones de los productos fabricados por un conglomerado dependen de la categoría del producto; por ejemplo, los atributos necesarios para describir una marca de bombillas son muy diferentes de los necesarios para describir un dispositivo de diagnóstico por imagen, pero ambos comparten atributos comunes como la unidad de embalaje y el costo unitario.

Descripción de conceptos

La entidad

En los datos clínicos, la entidad suele ser un evento clínico, como se describió anteriormente. En contextos más generales, la entidad es una clave externa a una tabla de "objetos" que registra información común sobre cada "objeto" (elemento) en la base de datos  ; como mínimo, un nombre preferido y una breve descripción, así como la categoría o clase de entidad a la que pertenece. A cada registro (objeto) en esta tabla se le asigna un identificador de objeto generado automáticamente.

El enfoque de "tabla de objetos" fue desarrollado por Tom Slezak y sus colegas en los Laboratorios Lawrence Livermore para la base de datos del cromosoma 19 , y ahora es estándar en la mayoría de las grandes bases de datos bioinformáticas . El uso de una tabla de objetos no exige el uso simultáneo de un diseño EAV: se pueden usar tablas convencionales para almacenar los detalles específicos de cada categoría de objeto.

La principal ventaja de una tabla central de objetos es que, al contar con una tabla complementaria de sinónimos y palabras clave, 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 sistemas de biociencias, donde una palabra clave como "acetilcolina" podría referirse tanto a la molécula en sí, que es un neurotransmisor, como al receptor biológico al que se une).

El atributo

En la tabla EAV, se trata simplemente de un identificador de atributo, una clave externa que apunta a una tabla de definiciones de atributos, como se indicó anteriormente. Sin embargo, normalmente existen varias tablas de metadatos que contienen información relacionada con los atributos, las cuales se describirán más adelante.

El valor

Convertir todos los valores a cadenas, como en el ejemplo de datos EAV anterior, da como resultado una estructura simple, pero no escalable: se requieren conversiones constantes entre tipos de datos si se quiere hacer algo con los valores, y un índice en la columna de valores de una tabla EAV es prácticamente inútil. Además, no es conveniente almacenar grandes cantidades de datos binarios, como imágenes, codificados en Base64 en la misma tabla que enteros pequeños o cadenas. Por lo tanto, los sistemas más grandes utilizan tablas EAV separadas para cada tipo de dato (incluidos los objetos binarios grandes , "BLOBS"), donde los metadatos de un atributo determinado identifican la tabla EAV en la que se almacenarán sus datos. Este enfoque es bastante eficiente porque la modesta cantidad de metadatos de atributos para una clase o formato determinado con el que un usuario elige trabajar se puede almacenar fácilmente en caché en la memoria. Sin embargo, requiere mover datos de una tabla a otra si se cambia el tipo de dato de un atributo.

Historia

EAV, como medio de propósito general de representación del conocimiento , se originó con el concepto de " listas de asociación " ( pares atributo-valor ). De uso común hoy en día, estos se introdujeron por primera vez en el lenguaje LISP . [ 1 ] Los pares atributo-valor se utilizan ampliamente para diversas aplicaciones, como archivos de configuración (utilizando una sintaxis simple como atributo = valor ). Un ejemplo de uso de EAV fuera de las bases de datos es 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 normalmente marca ("anota") un segmento: el ejemplo proporcionado en el tutorial de UIMA es un programa que realiza reconocimiento de entidades nombradas (NER) en un documento, anotando el segmento de texto "Presidente Bush" con la tripleta anotación-atributo-valor (Persona, Nombre_Completo, "George W. Bush") . [ 2 ] Dichas anotaciones pueden almacenarse en una tabla de base de datos.

Aunque 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 Regenstrief (el esfuerzo liderado por Clement MacDonald), [ 4 ] el sistema TMR (The Medical Record) de William Stead y Ed Hammond y el HELP Clinical Data Repository (CDR) creado por el grupo de Homer Warner en el LDS Hospital, Salt Lake City, Utah. [ 5 ] [ 6 ] (El sistema Regenstrief utilizaba un diseño Paciente-Atributo-Marca de tiempo-Valor: el uso de la marca de tiempo permitía recuperar 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 posteriormente adaptado a una arquitectura relacional y comercializado por la corporación 3M. (Cabe destacar que, si bien el artículo fundamental de Codd se publicó en 1970, su marcado tono matemático tuvo el desafortunado efecto de disminuir su accesibilidad entre personas ajenas al ámbito de la informática y, en consecuencia, retrasar la aceptación del modelo en los círculos de TI y de proveedores de software. El valor de la posterior contribución de Christopher J. Date , colega de Codd en IBM, al traducir estas ideas a un lenguaje accesible, acompañadas de ejemplos sencillos que ilustraban su potencial, es incalculable).

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 del 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.

Uso en bases de datos

El término "base de datos EAV" se refiere a un diseño de base de datos donde 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 mencionó anteriormente, el modelado EAV tiene sentido para categorías de datos, como los hallazgos clínicos, donde los atributos son numerosos y escasos. Cuando estas condiciones no se cumplen, es preferible el modelado relacional estándar (es decir, una columna por atributo); usar EAV no implica abandonar el sentido común ni los principios de un buen diseño relacional. En los sistemas de registros clínicos, los subesquemas relacionados con la demografía del paciente y la facturación suelen modelarse de forma 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 de los Estados Unidos (VA), 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ó en breve, una base de datos EAV es prácticamente imposible de mantener sin numerosas tablas auxiliares que contengan metadatos . Estas tablas de metadatos, que suelen triplicar o triplicar el número de tablas EAV, son generalmente tablas relacionales estándar. [ 8 ] [ 9 ] Un ejemplo de tabla de metadatos es la tabla de Definiciones de Atributos mencionada anteriormente.

EAV/CR: representación de subestructuras con clases y relaciones

En un diseño EAV simple, los valores de un atributo son tipos de datos simples o primitivos para el motor de base de datos. Sin embargo, en sistemas EAV utilizados para la representación de datos muy diversos, es posible que un objeto dado (instancia de clase) tenga subestructura: es decir, algunos de sus atributos pueden representar otros tipos de objetos, que a su vez pueden tener subestructura, con un nivel de complejidad arbitrario. Un automóvil, por ejemplo, tiene un motor, una transmisión, etc., y el motor tiene componentes como cilindros. (La subestructura permitida para una clase dada se define dentro de los metadatos de atributos del sistema, como se explica 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 tanto si los detalles de una clase individual se representan en formato convencional como EAV; dicho recorrido se realiza, por ejemplo, en los sistemas objeto-relacionales estándar. 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 debidas a la recursión son mínimas, especialmente con la indexación de los ID de los objetos.

EAV/CR (EAV con Clases y Relaciones) [ 11 ] [ 12 ] [ 13 ] se refiere a un marco que admite subestructuras complejas. Su nombre es algo engañoso: si bien fue una derivación del trabajo en sistemas EAV, en la práctica, muchas o incluso la mayoría de las clases en dicho sistema pueden representarse en forma relacional estándar, según 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 sobre las tablas de datos, y algunas de estas consultas pueden ser arbitrariamente recursivas. Este enfoque funciona bien para consultas de un objeto a la vez, como en las interfaces de navegación web donde al hacer clic en el nombre de un objeto se muestran todos los detalles del objeto en una página separada: los metadatos asociados a la clase de ese objeto también facilitan la presentación de los detalles del objeto, ya que incluyen títulos de los atributos individuales, el orden en que deben presentarse y cómo deben agruparse.

Una estrategia para EAV/CR consiste en permitir que las columnas contengan estructuras JSON , lo que proporciona la estructura de clases 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 combinar atributos JSON.

Metadatos

En palabras del Prof. Dr. Daniel Masys (exdirector del Departamento de Informática Médica de la Universidad de Vanderbilt), los desafíos de trabajar con EAV se derivan 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",  es decir, la forma en que los usuarios y muchas aplicaciones de software, como los paquetes estadísticos, lo consideran, como filas y columnas convencionales para clases individuales. (Dado que una tabla EAV conceptualmente mezcla peras con manzanas, naranjas, pomelos y chop suey, si se desea realizar algún análisis de los datos utilizando software estándar disponible comercialmente, en la mayoría de los casos es necesario convertir subconjuntos de los mismos a formato columnar. [ 14 ] El proceso de hacer esto, llamado pivotar , es lo suficientemente importante como para ser tratado por separado).

Los metadatos permiten a los usuarios interactuar con el sistema basándose en el esquema lógico en lugar del físico: el software consulta continuamente los metadatos para diversas operaciones, como la presentación de datos, la validación interactiva, la extracción masiva de datos y las consultas ad hoc . De hecho, los metadatos pueden utilizarse para personalizar el comportamiento del sistema.

Los sistemas EAV sacrifican la simplicidad en la estructura física y lógica de los datos a cambio de la complejidad en sus metadatos, que, entre otras cosas, cumplen la función que las restricciones de la base de datos y la integridad referencial desempeñan en los diseños de bases de datos estándar. Esta compensación suele ser ventajosa, ya que en el esquema mixto típico de los sistemas de producción, los datos en tablas relacionales convencionales también pueden beneficiarse de funcionalidades como la generación automática de interfaces. La estructura de los metadatos es lo suficientemente compleja como para constituir su propio subesquema dentro de la base de datos: varias claves foráneas en las tablas de datos hacen referencia a tablas dentro de este subesquema. Este subesquema es relacional estándar, y características como las restricciones y la integridad referencial se utilizan al máximo.

La corrección del contenido de los metadatos, en lo que respecta al comportamiento previsto del sistema, es fundamental. Garantizar dicha corrección implica que, al crear un sistema EAV, se deben realizar importantes esfuerzos de diseño para desarrollar interfaces de usuario que permitan la edición de metadatos por parte de miembros del equipo familiarizados con el ámbito del problema (por ejemplo, medicina clínica), aunque no sean necesariamente programadores. (Históricamente, una de las principales razones por las que el sistema TMR pre-relacional no se adoptó en otros centros además de su institución de origen fue que todos los metadatos se almacenaban en un único archivo con una estructura poco intuitiva. Personalizar el comportamiento del sistema modificando el contenido de este archivo, sin provocar fallos en el sistema, era una tarea tan delicada que sus creadores solo confiaban en sí mismos para llevarla a cabo).

Cuando un sistema EAV se implementa mediante RDF , el lenguaje de esquema RDF puede utilizarse convenientemente para expresar dichos metadatos. Esta información de esquema puede ser utilizada posteriormente por el motor de base de datos EAV para reorganizar dinámicamente su estructura de tabla interna y lograr la máxima eficiencia. [ 15 ]

Algunas advertencias finales con respecto a los metadatos:

  • Dado que la lógica de negocio reside en los metadatos en lugar de estar explícitamente definida en el esquema de la base de datos (es decir, un nivel por debajo, en comparación con los sistemas de diseño tradicional), resulta menos evidente para quienes no están familiarizados con el sistema. Por lo tanto, las herramientas de exploración e informes de metadatos son fundamentales para garantizar la mantenibilidad de un sistema EAV. En el caso común en que los metadatos se implementan como un subesquema relacional, estas herramientas no son más que aplicaciones creadas con herramientas de consulta o informes estándar que operan sobre las tablas de metadatos.
  • Un usuario con conocimientos insuficientes puede corromper fácilmente los metadatos (introduciendo inconsistencias y errores). Por lo tanto, es necesario restringir el acceso a los metadatos y establecer un registro de auditoría de los accesos y cambios para gestionar situaciones en las que varias personas tengan acceso a ellos. El uso de un sistema de gestión de bases de datos relacionales (RDBMS) para los metadatos simplifica el mantenimiento de la coherencia durante su creación y edición, gracias a las funcionalidades del RDBMS, como la compatibilidad con transacciones. Además, si los metadatos forman parte de la misma base de datos que los datos, se garantiza que se realicen copias de seguridad con la misma frecuencia, permitiendo su recuperación a un punto específico en el tiempo.
  • La calidad de la anotación y la documentación dentro de los metadatos (es decir, el texto narrativo/explicativo en las columnas descriptivas del subesquema de metadatos) debe ser mucho mayor para facilitar la comprensión por parte de los distintos miembros del equipo de desarrollo. Garantizar la calidad de los metadatos (y mantenerlos actualizados a medida que el sistema evoluciona) es una prioridad muy alta en la gestión y el mantenimiento a largo plazo de cualquier diseño que utilice un componente EAV. Los metadatos mal documentados o desactualizados pueden comprometer la viabilidad a largo plazo del sistema. [ 16 ] [ 17 ]

Información capturada en los metadatos

metadatos de atributos

  • Los metadatos de validación incluyen el tipo de dato, el rango de valores permitidos o la pertenencia a un conjunto de valores, la coincidencia con expresiones regulares, el valor predeterminado y si se permite que el valor sea nulo. En los sistemas EAV que representan clases con subestructura, los metadatos de validación también registrarán a qué clase, si corresponde, pertenece un atributo determinado.
  • Metadatos de presentación : cómo se mostrará el atributo al usuario (por ejemplo, como un cuadro de texto o una imagen de dimensiones específicas, una lista desplegable o un conjunto de botones de opción). Cuando un objeto compuesto está formado por varios atributos, como en el diseño EAV/CR, existen metadatos adicionales sobre el orden en que deben presentarse los atributos y cómo deben agruparse opcionalmente (bajo encabezados descriptivos).
  • Para los atributos que resultan ser parámetros de laboratorio, se registran rangos de valores normales , que pueden variar según la edad, el sexo, el estado fisiológico y el método de análisis.
  • Metadatos de agrupación : Los atributos se presentan normalmente como parte de un grupo de orden superior, por ejemplo, un formulario específico de una especialidad. Los metadatos de agrupación incluyen información como el orden en que se presentan los atributos. Ciertos metadatos de presentación, como las fuentes/colores y el número de atributos que se muestran por fila, se aplican al grupo en su conjunto.

metadatos de validación avanzada

  • Metadatos de dependencia : en muchas interfaces de usuario, se requiere ingresar valores específicos en ciertos campos o atributos para deshabilitar u ocultar otros campos, o para habilitar o mostrar otros. (Por ejemplo, si un usuario selecciona la respuesta "No" a la pregunta booleana "¿Tiene el paciente diabetes?", entonces las preguntas posteriores sobre la duración de la diabetes, los medicamentos para la diabetes, etc., deben deshabilitarse). Para lograr esto en un marco genérico, es necesario almacenar las dependencias entre los atributos de control y los atributos controlados.
  • Cálculos y validación compleja : Al igual que en una hoja de cálculo, el valor de ciertos atributos se puede calcular y mostrar en función de los valores introducidos en campos presentados previamente en secuencia. (Por ejemplo, la superficie corporal depende de la altura y el ancho). De forma similar, puede haber "restricciones" que deben cumplirse para que los datos sean válidos: por ejemplo, en un recuento diferencial de glóbulos blancos, la suma de los recuentos de los distintos tipos de glóbulos blancos siempre debe ser igual a 100, ya que los recuentos individuales representan porcentajes. Las fórmulas calculadas y la validación compleja generalmente se implementan almacenando expresiones en los metadatos, que se sustituyen mediante macros con los valores introducidos por el usuario y se pueden evaluar. En los navegadores web, tanto JavaScript como VBScript disponen de la función Eval(), que se puede utilizar para este fin.

La validación, presentación y agrupación de metadatos permiten la creación de marcos de código que facilitan 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 distribuido a través de la web, la validación de datos EAV se traslada del nivel de back-end/base de datos (que carece de capacidad para esta tarea) al nivel intermedio/servidor web. Si bien la validación en el back-end es siempre la ideal, ya que es imposible eludirla mediante la introducción directa de datos en una tabla, la validación en el nivel intermedio a través de un marco genérico resulta bastante viable, aunque requiere un esfuerzo considerable en el diseño del software para su construcción previa. La disponibilidad de marcos de código abierto que pueden estudiarse y modificarse según las necesidades individuales contribuye en gran medida a evitar la duplicación de esfuerzos.

Escenarios de uso

(La primera parte de esta sección es un resumen del artículo de referencia de Dinu/Nadkarni en Central, [ 18 ] al que se remite al lector para obtener más detalles).

El modelado EAV, también conocido como " modelado de datos genérico " o "esquema abierto", ha sido durante mucho tiempo una herramienta estándar para los modeladores de datos avanzados. Como toda técnica avanzada, puede ser un arma de doble filo y debe usarse con prudencia.

Además, el uso de EAV no excluye el uso de enfoques tradicionales de modelado de bases de datos relacionales dentro del mismo esquema de base de datos. En los sistemas de registros médicos electrónicos (EMR) que se basan en un sistema de gestión de bases de datos relacionales (RDBMS), como Cerner , que utilizan un enfoque EAV para su subesquema de datos clínicos, la gran mayoría de las tablas del esquema se modelan de forma tradicional, con los atributos representados como columnas individuales en lugar de como filas.

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, el número de tablas de metadatos en el esquema supera al de tablas de datos en una proporción aproximada de diez a uno. Dado que la corrección y la coherencia de los metadatos son fundamentales para el correcto funcionamiento de un sistema EAV, el diseñador del sistema busca aprovechar al máximo todas las funcionalidades que ofrecen los sistemas de gestión de bases de datos relacionales (RDBMS), como la integridad referencial y las restricciones programables, en lugar de tener que reinventar la rueda del motor de un RDBMS. En consecuencia, las numerosas tablas de metadatos que dan soporte a los diseños EAV suelen estar en forma relacional de tercera normal.

Los sistemas comerciales de registros electrónicos de salud (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 segregan en tablas separadas. En cada tabla, la "entidad" es un compuesto 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 a una tabla de búsqueda especialmente designada que contiene un vocabulario controlado, por ejemplo, CIE-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, si está dentro del 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 indicó anteriormente, este no es un enfoque EAV completo porque el dominio de 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 sistemas de historia clínica electrónica (HCE) también ofrecen un mecanismo EAV "puro", donde usuarios avanzados especialmente designados pueden definir nuevos atributos, su tipo de datos, valores máximos y mínimos permitidos (o un conjunto de valores/códigos permitidos) y, posteriormente, permitir que otros capturen datos en función de estos atributos. En el sistema de HCE Epic™, este mecanismo se denomina "hojas de flujo" y se utiliza habitualmente para capturar datos de observación de enfermería de pacientes hospitalizados.

Modelado de atributos dispersos

El caso típico para usar el 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 mencionó 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. (Por ejemplo, los datos demográficos de los pacientes se modelan de forma más natural en una estructura relacional tradicional de una columna por atributo).

En consecuencia, los argumentos sobre EAV frente al diseño relacional reflejan una comprensión incompleta del problema: un diseño EAV solo debería emplearse para el subesquema de una base de datos donde se necesite modelar atributos dispersos; incluso en este caso, deben ser compatibles con tablas de metadatos en tercera forma normal . Existen relativamente pocos problemas de diseño de bases de datos donde se encuentren atributos dispersos; por eso, las circunstancias en las que el diseño EAV es aplicable son relativamente raras. Incluso cuando se encuentran, un conjunto de tablas EAV no es la única forma de abordar los datos dispersos: una solución basada en XML (que se analiza más adelante) 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 presentarse en situaciones de comercio electrónico donde una organización compra o vende un conjunto vasto y muy diverso de productos, y los detalles de las categorías individuales de productos varían considerablemente.

Modelado de numerosas clases con muy pocas instancias por clase: esquemas altamente dinámicos.

Otra aplicación de EAV reside en 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 es relativamente modesto  (como máximo un par de cientos, aunque normalmente son unas pocas docenas). Además, el desarrollador del sistema debe proporcionar una interfaz web para el usuario final en un plazo muy breve. El término "dinámico" implica que es necesario definir y modificar continuamente nuevas clases y atributos para representar un modelo de datos en constante 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 web que permitan la navegación o la edición básica con validación por tipo y rango sí lo requiere. En tal caso, una solución a largo plazo más fácil de mantener consiste en crear un marco donde las definiciones de clase y atributo 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, se creó para abordar precisamente esta situación. Cabe destacar que un modelo de datos EAV no es esencial en este caso, pero el diseñador del sistema puede considerarlo una alternativa aceptable a la creación de, por ejemplo, sesenta o más tablas con un total de no más de dos mil filas. En este caso, dado que el número de filas por clase es tan reducido, las consideraciones de eficiencia son menos importantes; con la indexación estándar por ID de clase/ID de atributo, los optimizadores del sistema de gestión de bases de datos pueden almacenar fácilmente en caché los datos de una clase pequeña en memoria al ejecutar una consulta que involucre dicha clase o atributo.

En el escenario de atributos dinámicos, cabe destacar que el Resource Description Framework (RDF) se utiliza como base para el trabajo de ontología relacionado con la Web Semántica. RDF, concebido como un método general para representar información, es una forma de EAV: una tripleta RDF se compone de 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 generalmente también lo hace más difícil de entender y mantener, por lo que no se debe apresurar a modificar el código a menos que primero se haya determinado que existe un problema de rendimiento y que medidas como el análisis de rendimiento del código hayan identificado la ubicación exacta del cuello de botella. Una vez hecho esto, solo se modifica el código específico que necesita ejecutarse más rápido. Consideraciones similares se aplican al modelado EAV: se aplica solo al subsistema donde se sabe a priori que el modelado relacional tradicional es engorroso (como en el dominio de datos clínicos), o se descubre, durante la evolución del sistema, que plantea importantes desafíos de mantenimiento. El gurú de bases de datos (y actualmente vicepresidente de Tecnologías Centrales en Oracle Corporation), Tom Kyte, [ 19 ] , por ejemplo, señala correctamente las desventajas de emplear EAV en escenarios comerciales tradicionales y hace hincapié en que la mera "flexibilidad" no es un criterio suficiente para emplear EAV. (Sin embargo, afirma categóricamente que se debe evitar la EAV en todas las circunstancias, a pesar de que la propia división de Ciencias de la Salud de Oracle emplea la EAV para modelar atributos de datos clínicos en sus sistemas comerciales ClinTrial [ 20 ] y Oracle Clinical. [ 21 ] )

Trabajar con datos EAV

El punto débil de EAV reside en la dificultad de trabajar con grandes volúmenes de datos EAV. A menudo es necesario realizar conversiones, transitorias o permanentes, entre representaciones columnares y de filas (o modeladas en EAV) de los mismos datos; esto puede ser propenso a errores si se realiza manualmente, además de consumir muchos recursos de la CPU. Los marcos genéricos que utilizan metadatos de atributos y agrupaciones de atributos solucionan la primera limitación, pero no la segunda; su uso es prácticamente obligatorio en el caso de esquemas mixtos que contienen una combinación de datos relacionales convencionales y EAV, donde el índice 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 tipo de datos modelados por filas. (Por ejemplo, las implementaciones del algoritmo Apriori para el análisis de asociaciones, ampliamente utilizado para procesar datos de ventas de supermercados e identificar otros productos que los compradores de un producto determinado probablemente también adquieran, realizan un pivoteo de los datos modelados por filas como primer paso). Muchos motores de bases de datos cuentan con extensiones SQL propietarias para facilitar el pivoteo, y programas como Microsoft Excel también lo admiten. A continuación, se analizan las circunstancias en las que es necesario realizar un pivoteo.

  • Exploración de pequeñas cantidades de datos para una entidad individual, seguida opcionalmente de la edición de datos según las dependencias entre atributos. Esta operación se facilita mediante el almacenamiento en caché de las pequeñas cantidades de metadatos de soporte necesarios. Algunos programas, como TrialDB, acceden a los metadatos para generar páginas web semiestáticas que contienen código de programación integrado, así como estructuras de datos que almacenan los metadatos.
  • La extracción masiva transforma grandes cantidades de datos (predecibles, por ejemplo, los datos completos de un estudio clínico) en un conjunto de tablas relacionales. Si bien consume muchos recursos de la CPU, esta tarea es poco frecuente y no requiere procesamiento en tiempo real; es decir, el usuario puede esperar a que finalice el proceso por lotes. La importancia de la extracción masiva es fundamental, especialmente cuando los datos se procesan o analizan con herramientas estándar de terceros que desconocen por completo la estructura EAV. En este caso, no es recomendable reinventar la rueda con un marco genérico; lo mejor es extraer los datos EAV en tablas relacionales y luego trabajar con ellos utilizando herramientas estándar.
  • Las interfaces de consulta ad hoc para datos modelados por filas o EAV, cuando se consultan desde la perspectiva de atributos individuales (por ejemplo, "recuperar todos los pacientes con enfermedad hepática, signos de insuficiencia hepática y sin antecedentes de abuso de alcohol"), generalmente deben mostrar los resultados de la consulta con los atributos individuales como columnas separadas. Para la mayoría de los escenarios de bases de datos EAV, el rendimiento de las consultas ad hoc debe ser aceptable, pero no se requieren respuestas en menos de un segundo, ya que las consultas suelen ser de naturaleza exploratoria.

División relacional

Sin embargo, la estructura del modelo de datos EAV es ideal para la división relacional (véase álgebra relacional ). Con una buena estrategia de indexación, es posible obtener un tiempo de respuesta inferior a unos pocos cientos de milisegundos en una tabla EAV de mil millones de filas. Peter Larsson, MVP de Microsoft SQL Server, lo demostró en un portátil y puso la solución a disposición del público general. [ 22 ]

Optimización del rendimiento de pivoteo

  • Una posible optimización consiste en utilizar un " almacén " o esquema consultable independiente, cuyo contenido se actualiza por lotes desde el esquema de producción (transaccional). Véase almacenamiento de datos . Las tablas del almacén están altamente indexadas y optimizadas mediante la desnormalización , que combina varias tablas en una sola para minimizar la penalización de rendimiento debida a las uniones de tablas.
  • Ciertos datos EAV en un almacén pueden convertirse en tablas estándar utilizando " vistas materializadas " (véase almacén de datos ), pero esto generalmente es un último recurso que debe usarse con cuidado, porque el número de vistas de este tipo tiende a crecer de forma no lineal con el número de atributos en un sistema. [ 14 ]
  • Estructuras de datos en memoria : Se pueden usar tablas hash y matrices bidimensionales en memoria junto con metadatos de agrupación de atributos para pivotar datos, un grupo a la vez. Estos datos se escriben en disco como un archivo plano delimitado, con los nombres internos para cada atributo en la primera fila: este formato se puede importar fácilmente en bloque a una tabla relacional. Esta técnica "en memoria" supera significativamente los enfoques alternativos al mantener las consultas en tablas EAV lo más simples posible y minimizar el número de operaciones de E/S. [ 14 ] Cada instrucción recupera una gran cantidad de datos, y las tablas hash ayudan a llevar a cabo la operación de pivote, que implica colocar un valor para una instancia de atributo dada en la fila y columna apropiadas. La memoria de acceso aleatorio (RAM) es suficientemente abundante y asequible en el hardware moderno como para que el conjunto de datos completo para un solo grupo de atributos, incluso en conjuntos de datos grandes, generalmente quepa completamente en la memoria, aunque el algoritmo se puede hacer más inteligente trabajando con porciones de los datos si esto resulta no ser el caso.

Obviamente, independientemente del enfoque que se adopte, consultar datos EAV no será tan rápido como consultar datos relacionales estándar modelados por columnas para ciertos tipos de consultas, de forma similar a como el acceso a elementos en matrices dispersas no es tan rápido como en matrices no dispersas si estas últimas caben completamente en la memoria principal. (Las matrices dispersas, representadas mediante estructuras como listas enlazadas, requieren recorrer la lista para acceder a un elemento en una posición XY determinada, mientras que el acceso a elementos en matrices representadas como arreglos 2D se puede realizar mediante operaciones rápidas de registro de la CPU). Sin embargo, si se eligió correctamente el enfoque EAV para el problema que se intentaba resolver, este es el precio que se paga; en este sentido, el modelado EAV es un ejemplo de una compensación entre espacio (y mantenimiento del esquema) y tiempo de CPU.

Alternativas

EAV frente al modelo de datos universal

Originalmente postulado por Maier, Ullman y Vardi, [ 23 ] el "Modelo de Datos Universal" (UDM) busca simplificar la consulta de un esquema relacional complejo para usuarios inexpertos, creando la ilusión de que todo está almacenado en una única "tabla universal" gigante. Esto se logra mediante el uso de 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 donde una tabla está relacionada múltiplemente con otra (como en bases de datos genealógicas, 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 centralmente y una organización puede tener diferentes direcciones de oficina y de envío), no hay suficientes metadatos dentro del esquema de la base de datos para especificar uniones inequívocas. Cuando UDM se ha comercializado, 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 del "Universo" resuelve las uniones ambiguas incluyendo la tabla relacionada en una vista varias veces utilizando diferentes alias.

Aparte de la forma en que se modelan explícitamente los datos (UDM simplemente usa vistas relacionales para interceder entre el usuario y el esquema de la base de datos), EAV se diferencia de los Modelos Universales de Datos en que también se aplica a sistemas transaccionales, no solo a sistemas orientados a consultas (de solo lectura) como en UDM. Además, cuando se usa como base para sistemas de consulta de datos clínicos, las implementaciones de EAV no necesariamente eximen 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 que le interesa. Por ejemplo, la frase " litio " puede referirse tanto al medicamento (que se usa para tratar el trastorno bipolar ) como a un análisis de laboratorio para medir el nivel de litio en la sangre del paciente. (El nivel de litio en sangre debe controlarse cuidadosamente: un exceso del medicamento causa efectos secundarios graves, mientras que una cantidad insuficiente es ineficaz).

XML y JSON

Una implementación de Open Schema 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 dispersos y jerárquicos se pueden representar como JSON. Si la base de datos tiene soporte para JSON, como PostgreSQL y (parcialmente) SQL Server 2016 y posteriores, entonces los atributos se pueden consultar, indexar y unir. Esto puede ofrecer mejoras de rendimiento de más de 1000 veces sobre las implementaciones EAV ingenuas, [ 27 ] pero no necesariamente hace que la aplicación de base de datos en general sea más robusta.

Cabe destacar que existen dos maneras de almacenar datos XML o JSON: una consiste en almacenarlos como una cadena de texto simple, opaca para el servidor de base de datos; la otra consiste en utilizar un servidor de base de datos que pueda acceder a su estructura. Obviamente, almacenar cadenas opacas presenta graves inconvenientes: no se pueden consultar directamente, no se puede crear un índice basado en su contenido y es imposible realizar uniones basadas en dicho contenido.

Crear una aplicación que deba gestionar datos se vuelve extremadamente complicado al usar modelos EAV, debido a la magnitud de la infraestructura que debe desarrollarse en términos de tablas de metadatos y código del marco de la aplicación. El uso de XML resuelve el problema de la validación de datos basada en el servidor (que debe realizarse mediante código de nivel intermedio y basado en el navegador en marcos basados ​​en EAV), pero tiene los siguientes inconvenientes:

  • Es un proceso que requiere mucha programación. Los esquemas XML son notoriamente difíciles de escribir manualmente; un enfoque recomendado es crearlos definiendo tablas relacionales, generando código de esquema XML y luego eliminando estas tablas. Esto resulta problemático en muchas operaciones de producción que involucran esquemas dinámicos, donde se requiere que los nuevos atributos sean definidos por usuarios avanzados que comprenden un dominio de aplicación específico (por ejemplo, gestión de inventario o biomedicina) pero que no son necesariamente programadores. Por el contrario, en los sistemas de producción que utilizan EAV, dichos usuarios definen nuevos atributos (y el tipo de datos y las comprobaciones de validación asociadas a cada uno) a través de una aplicación con interfaz gráfica de usuario (GUI). Dado que los metadatos asociados a la validación deben almacenarse en múltiples tablas relacionales en un diseño normalizado, una aplicación GUI que vincule estas tablas y aplique las comprobaciones de coherencia de metadatos adecuadas es la única forma práctica de permitir la entrada de información de atributos, incluso para desarrolladores avanzados, incluso si el resultado final utiliza XML o JSON en lugar de tablas relacionales separadas.
  • Los diagnósticos basados ​​en el servidor que resultan de una solución XML/JSON cuando se intenta insertar datos incorrectos (por ejemplo, comprobación de rango o violaciones de patrones de expresiones regulares) son crípticos para el usuario final: para transmitir el error con precisión, sería necesario, como mínimo, asociar un diagnóstico de error detallado y fácil de usar a cada atributo.
  • La solución no aborda el problema de la generación de la interfaz de usuario.

Todos los inconvenientes mencionados se pueden solucionar creando una capa de metadatos y código de aplicación, pero al hacerlo, desaparece la "ventaja" original de no tener que crear un marco de trabajo. De hecho, modelar atributos de datos dispersos de forma robusta es un problema complejo de diseño de aplicaciones de bases de datos, independientemente del método de almacenamiento utilizado. Sin embargo, el trabajo de Sarka [ 26 ] demuestra la viabilidad de usar un campo XML en lugar de tablas relacionales EAV específicas para cada tipo de dato en la capa de almacenamiento de datos, y en situaciones donde el número de atributos por entidad es moderado (por ejemplo, atributos de producto variables para diferentes tipos de producto), 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 atributo-valor, aunque se basa en texto estructurado en lugar de tablas relacionales).

Estructuras de árbol y bases de datos 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 separados 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 logran, mejoran o sustituyen el enfoque del modelo EAV.

Los usos de JSON y XML no son necesariamente los mismos que los de un modelo EAV, aunque pueden superponerse. XML es preferible a EAV para datos jerárquicos arbitrarios de volumen relativamente modesto para una sola entidad: no está diseñado para escalar a nivel de varios gigabytes en cuanto al rendimiento de manipulación de datos. 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 principal. EAV, como se indicó anteriormente, es específicamente (y solo) aplicable al escenario de atributos dispersos. Cuando se da este escenario, el uso de tablas de atributos-valor específicas del tipo de datos que se pueden indexar por entidad, por atributo y por valor, y manipular mediante simples sentencias SQL, es mucho más escalable que el uso de una estructura de árbol XML. Google App Engine, mencionado anteriormente, utiliza tablas de valores fuertemente tipados por una buena razón.

bases de datos de grafos

Una alternativa para gestionar los diversos problemas que surgen con los datos estructurados EAV es emplear una base de datos de grafos . Estas representan las entidades como nodos de un grafo o hipergrafo , y los atributos como enlaces o aristas de dicho grafo. El problema de las uniones de tablas se resuelve 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 .

Consideraciones para el software de servidor

PostgreSQL: Columnas JSONB

PostgreSQL versión 9.4 incluye soporte para columnas binarias JSON (JSONB), que se pueden consultar, indexar y unir. Esto permite mejoras de rendimiento de hasta mil veces 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 Entidad. Esto hace que el esquema de la base de datos sea fácil de comprender y las consultas SQL 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 ]

SQL Server 2008 y versiones posteriores: columnas dispersas

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 la columna de la instrucción CREATE TABLE. Las columnas dispersas optimizan el almacenamiento de valores NULL (que ahora no ocupan espacio alguno) y son útiles cuando la mayoría de los registros de una tabla tendrán valores NULL para esa columna. Los índices en las columnas dispersas también se optimizan: solo se indexan las 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 se agregan normalmente a él. Esto tiene la interesante consecuencia de que la sentencia SQL SELECT * from <tablename>no devolverá las columnas dispersas individualmente, sino que las concatenará todas en una única columna XML cuyo nombre coincide con el del conjunto de columnas (que, por lo tanto, actúa como una columna virtual calculada). Las columnas dispersas son útiles para aplicaciones empresariales como la información de productos, donde los atributos aplicables pueden variar considerablemente según el tipo de producto, pero donde el número total de atributos variables por tipo de producto es relativamente modesto.

Limitaciones de los atributos dispersos

Sin embargo, este enfoque para modelar atributos dispersos tiene varias limitaciones que los sistemas de gestión de bases de datos (DBMS) rivales, en particular, han optado por no adoptar para sus propios motores. Las limitaciones incluyen:

  • El número máximo de columnas dispersas en una tabla es de 10 000, lo que puede resultar insuficiente para algunas implementaciones, como el almacenamiento de datos clínicos, donde el número posible de atributos es un orden de magnitud mayor. Por lo tanto, esta no es una solución para modelar *todos* los atributos clínicos posibles de un paciente.
  • La adición de nuevos atributos  , una de las principales razones por las que se podría buscar un modelo EAV, aún requiere un administrador de bases de datos. Además, no se aborda el problema de crear una interfaz de usuario para datos de atributos dispersos: solo se optimiza el mecanismo de almacenamiento.
  • Es posible desarrollar aplicaciones que añadan y eliminen dinámicamente columnas dispersas de una tabla durante la ejecución. En cambio, intentar realizar dicha acción en un entorno multiusuario, donde otros usuarios o procesos siguen utilizando la tabla, se impediría si la tabla no contiene columnas dispersas. Sin embargo, si bien esta capacidad ofrece potencia y flexibilidad, también puede dar lugar a abusos, por lo que debe utilizarse con prudencia y poca frecuencia.
    • Esto puede ocasionar importantes penalizaciones en el rendimiento, en parte porque cualquier plan de consulta compilado que utilice esta tabla se invalida automáticamente.
    • La adición o eliminación dinámica de columnas es una operación que debe ser auditada, ya que la eliminación de columnas puede provocar la pérdida de datos: permitir que una aplicación modifique una tabla sin mantener algún tipo de registro, incluida una justificación de la acción, no es una buena práctica de software.
  • Las restricciones SQL (por ejemplo, comprobaciones de rango, comprobaciones de expresiones regulares) no se pueden aplicar a columnas dispersas. La única comprobación que se aplica es la del tipo de datos correcto. Las restricciones tendrían que implementarse en tablas de metadatos y en el código de la capa intermedia, como se hace en los sistemas EAV de producción. (Esta consideración también se aplica a las aplicaciones empresariales).
  • SQL Server tiene limitaciones en el tamaño de las filas si se intenta cambiar el formato de almacenamiento de una columna: el contenido total de todas las columnas de tipo de datos atómico, dispersas y no dispersas, en una fila que contengan datos no puede exceder los 8016 bytes si esa tabla contiene una columna dispersa para que los datos se copien automáticamente.
  • Las columnas dispersas que contienen datos tienen una sobrecarga de almacenamiento de 4 bytes por columna, además del almacenamiento propio del tipo de dato (por ejemplo, 4 bytes para las columnas de fecha y hora). Esto afecta la cantidad de datos de columnas dispersas que se pueden asociar a una fila determinada. Esta restricción de tamaño se flexibiliza para el tipo de dato varchar, lo que significa que, si se alcanzan los límites de tamaño de fila en un sistema de producción, es necesario sortearlos designando las columnas dispersas como varchar, aunque tengan un tipo de dato intrínseco diferente. Desafortunadamente, este enfoque ahora invalida la verificación del tipo de dato en el servidor.

Ofertas de computación en la nube

Muchos proveedores de computación en la nube ofrecen almacenes de datos basados ​​en el modelo EAV, donde se puede asociar un número arbitrario de atributos a una entidad determinada. Roger Jennings ofrece una comparación exhaustiva [ 34 ] de estos. En la oferta de Amazon, SimpleDB, el tipo de datos se limita a cadenas, y los datos que intrínsecamente no son cadenas deben convertirse a cadenas (por ejemplo, los números deben rellenarse con ceros iniciales) si se desea realizar operaciones como la ordenación. 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.El motor de aplicaciones de GoogleOfrece la mayor variedad de tipos de datos: además de dividir los datos numéricos en enteros, largos o de punto flotante, también define tipos de datos personalizados como números de teléfono, direcciones de correo electrónico, geocodificación e hipervínculos. Google, a diferencia de Amazon y Microsoft, permite definir metadatos que impiden que se asocien atributos no válidos con una clase de entidad específica, mediante la creación de un modelo de metadatos.

Google permite operar con los datos mediante un subconjunto de SQL; Microsoft ofrece una sintaxis de consulta basada en URL, abstraída mediante un proveedor LINQ ; Amazon ofrece una sintaxis más limitada. Cabe destacar que, actualmente (abril de 2010), ninguno de los tres motores cuenta con soporte integrado para combinar diferentes entidades mediante uniones. Estas operaciones deben realizarse mediante código de aplicación. Esto podría no ser un problema si los servidores de aplicaciones se encuentran en el mismo centro de datos que los servidores de datos del proveedor, pero se generaría un gran volumen de tráfico de red si estuvieran geográficamente separados.

Un enfoque EAV se justifica únicamente cuando los atributos que se modelan son numerosos y escasos: si los datos que se capturan no cumplen este requisito, el enfoque EAV predeterminado de los proveedores de la nube suele ser inadecuado para aplicaciones que requieren una base de datos back-end real (en lugar de simplemente un medio de almacenamiento persistente de datos). 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 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 completo y accesible en la nube que permite migrar 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.

Véase también

Referencias

  1. ↑ Free Software Foundation (10 de junio de 2007), GNU Emacs Lisp Reference Manual , Boston, MA: Free Software Foundation, págs.  Sección 5.8, "Listas de asociación", archivado del original el 20 de octubre de 2011.
  2. ↑ Fundación Apache, Tutoriales y guías de usuario de UIMA. URL: http://uima.apache.org/downloads/releaseDocs/2.1.0-incubating/docs/html/tutorials_and_users_guides/tutorials_and_users_guides.html . Consultado en octubre de 2012.
  3. ↑ Stead, WW; Hammond, WE; Straube, MJ (1982), "Un registro sin gráficos: ¿es adecuado?", Actas del Simposio Anual sobre Aplicaciones Informáticas en la Atención Médica , 7 (2 de noviembre de 1982): 89–94 , doi : 10.1007/BF00995117 , PMC 2580254 , PMID 6688264  
  4. ↑ McDonald, CJ; Blevins, L.; Tierney, WM; Martin, DK (1988), "Los registros médicos de Regenstrief", MD Computing , 5 (5): 34– 47, PMID 3231034 
  5. ↑ Pryor, T. Allan (1988). "El sistema de registro médico HELP". MD Computing . 5 (5): 22– 33. PMID 3231033 . 
  6. ↑ Warner, HR; Olmsted, CM; Rutherford, BD (1972), "HELP: un programa para la toma de decisiones médicas", Comput Biomed Res , 5 (1): 65–74 , doi : 10.1016/0010-4809(72)90007-9 , PMID 4553324 
  7. ↑ Friedman, Carol; Hripcsak, George; Johnson, Stephen B.; Cimino, James J.; Clayton, Paul D. (1990), "Un esquema relacional generalizado para una base de datos clínica integrada de pacientes", Actas del Simposio Anual sobre Aplicaciones Informáticas en la Atención Médica : 335–339 , PMC 2245527 
  8. 1 2 Nadkarni, Prakash M.; Marenco, Luis; Chen, Roland; Skoufos, Emmanouil; Shepherd, Gordon; Miller, Perry (1999), "Organización de datos científicos heterogéneos mediante la representación EAV/CR", Journal of the American Medical Informatics Association , 6 (6): 478– 493, doi : 10.1136/jamia.1999.0060478 , PMC 61391 , PMID 10579606  
  9. 1 2 Marenco, Luis; Tosches, Nicholas; Crasto, Chiquito; Shepherd, Gordon; Miller, Perry L.; Nadkarni, Prakash M. (2003), "Logrando aplicaciones de biociencias de bases de datos web evolutivas utilizando el marco EAV/CR: avances recientes", Journal of the American Medical Informatics Association , 10 (5): 444– 53, doi : 10.1197/jamia.M1303 , PMC 212781 , PMID 12807806  
  10. ↑ Departamento de Asuntos de Veteranos: Administración de Salud para Veteranos. Archivado el 21 de febrero de 2006 en Wayback Machine.
  11. ↑
    • Nadkarni, Prakash, El modelo EAV/CR de representación de datos , consultado el 1 de febrero de 2015.
  12. ↑ Nadkarni, PM; Marenco, L; Chen, R; Skoufos, E; Shepherd, G; Miller, P (1999), "Organización de datos científicos heterogéneos mediante la representación EAV/CR", Journal of the American Medical Informatics Association , 6 (6): 478– 493, doi : 10.1136/jamia.1999.0060478 , PMC 61391 , PMID 10579606  
  13. ↑ Marenco, L; Tosches, N; Crasto, C; Shepherd, G; Miller, PL; Nadkarni, PM (2003), "Logrando aplicaciones de biociencias con bases de datos web evolutivas utilizando el marco EAV/CR: avances recientes", Journal of the American Medical Informatics Association , 10 (5): 444– 453, doi : 10.1197/jamia.M1303 , PMC 212781 , PMID 12807806  
  14. 1 2 3 Dinu, Valentin; Nadkarni, Prakash; Brandt, Cynthia (2006), "Enfoques pivotantes para la extracción masiva de datos Entidad-Atributo-Valor", Computer Methods and Programs in Biomedicine , 82 (1): 38– 43, doi : 10.1016/j.cmpb.2006.02.001 , PMID 16556470 
  15. ↑ GB 2384875 , Dingley, Andrew Peter, "Almacenamiento y gestión de datos semiestructurados", publicado el 6 de agosto de 2003, asignado a Hewlett Packard 
  16. ↑ Nadkarni, Prakash M. (9 de junio de 2011). Sistemas de software basados ​​en metadatos en biomedicina: diseño de sistemas que se adaptan al conocimiento cambiante . Springer. ISBN 978-0857295095.
  17. ↑ Nadkarni, Prakash (2011), Sistemas de software basados ​​en metadatos en biomedicina , Springer, ISBN 978-0-85729-509-5
  18. ↑ Dinu, Valentin; Nadkarni, Prakash (2007), "Directrices para el uso efectivo del modelado entidad-atributo-valor para bases de datos biomédicas", International Journal of Medical Informatics , 76 ( 11–12 ): 769–79 , doi : 10.1016/j.ijmedinf.2006.09.023 , PMC 2110957 , PMID 17098467  
  19. ↑ Kyte, Thomas. Effective Oracle by Design. Oracle Press, McGraw-Hill Osborne Media. 21 de agosto de 2003. http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:10678084117056
  20. ↑ "Ensayo clínico de Oracle Health Sciences - Oracle" . www.oracle.com .
  21. ↑ " Oracle Clinical - Descripción general - Oracle" . www.oracle.com
  22. ↑ "Relacionalmente divididos por EAV" .
  23. ↑ David Maier, Jeffrey Ullman, Moshe Vardi. Sobre los fundamentos del modelo de relación universal. ACM Transactions on Database Systems (TODS). Volumen 9, número 2, junio de 1984. Páginas 283-308. URL: http://dl.acm.org/citation.cfm?id=318580
  24. ↑ Sobre el diseño universal de bases de datos. En "Introducción a los sistemas de bases de datos", 8.ª ed., Pearson/Addison Wesley, 2003.
  25. ↑ Murphy, SN; Weber, G; Mendis, M; Gainer, V; Chueh, HC; Churchill, S; Kohane, I (2010), "Servir a la empresa y más allá con la informática para integrar la biología y la atención al paciente (i2b2)", Journal of the American Medical Informatics Association , 17 (2): 124– 130, doi : 10.1136/jamia.2009.000893 , PMC 3000779 , PMID 20190053  
  26. 1 2 Itzik Ben-Gan, Dejan Sarka, Inside Microsoft SQL Server 2008: T-SQL Programming (Microsoft Press)
  27. 1 2 Jeroen Coussement, " Reemplazando EAV con JSONB en PostgreSQL " (2016)
  28. ↑ Postgres 9.6, " Tipos JSON "
  29. ↑ TinkerPop, Apache. "Apache TinkerPop" . tinkerpop.apache.org .
  30. ↑ "Coincidencia de patrones - OpenCog" . wiki.opencog.org .
  31. ↑ " JsQuery – lenguaje de consulta JSON con soporte para indexación GIN " (2014)
  32. ↑ " Proyecto 7cart: una alternativa futura a Shopify y Magento " (2019)
  33. ↑ BYHAM (28 de febrero de 2023). "Utilice columnas dispersas" . msdn.microsoft.com .
  34. ↑ Jennings, Roger (2009), "Retire su centro de datos", Visual Studio Magazine , febrero de 2009 : 14–25
  35. ↑ "Límites de recursos - Azure SQL Managed Instance" . 20 de junio de 2023.
Lecturas relacionadas
6 articulos
Modelo de datosModelo de datosUn modelo de datos es un modelo abstracto que organiza elementos de datos y estandariza cómo se relacionan entre sí y con las propiedades de las en...{\displaystyle \left({\begin{smallmatrix}11&22&0&0&0&0&0\\0&33&44&0&0&0&0\\0&0&55&66&77&0&0\\0&0&0&0&0&88&0\\0&0&0&0&0&0&99\\\end{smallmatrix}}\right)}Sparse matrixIn numerical analysis and scientific computing, a sparse matrix or sparse array is a matrix in which most of the elements are zero.[1] There is no ...Clave externaClave externaUna clave externa es un conjunto de atributos en una tabla que hace referencia a la clave principal de otra tabla, vinculando estas dos tablas. En ...Tipo de datosLa jerarquía de tipos estándar de Python 3 En informática y programación informática , un tipo de datos (o simplemente tipo ) es una colección o ag...Nulo (SQL)Nulo (SQL)En SQL , null o NULL es un marcador especial que se utiliza para indicar que un valor de datos no existe en la base de datos . Introducido por el c...SoporteSoporteUn corchete es uno de dos signos de puntuación altos, orientados hacia adelante o hacia atrás, que se usan comúnmente para aislar un segmento de te...