Graph-Relational Database Model
- Graph-relational database model is a unified framework that integrates relational tables and graph structures while preserving semantics and queries.
- It employs diverse methodologies from direct mapping to native DBMS integration, achieving significant performance improvements in graph querying.
- The model supports advanced applications including predictive deep learning, semantic enrichment, and hybrid query execution.
In the literature considered here, a graph-relational database model denotes a class of approaches that place relational structure and graph structure in one formal or operational framework. Some proposals define direct mappings from relational databases to property graphs and require information preservation, semantic preservation, and query preservation; some make graphs first-class database objects inside an RDBMS; some implement typed graph schemas through relational metadata and base tables; and some recast normalized multi-table databases as heterogeneous temporal graphs for predictive learning rather than for storage or query processing (Boudaoud et al., 2022, Hassan et al., 2017, Crowe et al., 2023, Fey et al., 2023, Figueira et al., 2024).
1. Conceptual scope
The surveyed work does not present a single canonical graph-relational construction. Instead, it presents several recurring formulations that differ in purpose, formalism, and execution model.
| Orientation | Core move | Representative papers |
|---|---|---|
| Direct mapping | Map to while preserving information, semantics, and queries | (Boudaoud et al., 2022) |
| Native DBMS integration | Treat graphs as first-class database objects or native operators inside an RDBMS | (Hassan et al., 2017, Paradies et al., 2014, Fu, 2024) |
| Typed conceptual modeling | Use a typed graph schema as the conceptual model and realize it through relational technology and metadata | (Crowe et al., 2023, Crowe et al., 2024) |
| Relational logic for graph querying | Encode property graphs as relational structures and study graph languages through $\FO[TC]$, $\ESO$, and $\SO$ | (Figueira et al., 2024) |
| Learning-oriented graphification | Transform rows to nodes and primary-key/foreign-key links to typed edges for GNNs or graph transformers | (Fey et al., 2023, Dwivedi et al., 16 May 2025, Wu et al., 15 May 2026) |
| Semantic graph layers | Represent relational structure, lineage, and process metadata as ontologies or knowledge graphs | (Dutkiewicz et al., 15 May 2026) |
This plurality is substantive rather than terminological. In system-oriented work, the graph-relational model is usually a storage, query, or execution design. In learning-oriented work, it is typically a derived representation of a normalized database used as the substrate for message passing, attention, or graph-conditioned generation. This suggests that the expression functions as an umbrella concept rather than a single standardized model.
2. Formal foundations
A strongly typed formulation appears in the Typed Graph Schema and Typed Graph Model. The schema is written as
with node types , edge types , a function assigning each edge type to tail and head node-type sets, a set of data types , multiplicity information 0, and constraints 1. The corresponding instance model is
2
where 3 is a homomorphism from graph instances to graph types, so that every node and edge has exactly one type and the mapping is structure preserving (Crowe et al., 2024). In this line of work, the graph-relational model is not a loose “graph view,” but a typed schema theory with multiplicities, constraints, inheritance, and role semantics.
A distinct formalization appears in direct mapping work, where a relational database 4 is transformed into a graph database 5 through a total mapping 6. Its defining properties are information preservation, semantic preservation, and query preservation. Information preservation is stated by the existence of a computable inverse 7 such that
8
while semantic preservation is stated through graph consistency conditions corresponding to primary-key and foreign-key constraints, and query preservation is studied through translation from SQL to Cypher (Boudaoud et al., 2022). Here the graph-relational model is a reversible and schema-aware bridge between data models.
The RG model revises the relational model itself by extending attribute domains from 9 to $\FO[TC]$0, where $\FO[TC]$1 is a domain of logical pointers. An extended database $\FO[TC]$2 includes an injective partial reference function
$\FO[TC]$3
with dereference $\FO[TC]$4. In regular form, pointers in the same column point into one relation, and their target subsets are either disjoint or identical (Fu, 2024). This is a more radical graph-relational thesis: graph topology is preserved inside an extended relational model through logical pointers to fragments rather than through only value-based joins.
From a logical perspective, property graphs can be encoded as relational structures with predicates such as $\FO[TC]$5, $\FO[TC]$6, $\FO[TC]$7, $\FO[TC]$8, $\FO[TC]$9, and $\ESO$0. On that encoding, basic restrictor-free GQL is expressible in $\ESO$1; basic positive GQL without shortest is expressible in $\ESO$2; and full basic GQL is expressible in $\ESO$3. The resulting data-complexity bounds are $\ESO$4, $\ESO$5, and $\ESO$6, respectively (Figueira et al., 2024). This formulation does not replace graph semantics with ordinary relational calculus; it identifies exactly which extensions of relational logic are needed for graph navigation and path restrictions.
3. Query languages and native execution inside relational systems
One systems line makes graphs first-class objects inside a relational engine. In GRFusion, a graph view is defined over vertex and edge relational sources, while graph topology is materialized natively in memory and graph attributes remain in relational storage through tuple pointers. The runtime extends tuple types with Vertex, Edge, and Path, and introduces graph operators such as VertexScan, EdgeScan, and PathScan that coexist with relational operators in the same query execution pipeline. The reported effect is up to four orders-of-magnitude in query-time speedup with respect to the compared approaches (Hassan et al., 2017). In this model, the graph-relational boundary is crossed at operator level rather than through ETL or query federation.
GRAPHITE addresses traversal as the central graph primitive in an in-memory column-oriented RDBMS. A traversal configuration is written as
$\ESO$7
where $\ESO$8 is the start set, $\ESO$9 is an edge predicate, $\SO$0 is the collection boundary, $\SO$1 is the recursion boundary, and $\SO$2 is the traversal direction. The framework provides two physical implementations: level-synchronous traversal and fragmented-incremental traversal. Their performance differs by up to two orders of magnitude for different input configurations, and the reported query performance is competitive with two native graph database management systems (Paradies et al., 2014). The significance is that graph-relational execution is treated as an optimizer and storage problem, not only as a logical one.
The RG model extends this execution-centered view with an exploration operator over pointer-bearing relations. If $\SO$3 has an attribute $\SO$4 containing pointers into $\SO$5, then
$\SO$6
joins each tuple $\SO$7 with tuples in the dereferenced fragment $\SO$8, optionally under an explorative condition (Fu, 2024). On top of this, SQL$\SO$9 admits graph pattern queries and a 0-join that semantically matches tuples and vertices referring to the same entity. In WhiteDB, the reported pattern-query gains are 32500x over PostgreSQL, 112x over DuckDB, and 34.0x over GRainDB, while seamless hybrid execution yields average speedups of 3.62x on DBLP × DBpedia, 12.9x on IMDB × LinkedMDB, and 23.9x on YAGO × DBpedia (Fu, 2024). The distinctive point is unified optimization over graph exploration and relational joins in a single plan space.
Direct-mapping work approaches execution differently. Instead of native graph operators inside an RDBMS, it studies a complete mapping from relational databases to property graphs together with SQL-to-Cypher translation, so that each relation becomes a graph vertex type, each tuple becomes a vertex, foreign keys become edges, and SQL joins become graph traversals along those edges (Boudaoud et al., 2022). This preserves the relational interpretation of graph queries while targeting a property-graph query language.
4. Learning-oriented graphification of relational databases
A large recent body of work uses a graph-relational model not as a DBMS design, but as a learning representation. In Relational Deep Learning, a relational database is written as 1, with tables 2 and primary-key/foreign-key links 3, and is transformed into a Relational Entity Graph
4
where each row becomes a node, each key link becomes an edge, 5 assigns node types from tables, and 6 assigns edge types from schema links. The model is temporal through 7, and message passing is restricted to neighbors satisfying 8 for forecasting tasks (Fey et al., 2023). In this formulation, graph-relational modeling is explicitly described as a learned alternative to SQL JOIN+AGGREGATE.
Graph-based Feature Synthesis uses an analogous tuple graph, but emphasizes table-specific row encoders and learned aggregation of forward and backward neighborhoods. Its exact mapping is: row 9 node, table 0 node type, foreign-key reference 1 directed edge, foreign-key column 2 edge type, and non-key attributes 3 node raw features (Zhang et al., 2023). The framework is presented as a graph-mediated extension of tabular models rather than as a pure GNN.
Foundation-model work retains the same row-as-node, PK/FK-as-edge design but enlarges the modeling stack. Griffin defines a database 4 and a graph
5
where rows are nodes and each PK-FK pair induces a relation type. It adds task-conditioned cross-attention over row cells and relation-wise message passing, and is evaluated on graphs extracted from RDBs spanning over 150 million nodes (Wang et al., 8 May 2025). RelGT uses the relational entity graph
6
and decomposes each sampled node into five token components—features, type, hop distance, time, and local structure—before local and global attention (Dwivedi et al., 16 May 2025). Across 21 RelBench tasks, it is reported to match or outperform GNN baselines by up to 18% (Dwivedi et al., 16 May 2025).
Other work makes the same point from different angles. A hybrid BART+GraphSAGE system first serializes each row with schema-aware tokens and then injects those row embeddings into a relational entity graph; on driver-dnf from rel-f1, the fine-tuned hybrid reaches ROC-AUC 7, compared with LightGBM 8, RDL 9, and KumoRFM 0 (Wu et al., 15 May 2026). RDB2G-Bench shows that even within the familiar “rows become nodes, foreign keys become edges” paradigm, graph construction is not unique: table selection, FK selection, and Row2Node versus Row2Edge materially affect performance, and a common heuristic can lead to up to a 10% drop relative to the best graph model (Choi et al., 2 Jun 2025). This benchmark contains about 50k graph-performance pairs over 5 real-world RDBs and 12 tasks, and reports a 606× speedup for method evaluation relative to on-the-fly training (Choi et al., 2 Jun 2025).
The same graph-relational representation also supports generative and compression tasks. GRDM factorizes relational generation as
1
where 2 is a heterogeneous row graph, and then uses graph-conditional diffusion to generate attributes jointly over the sampled graph (Ketata et al., 22 May 2025). Relational Database Distillation defines a synthetic database 3, where 4 is a much smaller synthetic relational entity graph with the same schema, and reports compression from 35.0MB to 61.1KB on Rossmann, from 13.5MB to 89.5KB on Walmart, and from 350.0MB to 69.8KB on Airbnb (Gao et al., 8 Oct 2025). These works use a graph-relational model as the substrate for learning, not as a new query or storage model.
5. Metadata, ontology, and semantic layers
A different branch emphasizes semantic enrichment rather than either operator execution or predictive learning. The RDDL Ontology is an OWL ontology for relational database lineage that reuses PROV-O, CSVW, and DSD, and represents schema-level and instance-level objects including Table, Column, Row, CellValue/ColumnValue, Query, StoredCode, and execution events such as QueryExecution, ProcExecution, and FuncExecution (Dutkiewicz et al., 15 May 2026). Its lineage predicates—tableDerivedFrom, columnDerivedFrom, rowDerivedFrom, and valueDerivedFrom—are derived from prov:wasDerivedFrom, and the resulting semantic graph is used for inductive link prediction. The reported average improvements of the enriched ontology over the baseline are 5 Precision, 6 Recall, 7 AUC, and 8 Hits@10 (Dutkiewicz et al., 15 May 2026).
Typed-graph implementation work makes a related claim at the DBMS level: graph semantics should live in metadata and base tables rather than only in application code. In that line, node types and edge types become relational base tables, graph metadata is stored in the DBMS, and graph-oriented CREATE and MATCH syntax operates transactionally over ordinary tables with automatically introduced identifiers and endpoint roles (Crowe et al., 2023). The implementation in Pyrrho DBMS is presented as a way to ensure that the conceptual graph model is “an important part of the database implementation” rather than a separate annotation layer (Crowe et al., 2024). The common thread is that graph-relational modeling can function as a semantic layer over relational technology, not only as a storage abstraction or a learning graph.
6. Misconceptions, disagreements, and open directions
A recurrent misconception is that graph-relational modeling always proposes a new database model in the narrow DBMS sense. Several papers explicitly reject that interpretation. The hybrid BART+GNN model is described as “not a new logical or conceptual data model in the classical database-theory sense,” but as a machine-learning representation of a relational database (Wu et al., 15 May 2026). Relational Database Distillation is likewise a task-oriented graph representation rather than “a new general-purpose database model” (Gao et al., 8 Oct 2025). RelGT states that it does not propose a new database model in the DBMS sense, but a graph transformer over a graph view of relational tables (Dwivedi et al., 16 May 2025). The term therefore spans both system models and learned graph views.
A second misconception is that there is one natural or lossless way to graphify a relational schema for every downstream purpose. RDB2G-Bench shows that this is false even within a constrained design space: included tables, included foreign keys, and Row2Node versus Row2Edge are task-dependent, and graph-model correlations across tasks in the same RDB are often below 9 (Choi et al., 2 Jun 2025). This suggests that a graph-relational model is often workload-sensitive, especially in predictive settings.
A third point of disagreement concerns how much graph querying must depart from relational theory. Systems papers argue for native graph operators inside an RDBMS because self-join-based evaluation is too expensive for traversal-heavy workloads (Hassan et al., 2017, Paradies et al., 2014). By contrast, the logical perspective shows that property-graph querying can be studied through relational encodings and classical logic, with basic restrictor-free GQL in 0, positive non-shortest fragments in 1, and full basic GQL in 2 (Figueira et al., 2024). These positions are not contradictory: one is about evaluation strategy and physical execution, the other about definability and complexity.
Open directions remain visible across all strands. Direct-mapping work identifies richer integrity constraints and monotonicity under updates as future problems (Boudaoud et al., 2022). GRAPHITE explicitly focuses on traversal and leaves broader graph functionality and storage variants for future extension (Paradies et al., 2014). Learning-oriented systems note limitations of scale, simple temporal encodings, task coverage, and sequential rather than end-to-end training regimes (Dwivedi et al., 16 May 2025, Wu et al., 15 May 2026). This suggests that graph-relational database modeling remains a plural research program, with no single consensus architecture but a stable shared premise: relational keys, graph connectivity, and typed semantics can be made mutually explicit and operational.