Integrating External Data Sources

In this lesson, you will learn how to bridge the gap between rigid, flat relational tables and the flexible, interconnected nature of graph databases.

The Challenge of Flattened Data

Relational databases store data in rows and columns. When you export this data to move it into a graph database, you are typically dealing with "flat" files (like CSVs). A standard Users table and a Purchases table exist as separate islands. To represent these in a graph, you must stop thinking about rows and start thinking about entities (nodes) and interactions (edges).

From Rows to Graph Schema

When mapping relational data to a graph, your primary task is identifying the "Foreign Keys" that actually represent relationships.

Imagine you have a relational table Orders with a customer_id column. In a relational database, this is just a number. In a graph, that customer_id is an instruction to draw a line between a Customer node and an Order node.

Example Mapping Strategy:

1. Nodes: Map your primary entity tables (e.g., Users, Products) to node labels.
2. Edges: Map your join tables or foreign keys (e.g., Orders, Likes) to directional relationships.
3. Properties: Map your column attributes to the properties of the nodes or edges themselves.

Consider this Orders table:

order_id	user_id	product_id	date
501	10	99	2023-10-01

In your graph transformation, this row becomes:

• Nodes: Create/Find User(id: 10) and Product(id: 99).
• Relationship: Create an edge :PURCHASED from the User node to the Product node, carrying the order_id and date as edge properties.

// Mapping the flat row into a graph structure
MATCH (u:User {id: 10}), (p:Product {id: 99})
CREATE (u)-[:PURCHASED {order_id: 501, date: '2023-10-01'}]->(p)

By explicitly mapping these relationships during the import process, you transform static, disconnected records into a living graph that allows for complex traversal queries that would require expensive multi-way JOIN operations in a traditional SQL environment.

Key Takeaway: Importing flat relational data into a graph requires refactoring foreign keys into explicit directional edges and converting entity attributes into node properties.