Por qué necesitas un grafo de conocimiento y cómo construirlo
Necesidad y construcción de un grafo de conocimiento
Una guía para migrar de una base de datos relacional a una base de datos de gráficos
TLDR: Un grafo de conocimiento organiza eventos, personas, recursos y documentos en una base de datos de gráficos para análisis avanzados. Este artículo explicará el propósito de un grafo de conocimiento y le mostrará los conceptos básicos de cómo traducir un modelo de datos relacional a un modelo de gráfico, cargar los datos en una base de datos de gráficos y escribir algunas consultas de gráficos de muestra.
¿Por qué un grafo de conocimiento?
Las bases de datos relacionales son excelentes para crear listas, pero son terribles para administrar redes de entidades diversas. ¿Alguna vez ha intentado realizar alguna de estas tareas con una base de datos relacional?
- analizar un episodio de atención médica cuando un paciente interactúa con docenas de personas, lugares y procedimientos
- encontrar patrones de fraude financiero con una red de proveedores, clientes y tipos de transacciones involucrados
- optimizar las dependencias y los elementos interconectados de una cadena de suministro
Estos son ejemplos de redes de eventos, personas y recursos que causan grandes dolores de cabeza a los analistas de SQL que utilizan bases de datos relacionales. Las bases de datos relacionales se vuelven exponencialmente más lentas a medida que aumenta el tamaño de la red, mientras que las bases de datos de gráficos tienen una relación relativamente lineal. Si está administrando una red o web de actividades y cosas, una base de datos de gráficos es la elección correcta. En el futuro, deberíamos esperar ver a los grupos de datos empresariales adoptando una combinación de bases de datos relacionales para análisis aislados en una función comercial, y grafos de conocimiento para procesos complejos y en red que abarcan funciones.
Un grafo de conocimiento, basado en la tecnología de base de datos de gráficos, está diseñado para manejar una red diversa de procesos y entidades. En un grafo de conocimiento, tiene nodos que representan personas, eventos, lugares, recursos, documentos, etc. Y tiene relaciones (aristas) que representan vínculos entre los nodos. Las relaciones se almacenan físicamente en la base de datos con un nombre y dirección. No todas las bases de datos de gráficos son grafos de conocimiento. Para considerarse un grafo de conocimiento, el diseño debe incorporar el modelo semántico empresarial, reflejado en nombres comerciales claros para nodos y relaciones, en un conjunto diverso de nodos que abarcan múltiples funciones empresariales. En esencia, está creando una red continua de todas las partes de la empresa que interactúan y utilizando la semántica empresarial para vincular estrechamente los datos a los procesos que representan. Esto puede servir como base para el uso futuro de modelos generativos de LLM.
Para ilustrar un conjunto diverso de datos en un grafo de conocimiento, veamos un ejemplo simple de logística de cadena de suministro. El proceso empresarial podría estar modelado de la siguiente manera:
- La computación neumática adquiere aire de importancia
- Los criminales han creado sus propios clones de ChatGPT
- La IA está construyendo anticuerpos altamente efectivos que los hum...
Este modelo se podría ampliar para incluir cualquier parte relacionada de los procesos empresariales: devoluciones de clientes, facturas, materias primas, procesos de fabricación, empleados e incluso reseñas de clientes. No hay un esquema predefinido, por lo que el modelo puede expandirse en cualquier dirección o profundidad.
De modelo relacional a modelo dimensional a modelo de gráficos
Ahora pasemos por el proceso de traducir un modelo de base de datos relacional típico a un modelo de gráficos utilizando el escenario de un proveedor de comercio electrónico. Supongamos que este proveedor está ejecutando una serie de campañas de marketing digital, recibiendo pedidos en su sitio web y enviando productos a los clientes. El modelo relacional podría verse así:
Si convirtiéramos esto en un modelo dimensional para usar en un almacén de datos, el modelo podría verse así:
Tenga en cuenta que las tablas de hechos se centran en los eventos, y las tablas de dimensiones representan todos los atributos de una entidad comercial combinados en una sola tabla. Este diseño centrado en eventos brinda tiempos de consulta más rápidos, pero crea otros problemas. Cada evento es una tabla de hechos distinta y es difícil ver la conexión de un evento a un evento relacionado. No hay una forma fácil de comprender todas las relaciones entre una entidad de dimensión, como un producto, y todos los eventos que comparte con una entidad en otra dimensión, como un transportista, cuando esas relaciones se dividen entre varias tablas de hechos. El Modelo Dimensional se centra en un evento a la vez, pero oculta las conexiones entre los diferentes eventos.
El modelo de grafo resuelve el problema de mostrar la interrelación entre entidades modelando el proceso de la siguiente manera:
A primera vista, este modelo de grafo tiene más similitudes con el modelo relacional que con el modelo dimensional, pero se puede utilizar para los mismos fines analíticos que el almacén de datos. Tenga en cuenta que cada relación tiene un nombre y una dirección. Y las relaciones se pueden crear entre cualquier nodo: evento a evento, persona a persona, documento a evento, etc. Las consultas de grafo también le permiten recorrer el grafo de formas no posibles con SQL.
Por ejemplo, puede recopilar cualquier nodo relacionado con un evento clave y estudiar el patrón de ocurrencia. Las jerarquías se conservan y cada nivel se puede referenciar individualmente, a diferencia de una tabla de dimensión desnormalizada. Lo más importante es que los grafos son mucho más flexibles para modelar cualquier evento o entidad en el negocio sin seguir un conjunto estricto de restricciones de esquema. El grafo está diseñado para que coincida con el modelo semántico del negocio.
Extracción, Transformación y Carga (ETL)
Ahora veamos una tabla de base de datos relacional de muestra y creemos algunos scripts de muestra para extraer, transformar y cargar los datos en una base de datos de grafo. Para este artículo, voy a usar el lenguaje Cypher, que es utilizado por Neo4j, la base de datos de grafo comercial más popular. Pero los conceptos se aplicarían a otras variaciones de lenguajes de consulta de grafo (GQL). Usaremos la siguiente tabla de productos de muestra:
Usando esta consulta, podríamos obtener los nuevos productos actualizados en las últimas 24 horas:
SELECT product_id, product_name, cost_usd, product_statusFROM ProductWHERE last_updated_date > current_date -1;Podríamos obtener esos resultados en un dataframe de Python Pandas llamado “df”, abrir una conexión a la base de datos de grafo y luego fusionar el dataframe en el grafo usando este script:
UNWIND $df as rowMERGE INTO (p:Product {product_id: row.product_id})SET p.product_name = row.product_name, p.cost_usd = row.cost_usd, p.product_status= row.product_status, p.last_updated_date = datetime();La primera línea hace referencia a un parámetro “df”, que es el dataframe de Pandas. Fusionaremos en el tipo de nodo “Producto”, que se referencia mediante un alias “P”. Luego, la sección “product_id” se utiliza para vincular a un identificador único en el nodo. Después de eso, la instrucción Merge se parece a un merge en SQL.
Después de haber creado cada uno de los nodos utilizando declaraciones de merge como la anterior, creamos relaciones. Las relaciones se pueden crear tanto en el mismo script como en un script de postprocesamiento utilizando un comando merge como este:
MATCH (p:Product), (o:Order)WHERE p.product_id = o.order_idMERGE (o)-[:CONTIENE]->(p);La instrucción Match se parece al uso de join en Oracle, con dos tipos de nodos declarados después del Match y luego la unión que ocurre en la cláusula Where.
Consultas en el modelo de grafo
Supongamos que hemos construido el grafo y ahora queremos consultarlo. Podemos usar una consulta como esta para ver los grupos de anuncios que han generado pedidos desde Arizona.
MATCH (ag:AdGroup)<-[:BELONGS_TO]-(a:Ad)-[:DRIVES]->(o:Order)<-[:PLACES]-(c:Customer)WHERE c.state = 'AZ'RETURN ag.group_name, COUNT(o) as order_countEsta consulta devolvería el nombre del grupo de anuncios y el conteo de órdenes, filtrado por el estado de Arizona. Ten en cuenta que en Cypher no se requiere la cláusula Group By, a diferencia de SQL. A partir de esta consulta, obtendríamos el siguiente resultado de muestra:
Este ejemplo puede parecer trivial porque fácilmente podrías crear una consulta similar en una base de datos relacional o un almacén de datos utilizando la tabla de hechos de la orden. Pero consideremos una consulta más complicada. Supongamos que quieres ver el tiempo que tarda desde el lanzamiento de una campaña hasta que se han recibido las entregas atribuibles. En un almacén de datos, esta consulta cruzaría tablas de hechos (no es una tarea sencilla) y requeriría recursos considerables. En una base de datos relacional, esta consulta implicaría una larga serie de joins. En una base de datos de gráficos, la consulta se vería así:
MATCH (cp:Campaign) )<-[:BELONGS_TO]-(ag:AdGroup)<-[:BELONGS_TO]-(a:Ad)MATCH (a)-[:DRIVES]->(o:Order)<-[:FULFILLS]-(d:Delivery)RETURN cp.campaign_name, cp.start_date as campaign_launch_date, MAX(d.receive_date) as last_delivery_dateHe utilizado un ejemplo de ruta de consulta, pero hay una variedad de rutas que un usuario podría tomar para responder diferentes preguntas comerciales. En la consulta, ten en cuenta que la ruta desde Campaign hasta Delivery pasa a través de una relación entre Order y Delivery. También ten en cuenta que, para mayor legibilidad, dividí la ruta en dos partes, comenzando con el alias para Ad en la segunda línea. El resultado de la consulta se vería así:
Conclusión
Hemos examinado algunos pasos de muestra para traducir un proceso comercial de comercio electrónico de un modelo relacional a un modelo de gráficos, pero no podemos cubrir todos los principios de diseño en este único artículo. Espero que hayas visto que las bases de datos de gráficos requieren aproximadamente el mismo nivel de habilidad técnica que las bases de datos relacionales, y que la migración no es un obstáculo importante.
El mayor desafío es reentrenar tu mente para alejarte de las técnicas tradicionales de modelado relacional y pensar en términos de modelado semántico o de negocios. Si ves una aplicación potencial para la tecnología de gráficos, pruébala con un proyecto de prueba de concepto. ¡Las posibilidades de análisis con un grafo de conocimiento van mucho más allá de lo que puedes hacer con tablas bidimensionales!
Todas las imágenes son del autor
