You may already have an existing project running on a relational database that you'd like to convert to a graph, or you might want to start a new graph project but are more familiar with relational models. Either way, this guide will walk you through the process of easily transforming a relational data model into a graph model.

Introducing the Tables

Assume we have three tables in a retail business: Customer, Merchant, and Transaction. The Transaction table records customers' transaction behaviors with merchants.

Modeling into a Graph

Graph databases are unlike relational databases that require you to establish connections between entities using foreign keys. Instead, you can model the connections directly as edges in the graph.

Building on the graph structure introduced, here's how the transformation goes:

• Entity tables to node types: Map the Customer and Merchant tables, which represent entities, to node types Customer and Merchant.
• Columns to node properties: Transform columns in each entity table into properties of the corresponding node type. Use the primary key as the unique identifier _id for the nodes.
• Relationship tables to edge types: Map the Transaction table, which defines connections, to an edge type TransfersTo. Consider using a verb for the edge type name to better describe the action and its direction.
• Columns to edge properties: Transform columns in each relationship table into properties of the corresponding edge type. Use the foreign keys cust_no and merch_no as edge system properties _from and _to (_id of the source and destination nodes).
• Rows to nodes and edges: Treat each row in the tables as a node or an edge in the graph.

This effectively maps the relational data model to graph structures as shown below:

And here is the graph produced:

You can refer to Importing Data to Ultipa to learn how to import data into the graph database.

Customizing the Graph Structure

Graph structure is highly flexible and can be adapted to meet specific analytical or operational requirements. Adjusting the structure allows you to better align the graph with the focus of your use case.

For example, some scenarios focus on transactions as primary entities that require modeling them as nodes instead of edges. The graph structure can be adjusted as below where the Trasaction table is mapped into the Transaction node type, which connects to the User and Merchant nodes through hasPayer and hasPayee edge types:

In cases where there is a need to analyze the types of merchants, you can enhance the graph structure by extracting the type column in the Merchant table and converting it into a separate node type. Instead of storing this information as a property of Merchant nodes, the graph structure would include Type nodes connected to Merchant nodes.

Ensure the type column is deduplicated before converting rows into Type nodes.