During 2023 I have been implementing Fritz Laux's concept of the Typed Graph Model (TGM) in PyrrhoDB. This is topical because ISO 9075-16 Property Graph Queries (SQL/PGQ) was published this year, and the new draft international standard ISO 39075 Graph Query Language (GQL) is in development and likely to be published in early 2024. In all three cases, we have the prospect of a full integration between the hitherto different topics of graph databases and relational databases.
PyrrhoV7alpha 7.06 is available on github, and contains considerable progress in this direction. This blog post is based on sections of the Pyrrho Manual and "Introduction to the Source Code of the PyrrhoDBMS" document in that repository. The important point in the implementation of typed graphs in Pyrrho is that graph data can be entered and modified using either relational SQL or the CREATE and MATCH statements, and Pyrrho maintains all of the base tables and indexes to make this work. The graph matching algorithms support repeating patterns and are reminiscent of Prolog backtracking in their use of continuations. The implementation takes care to respect transactions, roles, etc and all the RDBMS aspects, while making the creation and modification of graph data as smooth as possible.
A NodeType (or EdgeType) corresponds to a single database object that defines both a base Table in the database and a user-defined type for its rows. This UDT is managed by the database engine by default, but the usual ALTER operations are available for both Table and UDT. Its first column is a primary key ID of type INT, usually provided in the CREATE statement, or if this is not supplied, a new int value. Other columns are provided in the node type for any properties that are defined for a node of this type.
An EdgeType additionally specifies NodeTypes for Leaving and Arriving foreign key columns (an edge is said to leave a node and arrive at another). This means that all leaving nodes for an edge type have the same node type (and similarly all arriving nodes for an edge type have the same node type. As usual with foreign keys, the engine maintains multisets for the reverse relationships (edges leaving from or arriving at the node).
TNode and TEdge are TypedValues whose dataType is a NodeType (resp EdgeType). A TGraph is a collection of node and edge uids.
Nodes and edges are rows in the tables thus defined, and these can be updated and deleted using SQL in the usual ways, while ALTER TYPE, ALTER DOMAIN and ALTER TABLE statements can be applied to node and edge types.
In CREATE TYPE statements, metadata is available to declare a new type as a node type or an edge type, automatically specifying the ID (resp. ID, LEAVING and ARRIVING) columns and constraints as column 0 (resp, 0,1,2). A more convenient mechanism for defining or adding to typed graphs is provided by the CREATE syntax.
Creating graph data in the RDBMS
A Neo4j-like syntax can be used to add one or more nodes and zero or more edges using the CREATE statement defined below:
CreateStatement = CREATE Graph {THEN Statement END}
Graph= Node Path {',' Node Path } .
Path = { Edge Node } .
Node = '(' GraphItem ')' .
Edge= '-[' GraphItem ']->' | '<-[' GraphItem ']-'
GraphItem = [id | Node_Value] [GraphLabel] [ Document] .
GraphLabel = ':' (id | Label_Value) [GraphLabel] .
In this syntax we see new diglyph and triglyph tokens for indicating the start and end of directed edges. In this syntax id is an SQL identifier for later reference in the statement, not a node ID: node and edge identities are specified in the JSON document doc. Pyrrho will supply a default value for ID if not specified.
The Label identifies a node or edge type (with an optional subtype), which may be new. As suggested above, the columns of new node and edge types are inferred from supplied property values and automatically modified as needed. All nodes and edges by default have the special property ID of type INT. The syntax connects up the edges: it is not permitted to specify leaving and arriving nodes explicitly.
As indicated, the syntax can contain a comma-separated list of graph fragments. The engine endeavours to combine these, verifying or modifying the available node and edge types, and defining new nodes and edges.
Retrieving graph data from the RDBMS
The given graph fragments are evaluated in a recursive process that finds sets of values for unbound identifiers, for which the graph fragments are all found in the database. The result is thus a set of successful assignments of unbound identifiers to TypedValues. The Statement if supplied is executed for each row of this set. To be unbound, an identifier should not match any top-level database object (table, view, domain, type, procedure) or any identifier defined earlier in the current SQL statement. If there are no unbound identifiers in the MatchStatement, its value is just a Boolean indicating whether all of the fragments were found. = MATCH Match {',' Match} [WhereClause] [Statement] [THEN Statements END ] .
The Match statement computes a rowset of bindings for unbound identifiers (or a boolean if there are none) for which the Match is found in all or a selected set of graphs in the database (see MatchMode below). The Statement if present is executed for each row of bindings and may replace it with the result of a RETURN statement. If the Statement is present but has no RETURN, or if it changes the database, there is no rowset result for the MatchStatement. Match removes duplicate rows from its bindings and from the result if present. The THEN clause if present has access to the bindings but does not alter the result rowset.
Match = (MatchMode [id '='] MatchNode) {'|' Match}.
MatchNode = '(' MatchItem ')' {(MatchEdge|MatchPath) MatchNode}.
MatchEdge = '-[' MatchItem '->' | '<-' MatchItem ']-' .
MatchItem = [id | Node_Value] [GraphLabel] [ Document | Where ] .
MatchPath = '[' Match ']' MatchQuantifier .
MatchQuantifier = '?' | '*' | '+' | '{' int , [int] '}' .
MatchMode = [TRAIL|ACYCLIC| SIMPLE] [SHORTEST |ALL|ANY] .
The MatchMode controls how repetitions of path patterns are managed in the graph matching mechanism. A MatchPath creates lists of values of bound identifiers in its Match. By default, binding rows that have already occurred in the match are ignored, and paths that have already been listed in a quantified graph are not followed. The MatchMode modifies this default behaviour: TRAIL omits paths where an edge occurs more than once, ACYCLIC omits paths where a node occurs more than once, SIMPLE looks for a simple cycle. The last three options apply to MatchStatements that do not use the comma operator, and select the shortest match, all matches or an arbitrary match.
The Graph view of graph dataThe database is considered to contain a (possibly empty) set of disjoint TGraphs. Every Node in the database belongs to exactly one graph in this set.
The nodes of a graph are totally ordered by the order of insertion in the database, but this is not the traversal ordering: the first node in a graph is the first in both orderings. The traversal ordering starts with this first node but preferentially follows edges: the leaving edges ordered by their edge types and edge uids followed by arriving edges ordered similarly, while not visiting any node or edge more than once.
The set of graphs is (internally) totally ordered by the defining position of their first node.
In the data management language, an SqlNode is an SqlRow whose domain is a Node type. Evaluation of the SqlNode gives an explicit rowset of TGraph values. A TGraph specified in the above ways may match a subgraph of one of the graphs in this set, in which case we say the TGraph is found in the database.
The relational view of graph data
Graph models are typed collections of nodes and edges. This means that node and edge types are defined with particular typed properties including an integer identity, and for edge types, a leaving and an arriving integer property. Each node or edge type has a collection of nodes and edges, and these can be identified with a relational table whose columns of the properties of the node type/edge type, and whose rows are the values of the properties of a particular node.
The leaving and arriving properties of edges can be thought of as connecting the nodes into directed graphs. The leaving and arriving properties behave like foreign keys to a particular node type. Types can have subtypes (using the standard UNDER keyword).
The above description highlights the similarities with the relational model, so that it becomes natural to add the node/edge type behaviour to a relational type by simple metadata added to a standard type declaration with syntax respectively.
NODETYPE ['(' Identity_id [CHAR] ')']
Where id is an optional name for the identity column (if not specified, a column of type INT called ID is used, or added if not already specified). The column is automatically the primary key of the node type, but also accesses the database-wide collection of nodes and edges. By default it is an integer, but may be declared as a string type.
EDGETYPE [Identity_id ] '('[Leaving_id '='] NodeType_id ',' [Arriving_id '='] NodeType_id ')'
If not specified, columns of type string called LEAVING and ARRIVING are used or added if not already specified or inherited in the type declaration.
The identifiers ID, LEAVING and ARRIVING are not reserved words, and these columns can be renamed on a per-role basis subject to the usual rules and permissions. The identities of these structural columns are however inherited by subtypes. Columns added to a type in this way are appended to the row type.
The simplest node type (for a new node type called MYTYPE), containing only an identity column, is defined by the SQL statement
CREATE TYPE mytype NODETYPE
Additional columns can be specified in the usual ways, by declaring the new type to be UNDER and existing type and/or adding a clause AS '(' column_list ')' before the metadata part. A subtype of a node or edge type automatically inherits all its properties, so the metadata keywords should not occur in the declaration of a subtype of a node type or edge type. Edge types can be similarly defined in SQL.
The Graph CREATE statement has been added to facilitate rapid creation of graph types, nodes and edges. It uses extra token types for indicating directed arrows for edge connections and a JSON-style notation for providing property lists, so that a single statement can create many node types, edge types, and nodes and edges whose associated tables and columns are set up behind the scenes (in one transaction). Identifiers can be defined in the CREATE statement following the usual left-to-right conventions, and Pyrrho will supply an integer id value using its autokey feature if necessary. All such database items can be subsequently retrieved using MATCH and modified using SQL DDL statements such as SQL UPDATE, ALTER statements and now CREATE. An extra feature allows CREATE to be followed by a THEN clause which allows DDL and DML statements to use the identifiers accumulated during the CREATE.
Columns for node and edge types can thus be declared in three ways: (a) explicitly in the type clause of CREATE TYPE following the AS keyword, (b) ID, LEAVING and ARRIVING, in metadata in CREATE TYPE, (c) in the graph CREATE statement for a previously unknown Node or Edge label. In case (c) the values of these properties are also provided for the first node or edge of the new node or edge type.
In all cases, the NodeType.Build method does the actual work of creating the node or edge type and ensuring that the special properties ID, LEAVING , and ARRIVING have appropriate columns and indexes in the new type (or its supertypes). Even for a simple type-declaration, the transaction will require several stages of database object construction.
The parsing of these statements results in a set of physical records for the transaction log: (1) PNodeType or PEdgeType giving merely the name of the new type and its supertype (if there is a supertype all its supertypes and subtypes, and their supertypes and subtypes, will be modified to record this); (2) The new columns of the new type, that is, columns not inherited from supertypes (installing these objects modifies the parent type); (3) new indexes, for the primary key of the new type, and the two special foreign keys of a new edge type (installing these objects will modify the node/edge type to note their uids); and (4) for the graph create statement, Records containing new nodes and edges.
The label part for a node or edge can be a chain of identifiers in supertype to subtype order, but subtypes are first class types in the role and can be referenced on their own. Subtypes inherit the identity column (and leaving, arriving columns for edge types) so that the primary key of the subtype is also the primary key of the supertype. If a chain of labels is used for a new node or edge, any new columns are added to the first type in the chain. A new edge type in a CREATE statement will use the specified types for its leaving and arriving node type constraints.
Then supertypes are created before subtypes, node and edge types before edges, and columns before their indexes. The syntax ensures some regularity, and, for the most part, the class structure of the implementation is helpful. But it is useful at this point in the documentation to distinguish the various tasks and how their supported in the parser. In this version, the base table of a user-defined types has a rowType consisting (only) of the columns declared in the most specific type, but all records may contain values for columns in its pathDomain, which also contains columns inherited from supertypes if any. EdgeType is a subclass of NodeType, so in the discussion of the implementation below we can write node type even if we mean node type or edge type.
Additional data types in the implementation
Every node (TNode) has a unique integer identifier we refer to in these notes as id (whatever its column name is in the current role) and this can be modified using an SQL update statement: its value is independent of the role. The TNode also has a uid property that identifies the database TableRow discussed above. TNode is a subclass of TRow and its fields are the fields of this TableRow.
Every edge (TEdge) has a leaving property and an arriving property whose values reference actual nodes: the database maintains indexes to the actual TNodes. These properties are initially called LEAVING and ARRIVING but can be modified for the model. TEdge is a subclass of TNode, so edges have the identifiers and properties discussed above.
A graph (TGraph) is a collection of TNodes. A database TNode, in principle, identifies a graph consisting of all nodes that be reached by following edges. The database maintains a set of such connected TGraphs that cover the database. Any such connected TGraph can be represented by its base node (the oldest, which has the lowest uid). It follows that TGraphs in the database are not modified directly.
TGParam is a class of TypedValues used only in MatchStatements, which has a lexical uid from its first occurrence in the statement, a type indicating its use in the MatchStatement (flags for node, edge, path, group, nullable) and its name (a string). It is initially unbound, and once bound its value is found in the Context's list of bindings. TGParams can occur as the id of a node or edge, as the label part, or in SqlLiterals.
A MatchStatement is a collection of TGParams, a list of SqlNodes, and possibly where clause and a procedural body. An SqlNode keeps track of the TGParams they introduce, and SqlValues for id, type, and properties (a list of SqlValue key/value pairs: each key is a list of SqlValues that evaluate to strings). SqlNode has a subclass SqlEdge, which also has SqlValues for its leaving and arriving SqlNode, SqlEdge has a sbclass SqlPath, which has a pattern (a list of SqlNodes) and a pair of integers called the MatchQuantifier in the syntax for MatchStatement. All these evaluate to the binding of their id (a TNode or TEdge).
The Match Algorithm
When a MatchStatement is executed, the Context may already contain bindings from an enclosing Match in progress, but its own bindings will be unbound. The MatchStatement examines the first node in its list of SqlNodes and creates a continuation consisting of the rest of its list. On examination of this first SqlNode, a set of database nodes of its required type and properties is constructed; on examination of an SqlPath, the continuation is the pattern. For each element of this set, the SqlNode's TGParams are bound, and traversal continues to the next node in the continuation. . If there is no next node in the continuation, all SqlNodes in the MatchStatement have been bound to database rows (TNodes): subject to the where clause if any, the body of the match statement is obeyed, or if there is no body, a row of bindings is added to the result of the MatchStatement. When all elements at the current stage have been examined, the TGParams in the SqlNode's list are removed from the list of bindings. When the recursion is complete, the MatchStatement's side-effects have occurred and/or the rowset result has been built.
In some ways, unbound identifiers are like the aliases used in ordinary SQL, since they are given a meaning inside the current statement and then forgotten after it is executed. But there is an important difference: by its nature the MatchStatement looks to match unbound identifiers with database objects, so that if you want a new unbound identifier you need to avoid the names of existing database objects (tables, types, procedures, or columns, fields or methods of objects referenced in the current statement), or currently bound identifiers or aliases. These observations also apply to the use of unbound identifiers in the CreateStatement, which also can have a dependent executable statement. In this section we examine more sophisticated opportunities provided by MATCH.
Like the CreateStatement, the Match statement consists of a set of graph fragments, but like a SELECT statement as it builds a rowset whose columns are unbound identifiers in the graph syntax. Such identifiers can occur anywhere in the graph syntax, and as its name implies, the MATCH statement finds all possible values of these such that the graph fragments are found in the database.
[CREATE
(:Product:WoodScrew
{spec:'16/8x4'}),(:Product: WallPlug{spec:'18cm'}),
(Joe)-[:Ordered
{"Date":date'2002-11-22'} ]->(:"Order"{id:201})]
[MATCH (O:"Order"{id:201})
begin MATCH(P:Product{spec:'16/8x4'}) CREATE
(O)-[:Item {Qty: 5}]->(P);
MATCH ()-[:Item {Qty:A}]->(:T{spec:X}) where A>4
12345678901234567890123456789012345678901234567890
match (:"Order")-[:Item where
Qty>4]->(:T{spec:X})
The MatchStatement (referred to as %5 below) defines TGParams T and X and has a single graph whose nodes are the SqlNode #8, the SqlEdge #19, and the SqlNode #40. Looking at the TGParams we see that their properties remain to be discovered during the Build method of the MatchStatement.
The two main methods in the implementation of MatchStatement are:
void ExpNode(Context cx, ExpStep be, Sqlx tok, TNode? pd)
which is passed the current position in the Match Expression in a continuation be (as we will see below) and some context tok and pd, and DbNode:
void DbNode(Context cx, NodeStep bn, Sqltok, TNode? pd)
which is passed a list of relevant nodes in its continuation bn. In
both cases the continuation specifies what the algorithm does if the algorithm
is able to move to the next SqlMatch node. If all the nodes have matched and
there no further nodes, the AddRow method will be called by the EndStep of the
continuation to add a row of bindings to the result in an ExplicitRowSet constructed for the MatchStatement.
To start the process, ExpNode is called as follows:
ExpNode(cx, new ExpStep(sa.mode, xf, new GraphStep(gf.Next(), new EndStep(this), Sqlx.Null, null);
We can see that the continuation specifies the current match expression xf, the remaining graphs of the Match statement gf.Next() (there are none in this case), and the EndStep. The four continuation classes visible above are subclasses of Step, and each Step contains a link to the next step. Step has one more subclass, PathStep, which is discussed in the next section. We start with the first node in the first Graph (gf is a bookmark for the first MatchAlt in the MatchStatement) and an ExpStep (sa is the first MatchAlt, and xf is a bookmark for sa’s first MatchExp).
Thus, the first step in the match is
Step 1: ExpNode({Exp[#8,#19,#40],Graph[],End[%5]}, Null, null)
xn<-{SqlNode COLON #8 421 Order NODETYPE (444)[444,Domain INTEGER] rows 1 Indexes:((444)468) KeyCols: (444=True) IdIx=468 IdCol=444 [#9]}
ExpNode constructs a list of relevant nodes in the database. There is just one at this stage:
ds {(487=..)}
ds[0].vals {(444=201)}
We now call DbNode for this list of possible matches, with a
continuation consisting of a NodeStep for the first node in the list ds,
followed by an ExpStep for the rest of the current graph, and the rest of the
continuation.
Step 2: DbNode
{Node#8:[487],Exp[#19,#40],Graph[],End[%5]}
dn<- {TNode 487[421]}
dn.tableRow {(444=201)}
This node
matches our requirements so DbNode adds any relevant bindings. There are no bindings for this SqlNode, so and the
Next method for our NodeStep continuation takes us to the next SqlNode in the
graph, remembering the node we have just left:
Step 4: DbNode ({Node#19:[990,1024],Exp[#40],Graph[],End[%5]},
ARROWBASE, {TNode 487[421]}
dn<-{ {TEdge 990[774]} vals
{(802=1,847=201,905=1,963=5)}
Again, we hit the DoBindings breakpoint (since Qty is 5) and Next
takes us to
Step 5: ExpNode({Exp[#40],Graph[],End[%5]}, ARROWBASE,
{TEdge 990[774]}
xn<- {SqlNode COLON
#40 -509 NODETYPE rows 0 [#41] {#43=#48}
TYPE T,#41 T,#48 X}
ds<- {[157,{{(48=1,88=16/8x4)}}]}
This time, in DbNode, when we hit DoBindings, we add bindings for
T and X:
Step 6: DbNode {Node#40:[157],Exp[],Graph[],End[%5]},
ARROWBASE, {TEdge 990[774]}
dn<- {TNode 157[113]}
cx.binding<- {(#41=WOODSCREW,#48=16/8x4)}
and Next takes us to next.Next() where the GraphStep is also empty
so we get to the EndStep, and AddRow adds the bindings to ers.explRows:
AddRow(cx)
where cx.binding {[#41=WOODSCREW,#48=16/8x4]})
Returning from AddRow brings us back to Step6, where the bindings are cleared, to Step 4 where we call DbNode at Step 7, where the next value for dn {TEdge 1024[774]} fails the test Qty>4, so backtracks and no further rows get added.
| T | X |
|---|---|
| WOODSCREW | 16/8x4 |
Repeating Patterns
For simplicity let us start with an empty database:
[CREATE (a:Person {name:'Fred
Smith'})<-[:Child]-(b:Person {name:'Peter Smith'}),
(b)-[:Child]->(:Person {name:'Mary
Smith'})]
MATCH (p)-[:Child]->(c) RETURN
p.name,c.name AS child
123456789012345678901234567890123456789012345678901234567890123456
MATCH ({name:'Peter Smith'}
[()-[:Child]->()]+ (x) RETURN x.name
The + is shorthand for {1,*} . The pattern must be overall like a
complicated edge and therefore must start and end with a node, but these need
not be empty: any requirements apply to the repeat and to the preceding and
following nodes.
Tracing the steps as before (and watching also for calls on PathNode):
Step 1: ExpNode ({Exp[#8,%1,#50],Graph[],End[%7]},
Null, null)
xn<- {SqlNode LBRACE
#8 .. {#9=#14}}
ds<- {[112,
{{(47=1,87=Fred Smith)}}]}
{[139, {{(47=2,87=Peter Smith)}}]}
{[346, {{(193=1,236=2,290=1)}}]}
{[372, {{(47=3,87=Mary Smith)}}]}
{[399, {{(193=2,236=2,290=3)}}]}
Step 2: DbNode ({Node#8:[112,139,346,372,399],Exp[%1,#50],Graph[],End[%7]},Null,null)
dn<- {TNode 112[23]} backtrack (on
CheckProps)
Step 3: DbNode(..)
dn<- {TNode 139[23]}
Step 4: ExpNode {Exp[%1,#50],Graph[],End[%7]} null {TNode
139[23]}
Step 5: PathNode
({Path0[#32,#35,#45],Exp[#50],Graph[],End[%7]}, {TNode 139[23]})
Step 6: ExpNode {Exp[#35,#45],Path0[#32,#35,#45],Exp[#50],Graph[],End[%7]},Null, {TNode 139[23]})
xn<-{SqlEdge #35 CHILD}
ds<- {[346, {{(193=1,236=2,290=1)}}]}
{[399, {{(193=2,236=2,290=3)}}]}
Step 7: DbNode ({Node#35:[346,399],Exp[#45],Path0[#32,#35,#45],Exp[#50],Graph[],End[%7]},
ARROWBASE, {TNode 139[23]})
dn<-{TEdge 346[166]}
Step 8: ExpNode ({Exp[#45],Path0[#32,#35,#45],Exp[#50],Graph[],End[%7]},ARROWBASE, {TEdge 346[166]}
xn<- {SqlNode RPAREN #45 }
ds<- {[112, {{(47=1,87=Fred Smith)}}]}
Step 9: DbNode({Node#45:[112],Exp[],Path0[#32,#35,#45],Exp[#50],Graph[],End[%7]},ARROWBASE, {TEdge 346[166]})
dn<- {TNode 110[23]}
Step 10: PathNode ({Path1[#32,#35,#45],Exp[#50],Graph[],End[%7]}, {TNode 112[23]})
ot<- {(%0,(0=(0=TNode 139[23],1=TEdge 346[166],2=TNode
112[23])))}
Step 11: ExpNode ({Exp[#35,#45],Path1[#32,#35,#45],Exp[#50],Graph[],End[%7]},Null,
{TNode 112[23]})
xn<-{SqlEdge COLON #35 166 CHILD ..}
ds<-{} back to step 10
Step 12: ExpNode ({Exp[#50],Graph[],End[%7]},WITH, {TNode 112[23]})
xn<-{SqlNode X #50 -510 NODETYPE rows 0 From:%8 Id=#50 Id X,#50 X}
ds<- {#50, {{(47=1,87=Fred Smith)}}]}
Step 13: DbNode({Node#50:[112],Exp[],Graph[],End[%7]},
WITH, {TNode
112[23]})
dn<- {TNode 112[23]}
AddRow({(#50=TNode 112[23])} back to Step 9 back to step 7
Step 14: DbNode({Node#35:[346,399],Exp[#45],Path0[#32,#35,#45],Exp[#50],Graph[],End[%7]},
ARROWBASE, {TNode 139[23]})
dn<- {TEdge 399[166]}
Step 15: ExpNode ({Exp[#45],Path0[#32,#35,#45],Exp[#50],Graph[],End[%7]},ARROWBASE, {TEdge 399[166]})
xn<-{SqlNode RPAREN #45 }
ds<- {[372, {{(47=3,87=Mary Smith)}}]}
Step 16: DbNode ({Node#45:[372],Exp[],Path0[#32,#35,#45],Exp[#50],Graph[],End[%7]},
ARROWBASE, {TEdge 399[166]})
dn<-{TNode 372[23]}
Step 17: PathNode ({Path1[#32,#35,#45],Exp[#50],Graph[],End[%7]}, {TNode 372[23]})
Step 18: ExpNode
({Exp[#35,#45],Path1[#32,#35,#45],Exp[#50],Graph[],End[%7]}, Null, {TNode 372[23]})
xn<- {SqlEdge COLON #35 166 CHILD ..}
ds<-{} back to step 17
Step 19: ExpNode({Exp[#50],Graph[],End[%7]},WITH,
{TNode 372[23]})
xn<-{SqlNode X #50 -510 NODETYPE rows 0 From:%8 Id=#50 Id X,#50 X}
ds<-{[#50, {{(47=3,87=Mary Smith)}}]}
Step 19: DbNode({Node#50:[372],Exp[],Graph[],End[%7]},
WITH, {TNode 372[23]})
dn<- {TNode 372[23]}
AddRow({(#50=TNode 372[23])} back to step 20 back to step 16
back to step 14 back to step 5 back to step 3
Step 21: dn<- {TEdge 346[166]}
backtrack
Step 22: dn<- {TNode 372[23]}
backtrack
Step 23: dn<- {TEdge
399[166]} backtrack back to step 1
References
F. Laux and M. Crowe, “Information Integration using the Typed Graph Model”, DBKDA 2021: The Thirteenth International Conference on Advances in Databases, Knowledge, and Data Applications, IARIA, May 2021, pp. 7-14, ISSN: 2308-4332, ISBN: 978-1-61208-857-0
N. Francis, A. Gheerbrant, P. Guagliardo, L. Leonid, V. Marsault, et al.. A Researcher’s Digest of GQL. 26th International Conference on Database Theory (ICDT 2023), Mar 2023, Ioannina, Greece. doi:10.4230/LIPIcs.ICDT.2023.1. https://hal.science/hal-04094449
M. Crowe, PyrrhoV7alpha, https://github.com/MalcolmCrowe/ShareableDataStructures
No comments:
Post a Comment