DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Introducing Graph Concepts in Java With Eclipse JNoSQL, Part 2: Understanding Neo4j
  • Spring Data Neo4j: How to Update an Entity
  • Leveraging Neo4j for Effective Identity Access Management
  • The Beginner's Guide To Understanding Graph Databases

Trending

  • How to Write for DZone Publications: Trend Reports and Refcards
  • Agentic AI Design Patterns and Principles: Building Autonomous, Collaborative Systems
  • YOLOv5 PyTorch Tutorial
  • Java String Format Examples
  1. DZone
  2. Data Engineering
  3. Databases
  4. How to Find the Most Connected Neo4j Node Using Cypher

How to Find the Most Connected Neo4j Node Using Cypher

By 
Mark Needham user avatar
Mark Needham
·
Jun. 26, 12 · Interview
Likes (0)
Comment
Save
Tweet
Share
13.5K Views

Join the DZone community and get the full member experience.

Join For Free

As I mentioned in another post about a month ago I’ve been playing around with a neo4j graph in which I have the following relationship between nodes:

One thing I wanted to do was work out which node is the most connected on the graph, which would tell me who’s worked with the most people.

I started off with the following cypher query:

query =  " START n = node(*)"
query << " MATCH n-[r:colleagues]->c"
query << " WHERE n.type? = 'person' and has(n.name)"
query << " RETURN n.name, count(r) AS connections"
query << " ORDER BY connections DESC"

I can then execute that via the neo4j console or through irb using the neography gem like so:

> require 'rubygems'
> require 'neography'
> neo = Neography::Rest.new(:port => 7476)
> neo.execute_query query
 
# cut for brevity
{"data"=>[["Carlos Villela", 283], ["Mark Needham", 221]], "columns"=>["n.name", "connections"]}

That shows me each person and the number of people they’ve worked with but I wanted to be able to see the most connected person in each office .

Each person is assigned to an office while they’re working out of that office but people tend to move around so they’ll have links to multiple offices:

V3

I put ‘start_date’ and ‘end_date’ properties on the ‘member_of’ relationship and we can work out a person’s current office by finding the ‘member_of’ relationship which doesn’t have an end date defined:

query =  " START n = node(*)"
query << " MATCH n-[r:colleagues]->c, n-[r2:member_of]->office"
query << " WHERE n.type? = 'person' and has(n.name) and not(has(r2.end_date))"
query << " RETURN n.name, count(r) AS connections, office.name"
query << " ORDER BY connections DESC"

And now our results look more like this:

{"data"=>[["Carlos Villela", 283, "Porto Alegre - Brazil"], ["Mark Needham", 221, "London - UK South"]], 
"columns"=>["n.name", "connections"]}

If we want to restrict that just to return the people for a specific person we can do that as well:

query =  " START n = node(*)"
query << " MATCH n-[r:colleagues]->c, n-[r2:member_of]->office"
query << " WHERE n.type? = 'person' and has(n.name) and (not(has(r2.end_date))) and office.name = 'London - UK South'"
query << " RETURN n.name, count(r) AS connections, office.name"
query << " ORDER BY connections DESC"
{"data"=>[["Mark Needham", 221, "London - UK South"]], "columns"=>["n.name", "connections"]}

In the current version of cypher we need to put brackets around the not expression otherwise it will apply the not to the rest of the where clause. Another way to get around that would be to put the not part of the where clause at the end of the line.

While I am able to work out the most connected person by using these queries I’m not sure that it actually tells you who the most connected person is because it’s heavily biased towards people who have worked on big teams.

Some ways to try and account for this are to bias the connectivity in favour of those you have worked longer with and also to give less weight to big teams since you’re less likely to have a strong connection with everyone as you might in a smaller team.

I haven’t got onto that yet though!

 

 

 

 

Neo4j

Published at DZone with permission of Mark Needham. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Introducing Graph Concepts in Java With Eclipse JNoSQL, Part 2: Understanding Neo4j
  • Spring Data Neo4j: How to Update an Entity
  • Leveraging Neo4j for Effective Identity Access Management
  • The Beginner's Guide To Understanding Graph Databases

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook