A directed graph represents relationships with a source and a target. Direction matters when it changes meaning: a user who follows another user receives that user’s posts, but the reverse is not implied. Unlike an undirected connection, a directed relationship supports graph-algorithm traversal in only its stated direction. section 2.1.1
Compare a one-way relationship with a connection whose direction is not essential. section 2.1.1
Model a relationship as directed when its orientation carries domain meaning. A Twitter-style follower network uses User nodes and FOLLOWS relationships: Kim following Vanessa does not mean Vanessa follows Kim. Such a network is directed and unweighted when FOLLOWS has no strength value; its creation date can still be stored as a relationship property. section 2.3.1
Follower relationship in Cypher
A directed relationship points from the follower to the followed user: (:User{id:"Vanessa", registeredAt:"2019-03-05"})-[:FOLLOWS{since:"2020-01-01"}]->(:User{id:"Thomas", registeredAt:"2011-03-05"}). The arrow records who follows whom, while properties retain registration and follow dates. section 2.3.1
Direction affects both modeling and analysis:
- Represent an undirected connection with two opposite directed relationships when traversal must work both ways. section 2.1.1
- Avoid adding an opposite duplicate relationship when direction adds no semantic value in a labeled-property graph database. section 2.5
- Use follower direction to examine direct follower counts and transitive influence, including PageRank-style influence. section 2.3.1
- Characterize a directed follower subgraph through connectedness, link density, community detection, and centrality algorithms. section 5.1
Cypher can traverse directed relationships in either direction, but that query flexibility differs from graph-algorithm input, where traversing a directed relationship backward is typically not permitted. Keep this distinction in mind when moving from exploration queries to algorithmic analysis. section 2.1.1


