Base de datos de gráficos

Base de datos que utiliza gráficos matemáticos para almacenar y buscar datos.

Una base de datos de gráficos ( GDB ) es una base de datos que utiliza estructuras de gráficos para consultas semánticas con nodos , aristas y propiedades para representar y almacenar datos. ^[1] Un concepto clave del sistema es el gráfico (o arista o relación). El gráfico relaciona los elementos de datos del almacén con una colección de nodos y aristas, representando las aristas las relaciones entre los nodos. Las relaciones permiten que los datos del almacén se vinculen directamente y, en muchos casos, se recuperen con una sola operación. Las bases de datos de gráficos tienen como prioridad las relaciones entre los datos. Consultar relaciones es rápido porque se almacenan perpetuamente en la base de datos. Las relaciones se pueden visualizar intuitivamente utilizando bases de datos de gráficos, lo que las hace útiles para datos muy interconectados. ^[2]

Las bases de datos de gráficos se denominan comúnmente bases de datos NoSQL . Las bases de datos de gráficos son similares a las bases de datos de modelos de red de la década de 1970 en que ambas representan gráficos generales, pero las bases de datos de modelos de red operan en un nivel más bajo de abstracción ^{[3] y carecen de} un recorrido fácil a través de una cadena de bordes. ^[4]

El mecanismo de almacenamiento subyacente de las bases de datos de gráficos puede variar. Las relaciones son ciudadanos de primera clase en una base de datos gráfica y se pueden etiquetar, dirigir y otorgar propiedades. Algunos dependen de un motor relacional y almacenan los datos del gráfico en una tabla (aunque una tabla es un elemento lógico, por lo tanto, este enfoque impone un nivel de abstracción entre el sistema de gestión de la base de datos de gráficos y los dispositivos de almacenamiento físico). Otros utilizan un almacén de valores clave o una base de datos orientada a documentos para el almacenamiento, lo que los convierte en estructuras inherentemente NoSQL.

A partir de 2021 ^[actualizar], ningún lenguaje de consulta de gráficos se ha adoptado universalmente de la misma manera que SQL para las bases de datos relacionales, y existe una amplia variedad de sistemas, muchos de los cuales están estrechamente vinculados a un producto. Algunos de los primeros esfuerzos de estandarización conducen a lenguajes de consulta de múltiples proveedores como Gremlin , SPARQL y Cypher . En septiembre de 2019, los miembros del Comité Técnico Conjunto 1 de ISO/IEC (ISO/IEC JTC 1) aprobaron una propuesta de proyecto para crear un nuevo lenguaje de consulta de gráficos estándar (ISO/IEC 39075 Tecnología de la información - Lenguajes de bases de datos - GQL). GQL pretende ser un lenguaje de consulta de base de datos declarativo, como SQL. Además de tener interfaces de lenguaje de consulta, se accede a algunas bases de datos de gráficos a través de interfaces de programación de aplicaciones (API).

Las bases de datos de gráficos se diferencian de los motores de cálculo de gráficos. Las bases de datos de gráficos son tecnologías que son traducciones de las bases de datos de procesamiento de transacciones en línea relacionales (OLTP). Por otro lado, los motores de cálculo de gráficos se utilizan en el procesamiento analítico en línea (OLAP) para análisis masivos. ^[5] Las bases de datos de gráficos atrajeron una atención considerable en la década de 2000, debido a los éxitos de las principales corporaciones tecnológicas en el uso de bases de datos de gráficos patentadas, ^[6] junto con la introducción de bases de datos de gráficos de código abierto .

Un estudio concluyó que un RDBMS era "comparable" en rendimiento a los motores de análisis de gráficos existentes al ejecutar consultas de gráficos. ^[7]

Historia

A mediados de la década de 1960, las bases de datos de navegación como el IMS de IBM admitían estructuras en forma de árbol en su modelo jerárquico , pero la estricta estructura de árbol podía evitarse con registros virtuales. ^{[8] [9]}

Las estructuras de gráficos se podían representar en bases de datos de modelos de red de finales de la década de 1960. CODASYL , que había definido COBOL en 1959, definió el lenguaje de base de datos de red en 1969.

Los gráficos etiquetados se podían representar en bases de datos de gráficos de mediados de la década de 1980, como el Modelo de datos lógicos. ^{[10] [11]}

Las bases de datos de objetos comerciales (ODBMS) surgieron a principios de los años 1990. En 2000, el Object Data Management Group publicó un lenguaje estándar para definir estructuras de objetos y relaciones (gráficos) en su publicación ODMG'93.

A principios de la década de 1990 aparecieron varias mejoras en las bases de datos gráficas, que se aceleraron a finales de la década de 1990 con intentos de indexar páginas web.

A mediados y finales de la década de 2000, estuvieron disponibles bases de datos de gráficos comerciales con garantías ACID , como Neo4j y Oracle Spatial and Graph .

En la década de 2010, estuvieron disponibles bases de datos comerciales de gráficos ACID que podían ampliarse horizontalmente . Además, SAP HANA incorporó tecnologías en memoria y en columnas para graficar bases de datos. ^[12] También en la década de 2010, estuvieron disponibles bases de datos multimodelo que admitían modelos gráficos (y otros modelos como bases de datos relacionales o bases de datos orientadas a documentos ), como OrientDB , ArangoDB y MarkLogic (a partir de su versión 7.0). Durante este tiempo, las bases de datos gráficas de varios tipos se han vuelto especialmente populares en el análisis de redes sociales con la llegada de las empresas de redes sociales. También durante la década, estuvieron disponibles bases de datos de gráficos basadas en la nube , como Amazon Neptune y Neo4j AuraDB .

Fondo

Las bases de datos de gráficos representan los datos tal como se ven conceptualmente. Esto se logra transfiriendo los datos a nodos y sus relaciones a bordes.

Una base de datos de grafos es una base de datos que se basa en la teoría de grafos . Consta de un conjunto de objetos, que puede ser un nodo o una arista.

• Los nodos representan entidades o instancias como personas, empresas, cuentas o cualquier otro elemento al que se debe realizar un seguimiento. Son aproximadamente el equivalente de un registro, relación o fila en una base de datos relacional, o un documento en una base de datos de almacén de documentos.
• Las aristas , también denominadas gráficos o relaciones , son las líneas que conectan nodos con otros nodos; representando la relación entre ellos. Surgen patrones significativos al examinar las conexiones e interconexiones de nodos, propiedades y bordes. Los bordes pueden ser dirigidos o no dirigidos. En un gráfico no dirigido, un borde que conecta dos nodos tiene un significado único. En un gráfico dirigido, los bordes que conectan dos nodos diferentes tienen significados diferentes, dependiendo de su dirección. Los bordes son el concepto clave en las bases de datos de gráficos y representan una abstracción que no se implementa directamente en un modelo relacional o un modelo de almacén de documentos .
• Las propiedades son información asociada a los nodos. Por ejemplo, si Wikipedia fuera uno de los nodos, podría estar vinculado a propiedades como sitio web , material de referencia o palabras que comiencen con la letra w , dependiendo de qué aspectos de Wikipedia sean pertinentes para una base de datos determinada.

Modelos gráficos

Gráfico de propiedades etiquetadas

Un ejemplo de un gráfico de propiedades etiquetadas

Un modelo de gráfico de propiedades etiquetadas está representado por un conjunto de nodos, relaciones, propiedades y etiquetas. Ambos nodos de datos y sus relaciones tienen nombre y pueden almacenar propiedades representadas por pares clave-valor . Los nodos se pueden etiquetar para agruparlos. Las aristas que representan las relaciones tienen dos cualidades: siempre tienen un nodo inicial y un nodo final, y están dirigidas; ^[13] haciendo del gráfico un gráfico dirigido . Las relaciones también pueden tener propiedades. Esto es útil para proporcionar metadatos y semántica adicionales a las relaciones de los nodos. ^[14] El almacenamiento directo de relaciones permite un recorrido en tiempo constante . ^[15]

Marco de descripción de recursos (RDF)

Un ejemplo de gráfico RDF

En un modelo de gráfico RDF , cada adición de información se representa con un nodo separado. Por ejemplo, imagine un escenario en el que un usuario tiene que agregar una propiedad de nombre para una persona representada como un nodo distinto en el gráfico. En un modelo de gráfico de propiedades etiquetadas, esto se haría agregando una propiedad de nombre al nodo de la persona. Sin embargo, en un RDF, el usuario debe agregar un nodo separado llamado hasNameconectarlo al nodo persona original. Específicamente, un modelo de gráfico RDF se compone de nodos y arcos. Una notación gráfica RDF o una declaración está representada por: un nodo para el sujeto, un nodo para el objeto y un arco para el predicado. Un nodo puede dejarse en blanco, ser literal y/o identificarse mediante un URI . Un arco también puede identificarse mediante un URI. Un literal para un nodo puede ser de dos tipos: simple (sin tipo) y con tipo. Un literal simple tiene una forma léxica y, opcionalmente, una etiqueta de idioma. Un literal escrito se compone de una cadena con un URI que identifica un tipo de datos particular. Se puede utilizar un nodo en blanco para ilustrar con precisión el estado de los datos cuando los datos no tienen un URI . ^[dieciséis]

Propiedades

Las bases de datos de gráficos son una herramienta poderosa para consultas similares a gráficos. Por ejemplo, calcular el camino más corto entre dos nodos en el gráfico. Se pueden realizar otras consultas similares a gráficos en una base de datos de gráficos de forma natural (por ejemplo, cálculos de diámetro de gráficos o detección de comunidades).

Los gráficos son flexibles, lo que significa que permiten al usuario insertar nuevos datos en el gráfico existente sin perder la funcionalidad de la aplicación. No es necesario que el diseñador de la base de datos planifique detalles extensos de los casos de uso futuros de la base de datos.

Almacenamiento

El mecanismo de almacenamiento subyacente de las bases de datos de gráficos puede variar. Algunos dependen de un motor relacional y "almacenan" los datos del gráfico en una tabla (aunque una tabla es un elemento lógico, por lo tanto, este enfoque impone otro nivel de abstracción entre la base de datos del gráfico, el sistema de gestión de la base de datos del gráfico y los dispositivos físicos donde se almacenan los datos). está realmente almacenado). Otros utilizan un almacén de valores clave o una base de datos orientada a documentos para el almacenamiento, lo que los convierte en estructuras inherentemente NoSQL . Un nodo se representaría como cualquier otro almacén de documentos, pero los bordes que unen dos nodos diferentes contienen atributos especiales dentro de su documento; un atributo _from y _to.

Adyacencia sin índice

El rendimiento de la búsqueda de datos depende de la velocidad de acceso de un nodo particular a otro. Debido a que la adyacencia sin índice obliga a los nodos a tener direcciones RAM físicas directas y apuntar físicamente a otros nodos adyacentes, esto resulta en una recuperación rápida. Un sistema de gráficos nativo con adyacencia sin índice no tiene que moverse a través de ningún otro tipo de estructuras de datos para encontrar enlaces entre los nodos. Los nodos directamente relacionados en un gráfico se almacenan en la caché una vez que se recupera uno de los nodos, lo que hace que la búsqueda de datos sea incluso más rápida que la primera vez que un usuario busca un nodo. Sin embargo, esta ventaja tiene un costo. La adyacencia sin índice sacrifica la eficiencia de las consultas que no utilizan recorridos de gráficos . Las bases de datos de gráficos nativos utilizan adyacencia sin índice para procesar operaciones CRUD en los datos almacenados.

Aplicaciones

Se han reconocido múltiples categorías de gráficos por tipo de datos. Gartner sugiere cinco categorías amplias de gráficos: ^[17]

• Gráfico social : se trata de las conexiones entre personas; Los ejemplos incluyen Facebook , Twitter y la idea de seis grados de separación.
• Gráfico de intención: trata del razonamiento y la motivación.
• Gráfico de consumo: también conocido como "gráfico de pagos", el gráfico de consumo se utiliza mucho en la industria minorista. Empresas de comercio electrónico como Amazon, eBay y Walmart utilizan gráficos de consumo para realizar un seguimiento del consumo de clientes individuales.
• Gráfico de intereses : mapea los intereses de una persona y, a menudo, se complementa con un gráfico social. Tiene el potencial de seguir la revolución anterior de la organización web al mapear la web por intereses en lugar de indexar páginas web.
• Gráfico móvil: se construye a partir de datos móviles. Los datos móviles en el futuro pueden incluir datos de la web, aplicaciones, billeteras digitales, GPS y dispositivos de Internet de las cosas (IoT).

Comparación con bases de datos relacionales

Desde el artículo de Edgar F. Codd de 1970 sobre el modelo relacional , ^[18] las bases de datos relacionales han sido el estándar industrial de facto para los sistemas de almacenamiento de datos a gran escala. Los modelos relacionales requieren un esquema estricto y una normalización de datos que separe los datos en muchas tablas y elimine cualquier dato duplicado dentro de la base de datos. Los datos se normalizan para preservar la coherencia de los datos y admitir transacciones ACID . Sin embargo, esto impone limitaciones sobre cómo se pueden consultar las relaciones.

Una de las motivaciones del diseño del modelo relacional fue lograr un acceso rápido fila por fila. ^[18] Los problemas surgen cuando es necesario formar relaciones complejas entre los datos almacenados. Aunque las relaciones se pueden analizar con el modelo relacional, se requieren consultas complejas que realicen muchas operaciones de unión en muchos atributos diferentes en varias tablas. Al trabajar con modelos relacionales, también se deben considerar las restricciones de clave externa al recuperar relaciones, lo que genera una sobrecarga adicional.

En comparación con las bases de datos relacionales , las bases de datos gráficas suelen ser más rápidas para conjuntos de datos asociativos ^{[ cita necesaria ]} y se asignan más directamente a la estructura de las aplicaciones orientadas a objetos . Pueden escalar de forma más natural ^{[ cita necesaria ]} a grandes conjuntos de datos, ya que normalmente no necesitan operaciones de unión , que a menudo pueden resultar costosas. Como dependen menos de un esquema rígido, se comercializan como más adecuados para gestionar datos ad hoc y cambiantes con esquemas en evolución.

Por el contrario, los sistemas de gestión de bases de datos relacionales suelen ser más rápidos a la hora de realizar la misma operación en una gran cantidad de elementos de datos, lo que permite la manipulación de los datos en su estructura natural. A pesar de las ventajas de las bases de datos gráficas y su reciente popularidad sobre ^{[ cita necesaria ]} bases de datos relacionales, se recomienda que el modelo gráfico en sí no sea la única razón para reemplazar una base de datos relacional existente. Una base de datos gráfica puede volverse relevante si hay evidencia de una mejora del rendimiento en órdenes de magnitud y una menor latencia. ^[19]

Ejemplos

El modelo relacional recopila datos utilizando la información de los datos. Por ejemplo, se podrían buscar todos los "usuarios" cuyo número de teléfono contenga el código de área "311". Esto se haría buscando en tablas o almacenes de datos seleccionados , buscando en los campos de números de teléfono seleccionados la cadena "311". Este puede ser un proceso que requiere mucho tiempo en tablas grandes, por lo que las bases de datos relacionales ofrecen índices , que permiten almacenar los datos en una subtabla más pequeña, que contiene solo los datos seleccionados y una clave única (o clave primaria) del registro. Si los números de teléfono están indexados, se produciría la misma búsqueda en la tabla de índice más pequeña, reuniendo las claves de los registros coincidentes y luego buscando en la tabla de datos principal los registros con esas claves. Por lo general, una tabla se almacena de una manera que permite que la búsqueda mediante una clave sea muy rápida. ^[20]

Las bases de datos relacionales no contienen inherentemente la idea de relaciones fijas entre registros. En cambio, los datos relacionados se vinculan entre sí almacenando la clave única de un registro en los datos de otro registro. Por ejemplo, una tabla que contiene direcciones de correo electrónico para usuarios puede contener un elemento de datos llamado userpk, que contiene la clave principal del registro de usuario al que está asociado. Para vincular a los usuarios y sus direcciones de correo electrónico, el sistema primero busca las claves primarias de los registros de usuario seleccionados, busca esas claves en la userpkcolumna de la tabla de correo electrónico (o, más probablemente, en un índice de ellas), extrae los datos del correo electrónico, y luego vincula los registros de usuario y de correo electrónico para crear registros compuestos que contengan todos los datos seleccionados. Esta operación, denominada unión , puede resultar costosa desde el punto de vista computacional. Dependiendo de la complejidad de la consulta, la cantidad de combinaciones y la indexación de varias claves, es posible que el sistema tenga que buscar en varias tablas e índices y luego ordenarlos todos para que coincidan. ^[20]

Por el contrario, las bases de datos de gráficos almacenan directamente las relaciones entre registros. En lugar de encontrar una dirección de correo electrónico buscando la clave de usuario en la userpkcolumna, el registro de usuario contiene un puntero que hace referencia directamente al registro de dirección de correo electrónico. Es decir, una vez seleccionado un usuario, el puntero se puede seguir directamente a los registros de correo electrónico, no es necesario buscar en la tabla de correo electrónico para encontrar los registros coincidentes. Esto puede eliminar las costosas operaciones de unión. Por ejemplo, si uno busca todas las direcciones de correo electrónico de los usuarios en el código de área "311", el motor primero realizará una búsqueda convencional para encontrar los usuarios en "311", pero luego recuperará las direcciones de correo electrónico siguiendo los enlaces que se encuentran en esos registros. Una base de datos relacional primero encontraría a todos los usuarios en "311", extraería una lista de las claves principales, realizaría otra búsqueda de cualquier registro en la tabla de correo electrónico con esas claves principales y vincularía los registros coincidentes. Para este tipo de operaciones comunes, las bases de datos gráficas serían teóricamente más rápidas. ^[20]

El verdadero valor del enfoque gráfico se vuelve evidente cuando se realizan búsquedas que tienen más de un nivel de profundidad. Por ejemplo, considere una búsqueda de usuarios que tengan "suscriptores" (una tabla que vincula a los usuarios con otros usuarios) en el código de área "311". En este caso, una base de datos relacional tiene que buscar primero todos los usuarios con un código de área en "311", luego buscar en la tabla de suscriptores cualquiera de esos usuarios y finalmente buscar en la tabla de usuarios para recuperar los usuarios coincidentes. Por el contrario, una base de datos gráfica buscaría todos los usuarios en "311" y luego seguiría los vínculos de retroceso a través de la relación del suscriptor para encontrar los usuarios suscriptores. Esto evita varias búsquedas y el uso de memoria involucrado en almacenar todos los datos temporales de múltiples registros necesarios para construir la salida. En términos de notación O grande , esta consulta sería tiempo, es decir, proporcional al logaritmo del tamaño de los datos. Por el contrario, la versión relacional incluiría múltiples búsquedas, más el tiempo necesario para unir todos los registros de datos. ^[20] ${\displaystyle O(\log n)+O(1)}$ ${\displaystyle O(\log n)}$ ${\displaystyle O(n)}$

La ventaja relativa de la recuperación de gráficos crece con la complejidad de una consulta. Por ejemplo, uno podría querer saber "esa película sobre submarinos con el actor que estuvo en esa película con ese otro actor que interpretó el papel principal en Lo que el viento se llevó ". Esto primero requiere que el sistema encuentre a los actores de Lo que el viento se llevó , busque todas las películas en las que aparecieron, encuentre todos los actores de todas esas películas que no fueron los protagonistas de Lo que el viento se llevó y luego busque todas las películas. estaban, finalmente filtrando esa lista a aquellos con descripciones que contienen "submarino". En una base de datos relacional, esto requeriría varias búsquedas separadas en las tablas de películas y actores, hacer otra búsqueda en películas de submarinos, encontrar todos los actores de esas películas y luego comparar los (grandes) resultados recopilados. Por el contrario, la base de datos gráfica iría desde Lo que el viento se llevó hasta Clark Gable , reuniría los enlaces a las películas en las que ha estado, reuniría los enlaces de esas películas a otros actores y luego seguiría los enlaces de esos actores de regreso a la lista de películas. En la lista resultante de películas se puede buscar "submarino". Todo esto se puede hacer mediante una sola búsqueda. ^[21]

Las propiedades añaden otra capa de abstracción a esta estructura que también mejora muchas consultas comunes. Las propiedades son esencialmente etiquetas que se pueden aplicar a cualquier registro o, en algunos casos, también a los bordes. Por ejemplo, se podría etiquetar a Clark Gable como "actor", lo que permitiría al sistema encontrar rápidamente todos los registros que sean actores, en lugar de directores u operadores de cámara. Si se permiten etiquetas en los bordes, también se podría etiquetar la relación entre Lo que el viento se llevó y Clark Gable como "principal", y realizando una búsqueda de personas que sean "actores" "principales" en la película Lo que el viento se llevó , el La base de datos produciría a Vivien Leigh , Olivia de Havilland y Clark Gable. La consulta SQL equivalente tendría que depender de datos agregados en la tabla que vincula personas y películas, lo que agregaría más complejidad a la sintaxis de la consulta. Este tipo de etiquetas pueden mejorar el rendimiento de la búsqueda en determinadas circunstancias, pero generalmente son más útiles para proporcionar datos semánticos adicionales para los usuarios finales. ^[21]

Las bases de datos relacionales se adaptan muy bien a diseños de datos planos, donde las relaciones entre datos tienen solo uno o dos niveles de profundidad. Por ejemplo, es posible que una base de datos de contabilidad necesite buscar todas las partidas de todas las facturas de un cliente determinado, una consulta de tres combinaciones. Las bases de datos de gráficos están dirigidas a conjuntos de datos que contienen muchos más enlaces. Son especialmente adecuados para los sistemas de redes sociales , donde la relación de "amigos" es esencialmente ilimitada. Estas propiedades hacen que las bases de datos gráficas sean naturalmente adecuadas para tipos de búsquedas que son cada vez más comunes en sistemas en línea y en entornos de big data . Por esta razón, las bases de datos de gráficos se están volviendo muy populares para grandes sistemas en línea como Facebook , Google , Twitter y sistemas similares con vínculos profundos entre registros.

Para ilustrarlo mejor, imagine un modelo relacional con dos tablas: una peopletabla (que tiene una columna person_idy person_name) y una friendtabla (con friend_idy person_id, que es una clave externa de la peopletabla). En este caso, buscar a todos los amigos de Jack daría como resultado la siguiente consulta SQL.

SELECCIONE p2 . nombre_persona DE personas p1 ÚNETE a amigo EN ( p1 . person_id = amigo . persona_id ) ÚNETE a personas p2 EN ( p2 . persona_id = amigo . amigo_id ) DONDE p1 . nombre_persona = 'Jack' ;                   

La misma consulta puede traducirse a:

• Cypher , un lenguaje de consulta de bases de datos de gráficos.

  PARTICIPAR ( p1 : persona { nombre : 'Jack' }) -[ : AMIGO_CON ]- ( p2 : persona ) VOLVER p2 . nombre    

• SPARQL , un lenguaje de consulta de base de datos de gráficos RDF estandarizado por W3C y utilizado en múltiples tiendas RDF Triple y Quad
  • Forma larga

    PREFIJO  foaf :  <http://xmlns.com/foaf/0.1/>SELECCIONE  ?nombre DONDE  {  ?s  un  foaf : Persona  .  ?s  foaf : nombre  "Jack"  .  ?s  foaf : lo sabe  .  ?o foaf : nombre ?nombre . }     

  • Forma corta

    PREFIJO  foaf :  <http://xmlns.com/foaf/0.1/>SELECCIONE  ?nombre DONDE  {  ?s  foaf : nombre  "Jack"  ;  foaf : ¿ sabe  ?  ?o foaf : nombre ?nombre . }     

• SPASQL, un lenguaje de consulta de base de datos híbrido, que extiende SQL con SPARQL

  SELECCIONA  personas . nombre FROM  (  PREFIJO SPARQL  foaf : <http://xmlns.com/foaf/0.1/> SELECCIONAR ?nombre DONDE { ?s foaf : nombre "Jack" ; foaf : sabe ?o . ​​?o foaf : nombre ?nombre . } ) COMO personas ;                      

Los ejemplos anteriores son una ilustración sencilla de una consulta de relación básica. Condensan la idea de que la complejidad de las consultas de los modelos relacionales aumenta con la cantidad total de datos. En comparación, una consulta de base de datos de gráficos puede ordenar fácilmente el gráfico de relaciones para presentar los resultados.

También hay resultados que indican que las consultas simples, condensadas y declarativas de las bases de datos de gráficos no necesariamente proporcionan un buen rendimiento en comparación con las bases de datos relacionales. Si bien las bases de datos gráficas ofrecen una representación intuitiva de los datos, las bases de datos relacionales ofrecen mejores resultados cuando se necesitan operaciones establecidas. ^[15]

Lista de bases de datos de gráficos

La siguiente es una lista de bases de datos de gráficos notables :

Lenguajes de programación de consultas gráficas

• AQL (ArangoDB Query Language) : un lenguaje de consulta similar a SQL utilizado en ArangoDB tanto para documentos como para gráficos.
• Cypher Query Language (Cypher): un lenguaje declarativo de consulta de gráficos para Neo4j que permite el acceso ad hoc y programático (similar a SQL) al gráfico. ^[45]
• GQL : lenguaje de consulta de gráficos estándar ISO propuesto
• GraphQL : un lenguaje de manipulación y consulta de datos de código abierto para API. Dgraph implementa un lenguaje GraphQL modificado llamado DQL (anteriormente GraphQL+-)
• Gremlin : un lenguaje de programación gráfica que forma parte del proyecto de código abierto Apache TinkerPop ^[46]
• SPARQL : un lenguaje de consulta para bases de datos RDF que puede recuperar y manipular datos almacenados en formato RDF
• consultas de ruta regulares , un lenguaje teórico para consultas en bases de datos de gráficos

Ver también

• Transformación de gráficos
• Modelo de base de datos jerárquico
• Registro de datos
• Vadalog
• Base de datos de objetos
• Base de datos RDF
• Almacenamiento estructurado
• Gráfico de texto
• Wikidata es un proyecto hermano de Wikipedia que almacena datos en una base de datos gráfica. La navegación web normal permite ver nodos, seguir bordes y ejecutar consultas SPARQL .

Referencias

1. Bourbakis, Nikolaos G. (1998). Inteligencia artificial y automatización. Científico mundial. pag. 381.ISBN​ 9789810226374. Consultado el 20 de abril de 2018 .
2. Yoon, Byoung-Ha; Kim, Seon-Kyu; Kim, Seon-Young (marzo de 2017). "Uso de base de datos de gráficos para la integración de datos biológicos heterogéneos". Genómica e informática . 15 (1): 19–27. doi :10.5808/GI.2017.15.1.19. ISSN  1598-866X. PMC 5389944 . PMID  28416946. 
3. Ángulos, Renzo; Gutiérrez, Claudio (1 de febrero de 2008). "Estudio de modelos de bases de datos de gráficos" (PDF) . Encuestas de Computación ACM . 40 (1): 1–39. CiteSeerX 10.1.1.110.1072 . doi :10.1145/1322432.1322433. S2CID  207166126. Archivado desde el original (PDF) el 15 de agosto de 2017 . Consultado el 28 de mayo de 2016 . los modelos de red [...] carecen de un buen nivel de abstracción: es difícil separar el modelo de base de datos de la implementación real 
4. Silberschatz, Avi (28 de enero de 2010). Conceptos de sistemas de bases de datos, sexta edición (PDF) . McGraw-Hill. pag. D-29. ISBN 978-0-07-352332-3.
5. Robinson, Ian (10 de junio de 2015). Bases de datos gráficas: nuevas oportunidades para datos conectados. O'Reilly Media, Inc. pág. 4.ISBN​ 9781491930861.
6. "Las bases de datos de gráficos irrumpen en la corriente principal". www.kdnuggets.com . Consultado el 23 de octubre de 2018 .
7. Fan, Jing; Gerald, Adalberto (25 de diciembre de 2014). El caso contra los motores de análisis de gráficos especializados (PDF) . Conferencia sobre Investigación de Sistemas de Datos Innovadores (CIDR).
8. Silberschatz, Avi (28 de enero de 2010). Conceptos de sistemas de bases de datos, sexta edición (PDF) . McGraw-Hill. pag. E-20. ISBN 978-0-07-352332-3.
9. Parker, Lorena. "Notas del IMS". vcu.edu . Consultado el 31 de mayo de 2016 .
10. Ángulos, Renzo; Gutiérrez, Claudio (1 de febrero de 2008). "Estudio de modelos de bases de datos de gráficos" (PDF) . Encuestas de Computación ACM . 40 (1): 1–39. CiteSeerX 10.1.1.110.1072 . doi :10.1145/1322432.1322433. S2CID  207166126. Archivado desde el original (PDF) el 15 de agosto de 2017 . Consultado el 28 de mayo de 2016 . los modelos de red [...] carecen de un buen nivel de abstracción: es difícil separar el modelo de base de datos de la implementación real 
11. Kuper, Gabriel M. (1985). El modelo lógico de datos: un nuevo enfoque para la lógica de bases de datos (PDF) (Ph.D.). Expediente STAN-CS-85-1069. Archivado (PDF) desde el original el 30 de junio de 2016 . Consultado el 31 de mayo de 2016 .
12. "SAP anuncia nuevas capacidades en la nube con HANA". 2014-10-22 . Consultado el 7 de julio de 2016 .
13. Frisendal, Thomas (22 de septiembre de 2017). "Gráficos de propiedades". Graphdatamodeling.com . Consultado el 23 de octubre de 2018 .
14. Das, S; Srinivasan, J; Perry, Mateo; Chong, Eugenio; Banerjee, Jay (24 de marzo de 2014). "Una historia de dos gráficos: gráficos de propiedades como RDF en Oracle". {{cite journal}}: Citar diario requiere |journal=( ayuda )
15. Tener, Christian Theil; Jensen, Lars Juhl (17 de octubre de 2013). "¿Están las bases de datos de gráficos preparadas para la bioinformática?". Bioinformática . 29 (24): 3107–3108. doi : 10.1093/bioinformática/btt549. ISSN  1460-2059. PMC 3842757 . PMID  24135261. 
16. "Marco de descripción de recursos (RDF): conceptos y sintaxis abstracta". www.w3.org . Consultado el 24 de octubre de 2018 .
17. "La dinámica competitiva de la web del consumidor: cinco gráficos ofrecen una ventaja sostenible". www.gartner.com . Consultado el 23 de octubre de 2018 .
18. Codd, EF (1 de junio de 1970). "Un modelo relacional de datos para grandes bancos de datos compartidos". Comunicaciones de la ACM . 13 (6): 377–387. doi : 10.1145/362384.362685 . ISSN  0001-0782. S2CID  207549016.
19. "Bases de datos de gráficos, segunda edición". O'Reilly | Safari . Consultado el 23 de octubre de 2018 .
20. "De las bases de datos relacionales a las gráficas". Neo4j .
21. "Ejemplos donde brillan las bases de datos Graph: edición Neo4j", ZeroTurnaround
22. "Motor Amazon Neptune versión 1.3.2.1 (20 de junio de 2024)". Docs.AWS.Amazon.com . Servicios web de Amazon . Consultado el 4 de julio de 2024 .
23. "Base de datos de gráficos distribuidos masivamente paralelos en memoria diseñada específicamente para análisis". CambridgeSemantics.com . Consultado el 20 de febrero de 2018 .
24. Rueter, John (15 de febrero de 2018). "Cambridge Semantics anuncia soporte de análisis basado en gráficos AnzoGraph para Amazon Neptune y bases de datos de gráficos". BusinessWire.com . Consultado el 20 de febrero de 2018 .
25. Zane, Barry (2 de noviembre de 2016). "Bases de datos de gráficos semánticos: un digno sucesor de las bases de datos relacionales". DBTA.com . Tendencias y aplicaciones de bases de datos . Consultado el 20 de febrero de 2018 .
26. "Cambridge Semantics anuncia la compatibilidad con AnzoGraph para Amazon Neptune y bases de datos de gráficos". DBTA.com . Tendencias y aplicaciones de bases de datos. 2018-02-15 . Consultado el 8 de marzo de 2018 .
27. Woodie, Alex (21 de junio de 2016). "Más allá de Titan: la evolución de la nueva base de datos de gráficos de DataStax". Datanami.com . Consultado el 9 de mayo de 2017 .
28. "versión 1.0.0 · JanusGraph/janusgraph". GitHub.com . 21 de octubre de 2023.
29. "Backends de almacenamiento de JanusGraph". docs.JanusGraph.org . Archivado desde el original el 2 de octubre de 2018 . Consultado el 1 de octubre de 2018 .
30. "Almacenamiento de índices JanusGraph". docs.JanusGraph.org . Archivado desde el original el 2 de octubre de 2018 . Consultado el 1 de octubre de 2018 .
31. "Novedades de SQL Server 2017". Docs.Microsoft.com . Microsoft Corp. 19 de abril de 2017 . Consultado el 9 de mayo de 2017 .
32. "Nebula Graph debuta para el descubrimiento de análisis de big data". Datanami.com . 29 de junio de 2020 . Consultado el 2 de diciembre de 2020 .
33. "Notas de la versión: Neo4j 5". Neo4j.com . Plataforma de base de datos de gráficos Neo4j . Consultado el 25 de julio de 2024 .
34. "Notas de la versión". Ontotexto GraphDB . 22 de julio de 2024 . Consultado el 22 de julio de 2024 .
35. "Diagramas de arquitectura de implementación de clústeres para Virtuoso". Virtuoso.OpenLinkSW.com . Software OpenLink . Consultado el 9 de mayo de 2017 .
36. Ewbank, clave. "RedisGraph alcanza disponibilidad general". I-Programmer.info .
37. "Novedades de SAP HANA 2.0 SPS 05". blogs.SAP.com . 2020-06-26 . Consultado el 26 de junio de 2020 .
38. Rudolf, Michael; Paraísos, Marcus; Bornhövd, Christof; Lehner, Wolfgang. La historia gráfica de la base de datos SAP HANA (PDF) . Apuntes de conferencias en informática.
39. Vanian, Jonathan (18 de febrero de 2015). "Sqrrl, vinculado a la NSA, se fija en la seguridad cibernética y consigue una financiación de 7 millones de dólares". Gigaom.com . Gigaom . Archivado desde el original el 9 de marzo de 2019 . Consultado el 9 de mayo de 2017 .
40. Woodie, Alex (23 de octubre de 2015). "El arte de la analítica, o lo que nos pueden enseñar los peliverdes". Datanami.com . Consultado el 9 de mayo de 2017 .
41. "Lanzamientos de GitHub". GitHub . Consultado el 3 de julio de 2023 .
42. "Notas de la versión: TigerGraph: Documentos". Docs.TigerGraph.com . TigreGraph . Consultado el 4 de julio de 2024 .
43. "The Forrester Wave ™: plataformas de datos gráficos, cuarto trimestre de 2020". AWS.Amazon.com . Servicios web de Amazon . 16 de noviembre de 2020 . Consultado el 16 de noviembre de 2020 .
44. "Lanzamiento TypeDB 2.14.0 · vaticle/typedb". GitHub . Consultado el 25 de noviembre de 2022 .
45. Svensson, Johan (5 de julio de 2016). "Vista de invitado: bases de datos relacionales frente a gráficas: ¿cuál usar y cuándo?". Tiempos de San Diego . Medios BZ . Consultado el 30 de agosto de 2016 .
46. TinkerPop, Apache. "Apache Tinker Pop". Apache TinkerPop . Consultado el 2 de noviembre de 2016 .