Graph Analytics inside RDBMS: Leveraging Recursive SQL for Social Network Analysis

TL;DR

As social networks grow, the debate between using specialized Graph Databases vs. traditional Relational Databases (RDBMS) intensifies. This paper demonstrates that Oracle 11.2g can serve as a powerful engine for Social Network Analysis (SNA). By using Recursive SQL, the authors implement complex metrics like Degree Centrality and Local Clustering directly on the database server, proving that you don't always need to migrate to NoSQL to handle graph-like structures.

Problem & Motivation

Social network data is inherently graph-structured (Nodes and Edges). For years, the "Relational model" was criticized for being too rigid for graph traversals, leading to the rise of NoSQL platforms like Neo4j.

The authors argue that for many enterprises, social data is just one part of a massive relational ecosystem. Moving this data to a graph database creates silos, synchronization issues, and security overhead. The motivation here is to see if Oracle's Recursive SQL extensions—specifically the CONNECT BY and NOCYCLE features—can handle graph metrics with the same "natural" feel and efficiency as graph-native tools.

Methodology: Turning SQL into a Graph Engine

The core of the paper lies in mapping graph theory to the Relational Model. The authors propose a schema where actors and relations are stored in standard tables, then use recursive logic to traverse these paths.

1. Degree Centrality

Degree centrality measures a node's involvement in a network. In weighted graphs, this involves not just the count of edges ($k_i$) but also the sum of weights ($s_i$). The authors implement the generalized formula: $C_D^{\omega \alpha }=k_i^{(1-\alpha )}imes{s}_i^{\alpha }$

2. Local Clustering Coefficient (LCC)

LCC is significantly harder to calculate because it requires identifying "triangles"—closed loops of three nodes. This is where Oracle's CONNECT BY shines.

The UML model above shows how nodes and edges are represented within the relational schema.

The Recursive Logic

The authors compare two SQL styles for calculating LCC:

• Oracle-specific (CONNECT BY): Uses a built-in mechanism to find paths of length 3 where the start node equals the end node. It is highly compact.
• ANSI SQL-99 (WITH clause): Uses Common Table Expressions (CTEs) to recursively build the graph. While more portable across different databases (PostgreSQL, DB2), it is significantly more verbose.

Experiments & Results

The study focuses on the expressiveness and initial performance of these SQL implementations.

• Conciseness: The Oracle-specific CONNECT BY syntax is significantly shorter and more readable for developers familiar with the relational model.
• Functionality: By using the NOCYCLE clause, the authors successfully navigated the primary pitfall of RDBMS graph traversal: infinite loops in cyclic social graphs.
• Efficiency: Preliminary tests suggest that processing metrics at the database level eliminates the "latency tax" of moving data to the application layer or external NoSQL servers.

Critical Analysis & Conclusion

Takeaway

The paper successfully makes the case for "Graph-in-RDBMS." By utilizing recursive SQL, developers can perform sophisticated social network analysis without the operational complexity of managing a separate graph database. This is particularly valuable for applications where social interactions are tightly coupled with traditional transactional data (e.g., Banking, CRM).

Limitations

While the paper demonstrates how to calculate these metrics, it lacks a large-scale performance benchmark against dedicated graph databases on massive datasets (billion-scale edges). Furthermore, while CONNECT BY is powerful, its internal optimization for complex "Path-finding" (like Dijkstra's algorithm) is generally less mature than the specialized traversal engines found in NoSQL.

Future Outlook

The authors point towards future research in Performance Tuning, specifically using Index-Organized Tables (IOT) and Partitioning to speed up edge lookups. As RDBMS vendors continue to implement "Graph Tables" (as seen in newer versions of SQL Server and Oracle's own Property Graph features), the boundary between relational and graph databases will continue to blur.