Graph Querying: Overview

• In The Beginning..
  One of the best known founding moments of graph theory is Leonhard Euler's attempt at solving the Königsberg Bridges riddle, eventually tackling the problem by representing the scenery and its elements in a graph.
  Euler's search for an optimal path is a great referral to the practicality of graph theory, leading all the way to its present-day effectiveness in managing complex data volumes.
• Graph modeling and complex data volumes
  As non-graphical data models are inefficient in (and often incapable of) searching and managing large and complex data sets with intricate relations, various applications take part in complementing or replacing them.
  Databases capable of running graph queries are a major contribution in this regard.
• Graph modeling in a multi-model database
  People often fulfill their graph modeling needs using dedicated graph databases. While this does offer a solid solution, it also produces additional issues that need to be resolved - like the need to integrate source data and graph results.
  Using the graph capabilities of a multimodel database is a native solution that you can use directly without creating additional issues.
  RavenDB is a multimodel database whose graph capabilities are founded upon superb document store and indexing engine. Data already deposited in database documents and indexes can participate in graph querying with no preceding arrangements, easing user administration and improving internal logic and data management.

Graph querying is an expansion of RavenDB's RQL; you can build and test graph queries using the Studio, exactly as you would with non-graph RQL.

Graph Query

The Studio will identify graph queries by their syntax, execute them as such and automatically show their results both graphically and textually.

Graphical View

Textual View

The vocabulary and syntax of graph queries are simple and straightforward. Take for example the following basic query, that maps an organization's "chain of command" by finding who each employee reports to.

match 
    (Employees as employed) - 
    [ReportsTo as reportsTo]-> 
    (Employees as incharge)

Graph query: Query Structure

1. Alias: employed
   Aliases are given to nodes and edges for two main reasons: making queries easier to read and manage, and allowing the filtering and projection of results.

   In this sample query, understanding the search pattern would have been difficult without aliases because origin and destination data nodes are retrieved from the same collection, Employees. The employed and incharge aliases distinguish between this collection's different roles in the origin and destination clauses.

2. Alias: reportsTo

3. Alias: incharge

4. Origin Data-Node Clause: (Employees as employed)
   This clause indicates where the origin data nodes are looked for.

   In this sample query, this clause simply retrieves all documents of the Employees collection.

5. Edge Origin Delimiter: -
   The hyphen connects the edge clause with the origin data-nodes clause.

   In this sample query the "-" indicates that edges will be fetched from data nodes of the Employees collection.

6. Edge Clause: [ReportsTo as reportsTo]
   The edge clause indicates which data nodes' properties are used as edges.

   In this sample query edges are a field named ReportsTo in each data node retrieved from the origin collection.

7. Edge Destination Delimiter: ->
   Edges contain the IDs of destination nodes.
   The arrow indicates in which data set we should be looking for the documents whose IDs the edges hold.

   In this sample query the arrow indicates that destination nodes' IDs are stored in a field named ReportsTo and the documents are in the Employees collection.

8. Destination Data-Node Clause: (Employees as incharge)

   In this sample query edges hold the IDs of documents of the Employees collection.

The graphical view lets you quickly evaluate query results, however complex they may be.
Clicking data nodes in the graphical view displays their contents.

Graph Results: Graphical View

When your query retrieves a whole document, the textual view presents it as {...}.
You can hover above such results to reveal the document's contents.

Graph results: Textual View

To project selected query details, follow your query with a select clause. Select elements and properties you're interested in by their aliases.

Here, for example, is the same basic query we demonstrated above, with a projection this time to make its textual view much more helpful.

match 
    (Employees as employed) - 
    [ReportsTo as reportsTo]-> 
    (Employees as incharge)

select
   id(employed) as employedID, 
   employed.FirstName as employedFirstName, 
   employed.LastName as employedLastName, 
   employed.Title as employedTitle, 
   id(incharge) as inchargeID, 
   incharge.Title as inchargeTitle

Graph Results: Creating Meaningful Textual View Using Projection