Un modelo entidad-atributo-valor ( EAV ) es un modelo de datos optimizado para el almacenamiento eficiente del espacio de valores de datos o propiedades dispersos (o ad-hoc) , destinado a situaciones en las que los patrones de uso del tiempo de ejecución son arbitrarios, están sujetos a la variación del usuario o de lo contrario sería imprevisible si se utilizara un diseño fijo. El caso de uso se dirige 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 sólo se instancia (o persiste) una selección pequeña y específica de estas para un determinado entidad. Por tanto, este tipo de modelo de datos se relaciona con la noción matemática de 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 que ahorran espacio para almacenar una matriz dispersa , 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 a menudo se describen como "largas y delgadas": "largas" se refiere al número de filas, "delgadas" a las pocas columnas.
Los datos se registran en tres columnas:
Consideremos cómo se intentaría representar una historia clínica de propósito general en una base de datos relacional. Claramente, crear una tabla (o un conjunto de tablas) con miles de columnas no es factible, porque la gran mayoría de las columnas serían nulas . Para complicar las cosas, en una historia clínica 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 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 una revisión constante 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 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 valores de clave externa codificados para facilitar la comprensión. En este ejemplo, todos los valores son valores literales, pero también podrían ser listas de valores predefinidos. Estos últimos son particularmente útiles cuando se sabe que los valores posibles son limitados (es decir, enumerables ).
El siguiente ejemplo ilustra los hallazgos de los síntomas que podrían observarse en un paciente con neumonía .
Los datos de EAV descritos anteriormente son comparables al contenido de un recibo de compra de un supermercado (que se reflejaría en una tabla de artículos de línea de ventas 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 compra es una representación compacta de datos inherentemente escasos.
El modelado de filas , [ se necesita aclaración ] donde los hechos sobre algo (en este caso, una transacción de venta) se registran como varias filas en lugar de varias columnas , es una técnica de modelado de datos estándar. Las diferencias entre el modelado de filas y 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 normalmente se modela 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 necesitaría ir más allá del modelado de filas estándar a EAV se enumeran a continuación:
Ciertas clases ("híbridas") tienen algunos atributos que no son escasos (presentes en todos o en la mayoría de los casos), mientras que otros atributos son muy variables y escasos. Estos últimos son adecuados para el modelado EAV. Por ejemplo, las descripciones de productos realizadas por un conglomerado 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 imágenes médicas, pero ambos tienen atributos comunes, como el embalaje. Costo unitario y por artículo.
En los datos clínicos, la entidad suele ser un evento clínico, como se describió anteriormente. En entornos de propósito más general, 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 el categoría/clase de entidad a la que pertenece. A cada registro (objeto) de esta tabla se le asigna un ID de objeto generado por máquina.
El enfoque de la "tabla de objetos" fue iniciado por Tom Slezak y sus colegas de 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 cada objeto.
El principal beneficio de una tabla de objetos central es que, al tener una tabla de soporte de sinónimos de objetos 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 buscarlo. Primero especifique la categoría a la que pertenece. (Esto es importante en los sistemas de biociencia, donde una palabra clave como "acetilcolina" podría referirse a la molécula misma, que es un neurotransmisor, o al receptor biológico al que se une).
En la propia 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 éstas se analizan en breve.
Convertir 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 constantes de tipos de datos si se quiere hacer algo con los valores, y un índice sobre el valor. La columna de una tabla EAV es esencialmente inútil. Además, no es conveniente almacenar datos binarios grandes, como imágenes, en formato codificado en Base64 en la misma tabla que números enteros o cadenas pequeños. Por lo tanto, los sistemas más grandes utilizan tablas EAV separadas para cada tipo de datos (incluidos los objetos binarios grandes , "BLOBS"), y los metadatos de un atributo determinado identifican la tabla EAV en la que se almacenarán sus datos. En realidad, este enfoque es 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 medio de representación del conocimiento de propósito general , se originó con el concepto de " listas de asociación " ( pares atributo-valor ). Comúnmente utilizados hoy en día, se introdujeron por primera vez en el lenguaje LISP . [1] Los pares atributo-valor se usan ampliamente para diversas aplicaciones, como archivos de configuración (usando una sintaxis simple como atributo = valor ). Un ejemplo de uso de EAV fuera de bases de datos se encuentra 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 el reconocimiento de entidad nombrada (NER) en un documento, anotando el segmento de texto "Presidente Bush" con la anotación– atributo-valor triple (Persona, Nombre_completo, "George W. Bush") . [2] Estas anotaciones pueden almacenarse en una tabla de base de datos.
Si bien EAV no tiene una conexión directa con pares AV, Stead y Hammond parecen ser los primeros en concebir 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 repositorio de datos clínicos HELP (CDR). creado por el grupo de Homer Warner en LDS Hospital, Salt Lake City, Utah. [5] [6] (El sistema Regenstrief en realidad utilizó un diseño Paciente-Atributo-Marca de tiempo-Valor: el uso de la marca de tiempo apoyó 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 mucho más tarde HELP fue 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 ajenos a las ciencias de la computación y, en consecuencia, retrasar la aceptación del modelo en los círculos de proveedores de software y TI. El valor del posterior No se puede subestimar la 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 ilustran su poder).
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]
INSERTAR
Nueva contribución - Ha salido a la luz el artículo [7a] que fue recibido en junio de 1996 y aceptado para su publicación en la revista “Computers and Biomedical Research” (Academic Press) en 1997. Ilustra los resultados del trabajo independiente original realizado en el Centro CRISATO ( C entro di R icerca I nterdipartimentale per lo S tudio delle A ffezioni T umorali dell' O cchio), Departamento de Oftalmología, Universidad de Siena UniSi-IT (n.º de artículo CO971447) de Francesco Di Pisa , en ese momento contrato Profesor de Bases de Datos en la Facultad de Ingeniería de la Universidad de Siena UniSi-IT .
[7a] Di Pisa, F.; Mastrangelo, D; Hadjistilianou, T.; Squitieri, N.; Rinaldo, F.; Donoso, L. y Frezzotti, R. (1997) "Diseño e implementación de una base de datos relacional utilizada en el tratamiento de pacientes con retinoblastoma", Computers and Biomedical Research , 30 (30): 273-289, Academic Press.
Los aspectos relevantes del modelo OAV ( objeto , atributo , valor ) (alias modelo EAV) introducido para gestionar el sistema en el documento antes mencionado son:
1._La aplicabilidad general a muchas situaciones, también a preocupaciones médicas, no se limita al conocimiento clínico de la enfermedad del retinoblastoma únicamente como se presenta en el artículo antes mencionado.
2._Propone las transformaciones reversibles del Modelo Semántico Binario utilizando Cajas vía relaciones algebraicas (es decir, Lenguajes Lógicos, Hechos y Teorías clínicas) en tuplas RDBSM y finalmente en Archivos de Sistema , y hacia atrás (Fig.1). en el papel).
3._Proporciona el diseño de la base de datos clínica (relacional) y la implementación de casos de la rara enfermedad del retinoblastoma en oncología ocular (Fig. 2 y 3) utilizando el modelo semántico binario y la estructura jerárquica de cajas , desde el conocimiento hasta las tuplas y hacia atrás, su interacción dentro del Modelo Semántico de Datos Clínicos (SMCD), el RDBMS y la implementación física de archivos, bajo sistema operativo Unix. En particular, la relevancia del modelo OAV de la teoría Net-Box se describe en todo el contenido del artículo, siendo de facto el inicio de la formalización semántica basada en reglas.
4._Define el uso de la Terminología del Modelo de Datos Clínicos (CDMT) mediante la identificación de categorías clínicas relevantes y términos mediante la configuración de la Metodología del Panel Interno de Expertos (EIPM) y la estandarización del Diccionario de Términos Clínicos (DCT) .
5._Define el Conocimiento de Términos Clínicos (CTK) utilizando (el lenguaje de) las relaciones y la estructura jerárquica identificada por el
Objeto.Atributo.Valor ,
formalismo, es decir, el OAV_Modelo de datos.
6._Propone la estandarización del Clinical Common Data Language (CCDL) permitiendo, entre otras cosas, también la gestión de sinónimos (Fig.7, Fig.13 en el artículo).
7._Se introduce el concepto de Cajas y su empleo jerárquico en el OAV_Model . De hecho, como muestra el estudio de caso de la Fig. 13, la instancia de consulta SQL estándar encuentra todas las posibles relaciones existentes (no fácilmente manejables por el tamaño efectivo de los datos visualizables, ver NOTA ). Este hecho confirma el poder del enfoque OAV_Model of Data propuesto y la consiguiente coherencia de las interfaces gráficas de usuario (explicadas en trabajos posteriores) para mostrar el descubrimiento de resultados de consultas , mostrando la capacidad de aprendizaje de los próximos sistemas desde entonces (entre otros, anticipa y facilita el proceso de Verificación y Validación de datos del conocimiento clínico, el llamado Proceso V&V ).
8._Proporciona formularios de entrada de datos bajo Unix utilizando el OAV_Model , los lenguajes lógicos ( Prolog en trabajos posteriores, como lenguaje relacional) y las relaciones semánticas por Hechos y Reglas, Conocimiento de hecho ( ver NOTA ).
Para cualquier otra cosa que no se mencione explícitamente en este documento, nos referimos al artículo original y al trabajo documentado realizado por el Prof. Francesco Di Pisa a partir de 1991 ( ver NOTA ) .
NOTA El progreso del OAV_Model no está respaldado en el artículo, pero fue avanzado de forma independiente desde 1991 por el Prof. Francesco Di Pisa, y es atestiguado por la Escuela de Informática, el Departamento de Oftalmología, la Facultad de Ingeniería, la estructura CRISATO de la Universidad de Siena (UniSi- IT) y la AOUS ( A zienda O spedaliera U niversitaria S enese). El modelo de base de datos semántica, el modelo de datos relacionales y el OAV_Model han allanado el camino para resultados posteriores relevantes en interfaces gráficas estructuradas, representación en archivos planos de información elemental y descubrimiento en MS-Windows (y Unix-Linux), en IA clínica, Programación lógica computacional e interfaces gráficas de usuario cognitivas (CUGI), la medicina de telesalud contemporánea, especialmente en el campo de oftalmología clínica, neuroimagen y oncología ocular en AOUS y UniSi-IT (desde 2016, la serie de conferencias del Día de la oncología ocular (desafortunadamente, las actas de la conferencia no están disponibles). aunque para conocer la disponibilidad de los programas de la conferencia desde entonces, comuníquese con UniSi-IT). De hecho, el documento muestra una visión PRODROMAL de varios desarrollos adicionales como una perspectiva futura, la información dividida por medio del modelo OAV (es decir, los átomos de información o hechos en la programación lógica)) constituye el primer paso para la construcción de conocimiento según reglas, utilizadas posteriormente también en la Lógica Computacional (Kowalski) [36] .
[36] Kowalski R. (2010), Lógica computacional y pensamiento humano: cómo ser artificialmente inteligente, Cambridge University Press.
Brevemente, el artículo muestra el diseño de una base de datos semántica relacionada con la enfermedad de Retinoblastoma. Se propone un sistema de doble función, en otras palabras, el modelo semántico clínico se traduce en un sistema de base de datos relacional estándar (RDBMS) que garantiza la persistencia de los datos y la seguridad del acceso, por un lado, y en el sistema algebraico (lógico) que soporta cajas , es decir, en relaciones. ( Reglas ) que permiten el descubrimiento y aprendizaje clínico mediante el Modelo OAV, por otro. El artículo muestra la estructura jerárquica de las cajas, su interacción dentro del modelo semántico de conocimiento de datos clínicos y la implementación física (archivos) en el RDBMS, para uso en investigación en el tratamiento y avances terapéuticos de la enfermedad del retinoblastoma. La estructura semántica y las ocurrencias de la teoría Net-Box se definen en términos del modelo OAV , es decir, TypeBox, y las entidades ValueBox y DataBox como tablas en el RDBMS, y el modelo binario semántico. El DataBox, es decir, las tuplas en la notación RDBMS, se utiliza en los formularios DataEntry adecuados para la implementación gráfica y la automatización, según los estándares del sistema operativo (es decir, según la API de MS-Windows o las interfaces gráficas X en el sistema operativo UNIX y Linux). Los formularios de entrada de la base de datos explotan el uso potencial (gráfico) ( ver NOTA ) de los hechos , para la verificación y validación del conocimiento clínico, y de hecho no se limitan únicamente a la investigación y la terapia de la enfermedad del retinoblastoma.
El sistema de gestión de datos de estudios clínicos TrialDB de código abierto 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 orientación a objetos en 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 escasos. Cuando estas condiciones no se cumplen, es preferible el modelado relacional estándar (es decir, una columna por atributo); utilizar EAV no significa abandonar el sentido común ni los principios del buen diseño relacional. En los sistemas de registros clínicos, los subesquemas que se ocupan de la facturación y la demografía del paciente 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 (VA) de los Estados Unidos , conocido como Administración de Salud de Veteranos (VHA), [10] es de código abierto y su esquema se puede acceder fácilmente. inspeccionable, aunque utiliza un motor de base de datos MUMPS en lugar de una base de datos relacional).
Como se analiza en breve, una base de datos EAV es esencialmente imposible de mantener sin numerosas tablas de respaldo que contengan metadatos de respaldo . 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 base de datos. Sin embargo, en los 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. a un nivel arbitrario de complejidad. Un coche, por ejemplo, tiene un motor, una transmisión, etc., y el motor tiene componentes como cilindros. (La subestructura permitida para una clase determinada 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 en el sistema (es decir, valores de clave externa en la tabla de objetos). Para obtener toda la información sobre un objeto determinado 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 si los detalles de una clase individual se representan 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 recursividad tiende a ser relativamente modesto para la mayoría de las clases, por lo que las penalizaciones de rendimiento debidas a la recursividad son modestas, especialmente con la indexación de ID de objetos.
EAV/CR (EAV con clases y relaciones) [11] [12] [13] se refiere a un marco que soporta una subestructura compleja. Su nombre es algo inapropiado: si bien fue una consecuencia 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, en función de si los atributos son escasos 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 navegador es que es posible generar un lote de consultas SQL dinámicas que son independientes de la clase del objeto, consultando primero sus metadatos y utilizando la información de los 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 la vez, como en las interfaces de navegación basadas en 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 incluye leyendas de atributos individuales, el orden en que se presentarán y cómo se agruparán.
Un enfoque para EAV/CR es permitir que las columnas contengan estructuras JSON , que así proporcionan 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 unir atributos JSON.
En palabras del Prof. Dr. Daniel Masys (ex 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 estadísticos, lo consideran, es decir, como filas y columnas convencionales para clases individuales. (Debido a que una tabla EAV mezcla conceptualmente manzanas, naranjas, pomelos y chop suey, si desea realizar algún análisis de los datos utilizando un 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 pivotación , es lo suficientemente importante como para discutirlo por separado).
Los metadatos ayudan a realizar el juego de manos que permite a los usuarios interactuar con el sistema en términos de esquema lógico en lugar de 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 . De hecho, los metadatos se pueden utilizar para personalizar el comportamiento del sistema.
Los sistemas EAV sacrifican la simplicidad en la estructura física y lógica de los datos por la complejidad de sus metadatos, que, entre otras cosas, desempeña el papel que desempeñan las restricciones de la base de datos y la integridad referencial en los diseños de bases de datos estándar. Esta compensación generalmente vale la pena, 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 funcionalidades como la generación automática de interfaces. La estructura de los metadatos es lo suficientemente compleja como para comprender 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, con características como restricciones e integridad referencial que se utilizan al máximo.
La exactitud 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 esfuerzos de diseño considerables para crear interfaces de usuario para la edición de metadatos que puedan ser utilizadas por las personas. en el 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 se adoptó en sitios distintos de su institución de origen fue que todos los metadatos se almacenaban en un único archivo con una estructura no intuitiva. Personalización del comportamiento del sistema alterando el contenido (La creación de este archivo, sin causar que el sistema fallara, era una tarea tan delicada que los autores del sistema sólo confiaban en sí mismos para realizarla).
Cuando un sistema EAV se implementa a través de RDF , el lenguaje de esquema RDF puede usarse convenientemente para expresar dichos metadatos. Esta información del esquema luego 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 con respecto a 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 navegación de datos como para la edición interactiva. En un sistema de producción que se entrega a través de la Web, la tarea de validación de los datos EAV se traslada esencialmente del nivel back-end/base de datos (que no tiene poder con respecto a esta tarea) al nivel medio/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 medio a través de un marco genérico es bastante viable, aunque primero se debe dedicar una cantidad significativa de esfuerzo de diseño de software a la construcción del marco. . La disponibilidad de marcos de código abierto que puedan estudiarse y modificarse según las necesidades individuales puede contribuir en gran medida a evitar la reinvención de la rueda. [ cita necesaria ]
(La primera parte de esta sección es un resumen del artículo de referencia de Dinu/Nadkarni en Central, [18] al que se dirige al lector para obtener más detalles).
El modelado EAV, bajo los términos alternativos " modelado de datos genérico " o "esquema abierto", ha sido durante mucho tiempo una herramienta estándar para los modeladores de datos avanzados. Como cualquier técnica avanzada, puede ser de doble filo y debe utilizarse con prudencia.
Además, el empleo de EAV no excluye el empleo de enfoques tradicionales de modelado de bases de datos relacionales dentro del mismo esquema de base de datos. En los EMR que dependen de un RDBMS, como Cerner , que utiliza un enfoque EAV para su subesquema de datos clínicos, la gran mayoría de las tablas en el esquema están modeladas tradicionalmente, 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, el número de tablas de metadatos en el esquema supera al de tablas de datos en aproximadamente diez a uno. Debido a que la exactitud y la coherencia de los metadatos son fundamentales para el funcionamiento correcto de un sistema EAV, el diseñador del sistema quiere aprovechar al máximo todas las características que proporcionan los RDBMS, como la integridad referencial y las restricciones programables, en lugar de tener que reinventar el RDBMS. -rueda del motor. En consecuencia, las numerosas tablas de metadatos que respaldan los diseños de EAV suelen estar en forma relacional de tercera normalidad.
Los sistemas de registros médicos electrónicos (EHR) comerciales utilizan modelos 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 una combinación de la identificación del paciente y la fecha/hora en que se realizó el diagnóstico (o se realizó 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 procesal actual 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 en el rango normal, bajo o alto, la identificación de la persona responsable de realizar la prueba, la fecha/hora en que se realizó la prueba, etc. adelante.) Como se indicó anteriormente, este no es un enfoque EAV completo porque el dominio de atributos para una tabla determinada está restringido, del mismo modo que el dominio de ID de productos en la tabla Sales de un supermercado estaría restringido al dominio de Productos en una tabla. Tabla de productos.
Sin embargo, para capturar datos sobre parámetros que no siempre están definidos en los vocabularios estándar, los EHR también proporcionan un mecanismo EAV "puro", donde usuarios avanzados especialmente designados pueden definir nuevos atributos, su tipo de datos, valores máximos y mínimos permisibles (o conjunto permisible). de valores/códigos), y luego permitir que otros capturen datos basados en estos atributos. En Epic (TM) EHR, 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 para utilizar el modelo EAV es para atributos heterogéneos y muy escasos, como los parámetros clínicos en la historia clínica electrónica (EMR), como se indicó anteriormente. Incluso aquí, sin embargo, es exacto afirmar que el principio de modelado EAV se aplica a un subesquema de la base de datos en lugar de a todo su contenido. (La demografía de los pacientes, por ejemplo, se modela de forma más natural en una estructura relacional tradicional de una columna por atributo).
En consecuencia, los argumentos sobre el diseño EAV versus el diseño "relacional" reflejan una comprensión incompleta del problema: un diseño EAV debe emplearse sólo para ese subesquema de una base de datos donde es necesario modelar atributos dispersos: incluso en este caso, es necesario respaldarlos. por tablas de metadatos de tercera forma normal . Hay relativamente pocos problemas de diseño de bases de datos en los que se encuentran atributos escasos: esta es la razón por la que 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 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. Los datos también son igualmente modestos. Un ejemplo de esta situación son los problemas de capturar atributos variables para diferentes tipos de productos.
Los atributos dispersos también pueden ocurrir en situaciones de comercio electrónico en las que una organización compra o vende un conjunto vasto y muy diverso de productos básicos, siendo muy variables los detalles de las categorías individuales de productos básicos.
Otra aplicación de EAV es el modelado de clases y atributos que, si bien no son escasos, 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 normalmente unas pocas docenas) y el sistema También se requiere que el desarrollador proporcione una interfaz de usuario final basada en Web en un tiempo de respuesta muy corto. "Dinámico" significa que es necesario definir y modificar continuamente nuevas clases y atributos para representar un modelo de datos en evolución. Este escenario puede ocurrir en campos científicos en 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 mucha mano de obra, la programación de interfaces basadas en Web que admitan la navegación o la edición básica con validación basada en tipos y rangos sí lo es. En tal caso, una solución a largo plazo más fácil de mantener es crear un marco donde 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, se creó para abordar esta misma situación. Tenga en cuenta que un modelo de datos EAV no es esencial aquí, pero el diseñador del sistema puede considerarlo una alternativa aceptable a la creación, digamos, sesenta o más tablas que contengan un total de no más de dos mil filas. Aquí, debido a 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 de DBMS pueden almacenar en caché fácilmente los datos de una clase pequeña en la memoria cuando ejecutan una consulta que involucra esa clase o atributo.
En el escenario de atributos dinámicos, vale la pena señalar que el Marco de descripción de recursos (RDF) se está empleando como base del trabajo de ontología relacionado con la Web Semántica. RDF, que pretende ser 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 generalmente también lo hace más difícil de entender y mantener, por lo que uno no se apresura a modificar el código a menos que primero haya determinado que hay una problema de rendimiento, y medidas como la elaboración de perfiles de código han identificado la ubicación exacta del cuello de botella. Una vez que lo haya hecho, modifique solo el código específico que necesita ejecutarse más rápido. Se aplican consideraciones similares al modelado EAV: se aplica solo al subsistema donde se sabe a priori que el modelado relacional tradicional es difícil de manejar (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 la base de datos (y actualmente vicepresidente de Core Technologies 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 suficiente. criterio para emplear EAV. (Sin embargo, hace la afirmación generalizada de que se debe evitar EAV en todas las circunstancias, a pesar de que la propia división de Ciencias de la Salud de Oracle emplea EAV para modelar atributos de 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 de EAV. A menudo es necesario interconvertir de forma transitoria o permanente entre representaciones modeladas en columnas y en filas o EAV de los mismos datos; Esto puede ser propenso a errores si se hace manualmente y consumir mucha CPU. Los marcos genéricos que utilizan metadatos de atributos y agrupaciones de atributos abordan la primera limitación, pero no la última; su uso es más o menos obligatorio en el caso de esquemas mixtos que contienen una combinación de datos relacionales convencionales y EAV, donde el cociente de error puede ser muy significativo.
La operación de conversión se llama pivote . La pivotación no es necesaria sólo para los datos EAV sino también para cualquier forma de datos modelados por filas. (Por ejemplo, las implementaciones del algoritmo Apriori para el 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 probablemente compren, pivotan los datos modelados por filas como primer paso). tienen extensiones SQL patentadas para facilitar la pivotación y paquetes como Microsoft Excel también lo admiten. Las circunstancias en las que es necesario pivotar se consideran a continuación.
Sin embargo, la estructura del modelo de datos EAV es un candidato perfecto para la división relacional; consulte á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, lo demostró en una computadora portátil y puso la solución a disposición general. [22]
Obviamente, no importa qué enfoque adopte, consultar EAV no será tan rápido como consultar datos relacionales modelados por columnas estándar para ciertos tipos de consultas, de la misma manera que el acceso a elementos en matrices dispersas no es tan rápido como aquellos en matrices no. -matrices 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 determinada, mientras que el acceso a elementos en matrices representadas como matrices 2D se puede realizar mediante operaciones rápidas de registro de la CPU). , eligió correctamente el enfoque EAV para el problema que intentaba resolver, este es el precio que paga; En este sentido, el modelado EAV es un ejemplo de compensación entre espacio (y mantenimiento de esquema) y tiempo de CPU.
Originalmente postulado por Maier, Ullman y Vardi, [23] el "Modelo de Datos Universal" (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. ". Para ello, utiliza relaciones entre tablas, de modo que el usuario no necesita preocuparse por qué tabla contiene qué atributo. CJ Date, sin embargo, [24] señaló que en circunstancias en las que una tabla está relacionada varias veces con otra (como en las 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 direcciones de envío), no hay metadatos suficientes dentro del esquema de la base de datos para especificar uniones inequívocas. Cuando se comercializa 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 "Universo" elimina la ambigüedad de las uniones ambiguas al incluir las múltiples relacionadas tabla en una vista varias veces usando diferentes alias.
Aparte de la forma en que los datos se modelan explícitamente (UDM simplemente usa 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 orientados a consultas (solo lectura). ) sistemas 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 mercado 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 interesan. Por ejemplo, la frase " litio " puede consulte el medicamento (que se usa para tratar el trastorno bipolar ) o un análisis de laboratorio para determinar el nivel de litio en la sangre del paciente. (El nivel de litio en sangre debe controlarse cuidadosamente: demasiado medicamento causa efectos secundarios graves, mientras que muy poco es ineficaz).
Una implementación de Open Schema puede utilizar una columna XML en una tabla para capturar la información variable/escasa. [26] Se pueden aplicar ideas similares a bases de datos que admiten columnas con valores JSON : los datos jerárquicos escasos se pueden representar como JSON. Si la base de datos tiene soporte 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 con respecto a implementaciones ingenuas de EAV, [27] pero no necesariamente hace que la aplicación de base de datos general sea más sólida.
Tenga en cuenta que hay dos formas de almacenar datos XML o JSON: una forma es almacenarlos como una cadena simple, opaca para el servidor de la base de datos; la otra forma es utilizar un servidor de base de datos que pueda "ver dentro" de la estructura. Obviamente, existen algunos inconvenientes graves al almacenar cadenas opacas: no se pueden consultar directamente, no se puede formar un índice basado en su contenido y es imposible realizar uniones basadas en el contenido.
Crear una aplicación que tenga que gestionar datos se vuelve extremadamente complicado cuando se utilizan modelos EAV, debido a la extensión de la infraestructura que debe desarrollarse en términos de tablas de metadatos y código de marco de 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 medio y basado en navegador en marcos basados en EAV), pero tiene los siguientes inconvenientes:
Todos los inconvenientes anteriores se pueden solucionar creando una capa de metadatos y código de aplicación, pero al crear esto, la "ventaja" original de no tener que crear un marco ha desaparecido. El hecho es que modelar de manera robusta atributos de datos dispersos es un problema difícil de diseño de aplicaciones de bases de datos, sin importar qué enfoque de almacenamiento se utilice. Sin embargo, el trabajo de Sarka [26] demuestra la viabilidad de utilizar un campo XML en lugar de tablas EAV relacionales de tipo específico para la capa de almacenamiento de datos, y en situaciones donde el número de atributos por entidad es modesto (por ejemplo, atributos variables de producto para diferentes tipos de productos), la solución basada en XML es más compacta que una basada en tablas EAV. (El propio XML puede considerarse como un medio de representación de datos de atributos y valores, aunque se basa en texto estructurado en lugar de tablas relacionales).
Existen varios otros enfoques para la representación de datos estructurados en árbol, ya sea XML , JSON u otros formatos, como el modelo de conjunto anidado , en una base de datos relacional. Por otro lado, los proveedores de bases de datos han comenzado a incluir soporte 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 declaraciones 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 el uso de un modelo EAV, aunque pueden superponerse. XML es preferible a EAV para datos arbitrariamente jerárquicos cuyo volumen es relativamente modesto para una sola entidad: no está pensado para escalar al nivel de varios gigabytes con respecto al rendimiento de manipulación de datos. [ cita necesaria ] 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 un mecanismo de almacenamiento primario. EAV, como se indicó anteriormente, es específicamente (y sólo) aplicable al escenario de atributos dispersos. Cuando tal escenario se cumple, el uso de tablas de valores-atributos específicos del tipo de datos que pueden indexarse por entidad, por atributo y por valor y manipularse a través de declaraciones SQL simples es mucho más escalable que el uso de una estructura de árbol XML. [ cita necesaria ] Google App Engine, mencionado anteriormente, [ cita necesaria ] utiliza tablas de valores fuertemente tipados por una buena razón. [ cita necesaria ]
Un enfoque alternativo para gestionar los diversos problemas encontrados con los datos estructurados EAV es emplear una base de datos de gráficos . Estos representan entidades como los nodos de un gráfico o hipergráfico y atributos como enlaces o bordes de ese gráfico. El problema de las uniones de tablas se aborda proporcionando lenguajes de consulta específicos de gráficos, como Apache TinkerPop, [29] o el comparador de patrones de espacio atómico OpenCog . [30]
Otra alternativa es utilizar la tienda SPARQL .
PostgreSQL versión 9.4 incluye soporte para columnas binarias JSON (JSONB), que se pueden consultar, indexar y unir. Esto permite mejoras de rendimiento por factores de mil o más con respecto a los diseños de mesa 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. Eso 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 de fecha y hora) 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) y son útiles cuando la mayoría de los registros de una tabla tendrán valores NULL para esa columna. Los índices en columnas escasas 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 un conjunto de columnas se define para una tabla como parte de una instrucción CREATE TABLE, normalmente se le agregan todas las columnas dispersas definidas posteriormente. Esto tiene la interesante consecuencia de que la instrucción SQL SELECT * from <tablename>no devolverá las columnas dispersas individuales, sino que las concatenará todas en una sola 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 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 tomar prestada 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 se puede asociar una cantidad arbitraria de atributos con una entidad determinada. Roger Jennings ofrece una comparación en profundidad [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 en cadenas (por ejemplo, los números deben rellenarse con ceros a la izquierda) si desea realizar operaciones como la clasificació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 [1]. Google App Engine [2] ofrece la mayor variedad de tipos de datos: además de dividir 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, código geográfico e hipervínculo. Google, pero no Amazon ni Microsoft, le permite definir metadatos que evitarían que se asocien atributos no válidos con una clase particular de entidad, al permitirle crear un modelo de metadatos.
Google le permite operar con los datos utilizando un subconjunto de SQL; Microsoft ofrece una sintaxis de consulta basada en URL que se extrae mediante un proveedor LINQ ; Amazon ofrece una sintaxis más limitada. Lo preocupante es que actualmente (abril de 2010) el soporte integrado para combinar diferentes entidades mediante uniones no existe en los tres motores. Estas operaciones deben realizarse mediante el código de la aplicación. Esto puede no ser una preocupación 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 una gran cantidad de tráfico de red si los dos estuvieran separados geográficamente.
Un enfoque EAV se justifica sólo cuando los atributos que se están modelando son numerosos y escasos: si los datos que se capturan no cumplen con este requisito, el enfoque EAV predeterminado de los proveedores de la nube a menudo no coincide con las aplicaciones que requieren una verdadera base de datos de back-end. (a diferencia 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 tradicional de modelado de datos, 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 ese 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 portar 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.
[7a] Di Pisa, F.; Mastrangelo, D; Hadjistilianou, T.; Squitieri, N.; Rinaldo, F.; Donoso, L. y Frezzotti, R. (1997) "Diseño e implementación de una base de datos relacional utilizada en el tratamiento de pacientes con retinoblastoma", Computers and Biomedical Research , 30 (30): 273-289, Academic Press.
[36] Kowalski R. (2010), Lógica computacional y pensamiento humano: cómo ser artificialmente inteligente, Cambridge University Press.