Come rappresentare un grafico diretto con più genitori?

http://dirtsimple.org/2010/11/simplest-way-to-do-tree-based-queries.html fornisce un algoritmo per l'inserimento e l'eliminazione da una tabella di chiusura.

Vorrei modellare una struttura di dati simile, tranne per il fatto che i nodi possono avere più genitori.

Dato:

Grafico n. 1

Se rimuoviamo [B, C]mi aspetto di finire con:

Grafico n. 2

e se rimuoviamo il nodo Bmi aspetto di finire con:

Grafico n. 3

Tuttavia, se si utilizza l'algoritmo dell'autore per rimuovere collegamenti o nodi, si noterà che viene taggato [D, C, 1]per l'eliminazione, il che è indesiderabile.

Quello che ho provato finora

Ho provato ad adattare la struttura dei dati originale aggiungendo una referencescolonna che indica quanti modi ci sono per viaggiare tra due nodi. Nell'esempio di cui sopra, si può viaggiare da Aa Csia attraverso Bo tramite D. L'idea sarebbe stata che quando Bviene rimosso, il percorso da Aa Cviene mantenuto e il conteggio dei riferimenti diminuisce da 2 a 1. In teoria era bello, ma non riuscivo a capire come far funzionare l'implementazione e ora mi chiedo se è assolutamente possibile (la struttura dei dati potrebbe non contenere informazioni sufficienti per capire quali righe rimuovere).

Quello che sto chiedendo

Come adatteresti le Closure Tables per supportare più genitori? Quali strutture di dati alternative consiglieresti? https://stackoverflow.com/q/4048151/14731 contiene un elenco esaustivo di tali strutture di dati, ma non è chiaro quali supportino (o siano i migliori per) più genitori.

database-design hierarchy

— Gili
fonte

Allora, cosa hai provato? E qual è la referencescolonna?

— ypercubeᵀᴹ

Non credo che uno potrebbe adattare le tabelle di chiusura nello scenario. Le tabelle di chiusura sono utili per molte applicazioni basate su alberi, ma questa domanda allude a un tipo di DAG (Directed Acyclic Graph) molto meno restrittivo. Questo è un argomento che potrebbe essere adatto per una tesi di Master e come tante altre cose quando si tratta di database, una soluzione ottimale dipenderà fortemente dal tuo caso d'uso specifico e preciso. Questo o questo potrebbe aiutarti a iniziare.

— Avarkx,

Quale software db?

— Neil McGuigan,

@NeilMcGuigan, H2 e PostgreSQL anche se ovviamente preferisco una soluzione indipendente dal DB.

— Gili,

Generalmente crea una tabella dei nodi e una tabella delle relazioni. I grafici diretti non sono realmente gerarchici e possono avere loop che rendono più difficile l'interrogazione. Ma se pensi a un DAG come a un albero generalizzato (ovvero un albero che consente a più genitori ma è ancora strettamente gerarchico) e un grafico diretto come un DAG generalizzato (cioè come un DAG ma non strettamente gerarchico) le cose diventano più facili.

Quindi per una soluzione PostgreSQL molto semplice potremmo fare qualcosa del tipo:

CREATE TABLE node (
    id serial primary key,
    payload jsonb not null
);

CREATE TABLE relationship (
    id serial primary key,
    relationship_type text not null,
    from_node int references node(id) not null,
    to_node int references node(id) not null,
    payload jsonb not null
);

Quindi puoi eseguire una query in questo modo:

with recursive dg as (
    select n.id as node_id, null::Int as parent, array[n.id] as path
      from node n
    union all
    select to_node, from_node, path || to_node
      FROM relationship
      JOIN dg on dg.node_id = from_node AND NOT from_node = ANY(path)
)
select * from dg;

— Chris Travers
fonte