Relational data seems like enough to make connections in data; however, there are connections that can require recursive queries and multiple joins that might be difficult to do with straight SQL.

Even if we look at the previous example of tables and compare customers that are connected by location, when they became customers, and the items they ordered, traversing through a graph structure might be easier.
Oracle 23c has native support for property graph data structures, and you can use a GRAPH_TABLE function and MATCH clause to write the queries.

There are more than 60 built-in algorithms for graph analytics.

Here are a couple of areas for these analytics:
• Detecting components and communities
• Evaluating structures
• Predicting links
• Ranking and walking
• Path-finding
• Machine learning

Now, you can start thinking of the questions you can ask of the data, such as making product recommendations, identifying dependencies and relationships, and detecting fraud.

You can even think of the operational data where this can help with workflows and dependencies of assets and systems.

Let’s look at a quick example using the same tables of customers and orders. We can have the customer table be a vertex, and items are also a vertex. Orders are the edges because this will show the connections. The graph will show items the customers have ordered and allow us to see additional related orders.

SQL> create property graph cust_orders vertex tables(customer key (customer_id) properties (customer_name, city,state), items key (item_id) properties (item_name, item_price) edge tables ( orderssource key (item_id) references items (item_id)destination key (customer_id) references customer (customer_id) properties (item_id,customer_id,order_id, order_date));

After we create the graph, we can query it for matches and count the items ordered:

SQL> select item_name, count(1) from graph_table (cust_orders match (src)-[is orders] -> (dst)
columns (dst.item_name)) group by item_name;

The () are for the vertices customer or items, and [] are for the edges that are the orders.
The match clause specifies the pattern from the graph_table, which is the path pattern for the graph. As you can see, we are using the same data without moving it to another graph database or using a separate system; this allows us to perform the analytics or use the graph algorithms against the data.

These simple examples might not give you the big picture of the data possibilities, but knowing you have different ways of viewing, connecting, and analyzing the data with queries on existing data is going to be useful. This allows you to leverage the data assets and use a single source of truth with all of the other security, performance, and reliability of the database that has been configured.