periodic - import data into neo4j

Modelado de bases de datos Neo4j para marketing de niveles múltiples

Question

Estoy tratando de modelar una base de datos de gráficos para la base de datos neo4j. Aquí están los detalles:

Agentes - Productos - Rangos - Comisiones.

Habrá agentes. Habrá productos (digamos productos de salud).

Un agente se unirá bajo otro agente o puede unirse directamente. Un agente puede tener solo un padre pero varios hijos. No hay límite en la amplitud y profundidad para unir agentes bajo otros agentes.

Los agentes serán promovidos y el rango depende de su valor total de los productos que compraron. Los agentes reciben comisión mensualmente y eso depende de su valor total de los productos que ellos y sus hijos compraron en un mes.

Nodo: agente {nombre, edad, ..., rango} A1, A2, A3 ...

Nodo: Producto {nombre, descripción, ..., precio} P1, P2, P3 ...

Relación: compras {fecha, hora, cantidad, pago total}

(Agente) - [: compras] -> (Producto)

El agente puede comprar múltiples productos a la vez. El agente puede comprar varias veces el mismo producto.

ejemplo:

A1 {''John Doe'', ''34'', ..., ''4''}

P1 {''Px1'', ''desx1'', ..., ''$ 2.3''}

A1 - [: compras {03-01-2014, 09.30, 02, ''$ 4.6''}] -> (P1)

A1 - [: compras {07-01-2014, 13.45, 01, ''$ 2.3''}] -> (P1)

? Aquí es donde estoy atascado. Entonces, ¿tengo que crear una relación [: compras] cada vez que un agente compra un producto, incluso si es el mismo producto?

¿Será eficiente la relación múltiple con el mismo tipo y etiqueta entre los mismos dos nodos en este escenario? Debido a que los agentes probablemente comprarán los mismos productos con frecuencia, esto creará un no mayor. de relaciones múltiples entre los mismos nodos.

¿Este modelo sigue un principio de modelado estándar? ¿Alguien puede sugerir un mejor modelado o corrección?

Answer 1

Supongo que con frecuencia necesita calcular la suma de todas las compras entre un agente específico A y el producto P. De ser así, podría ser beneficioso introducir una relación total_purchases entre A y P que total_purchases la suma. Cada vez que agregue una nueva compra, asegúrese de actualizar la relación total_purchases existente.

Otra cosa a considerar es si el enfoque actual de tener relaciones de purchases oculta algunos conceptos de dominio. Puedo pensar en agentes que hacen pedidos múltiples. Cada pedido contiene varios elementos, que es lo que usted refiere actualmente utilizando la relación de purchases . Entonces, el orden sería un nodo que tenga, por ejemplo, una fecha conectada a 1) el agente y 2) a los productos.

En general, todo lo que es un concepto en sí mismo o que tiene una identidad debe modelarse como un nodo.

Answer 2

Como sugirió Stefan, introduciría nodos de Purchase que tienen relaciones con los productos y también almacenaría el valor de compra en ese nodo. De esta forma puede restringir la consulta a las compras, sin tener que profundizar para llegar a los productos.

(:Agent)-[:made]->(:Purchase {date: XXX, value: XXX})-[:HAS]->(:Product)

Digamos que tenemos una relación :WORKS_FOR para relacionar los agentes de los niños con sus padres:

(a1:Agent)-[:WORKS_FOR]->(a2:Agent)

Esta simple consulta le dará la suma de las compras que cada agente ha hecho por sí mismo, sin tener en cuenta a sus hijos:

MATCH (parent:Agent)-[:MADE]->(p:Purchase) RETURN parent.name, sum(p.value)

Ahora, si además desea tener en cuenta las compras de los hijos de los agentes, puede hacer lo siguiente:

MATCH (parent:Agent)-[:MADE]->(p:Purchase) WITH parent, sum(p.value) AS own_value OPTIONAL MATCH (parent)<-[:WORKS_FOR*]-(child:Agent)-[:MADE]->(pc:Purchase) RETURN parent.name, own_value + sum(pc.value) as total_value