In this chapter
We'll meet the property graph model — nodes, labels, properties, and relationships as real, typed, directed, first-class data — and build a first real graph with one relationship between two accounts.
The Problem in Real Life
Sarah sketches the fraud ring on paper first — circles for accounts, arrows for "referred by," a couple of boxes off to the side for a shared device and a shared card. It's the clearest the pattern has ever looked. Now she needs it to actually be data, not a drawing.
Mike looks at the sketch. "So a database that just... is this drawing?"
Almost exactly. That's the whole idea.
Sarah
A Drawing on Paper vs. A Drawing That's Also a Database
A node is a thing
An account, a device, a card — each with its own label (what kind of thing it is) and properties (its own data).
A relationship is a real, typed connection
REFERRED_BY, SHARED_DEVICE — directed, named, and able to carry its own properties, not a foreign key waiting to be joined.
Direction is part of the data
a1 REFERRED_BY a2 is a genuinely different fact from a2 REFERRED_BY a1 — not an afterthought.
Modelling means choosing node vs. relationship
A shared device is worth its own node — two accounts can both point to the exact same one, which is the shape a fraud signal needs.
The Property Graph Model
The property graph model is precisely that: a node is a thing (an account, a device, a card), a relationship (also called an edge) is a named, directed connection between two nodes (REFERRED_BY, SHARED_DEVICE), and both nodes and relationships can carry their own properties — plain key-value data, the same flexible shape MongoDB's documents already taught this course. A node can also carry one or more labels — Account, Device, Card — which work like MongoDB's collections or Cassandra's tables: a way of saying what kind of thing a node is.
The genuinely new part, compared to every database this course has covered so far, is that a relationship isn't just a foreign key or an id sitting inside a node's own properties — it's its own real object, with a direction and a type, that the database stores and can be queried on directly.
Each CREATE (var:Label {props}) makes one node — a1 and a2 are both labeled Account, each with its own id/name/createdDaysAgo properties. CREATE (a1)-[:REFERRED_BY {via: 'promo'}]->(a2) makes a real, typed, directed relationship between the two nodes just created — REFERRED_BY, carrying its own property (via), pointing from a1 to a2.
CREATE (a1:Account {id: 'ACC-4471', name: 'Fresh Finds Co', createdDaysAgo: 2})CREATE (a2:Account {id: 'ACC-8820', name: 'Green Basket', createdDaysAgo: 2})CREATE (a1)-[:REFERRED_BY {via: 'promo'}]->(a2)MATCH (a:Account) RETURN a
Check the "Graph state" panel after running this — the relationship renders as its own line, Account(Fresh Finds Co) -[REFERRED_BY]-> Account(Green Basket), not buried inside either account's own data.
Nodes vs. relationships is the one distinction worth being precise about. A node answers "what exists?" A relationship answers "how are two things connected, and in which direction?" a1-REFERRED_BY->a2 is a genuinely different fact from a2-REFERRED_BY->a1 — direction is part of the data, not an afterthought. This is also why the fraud ring from last chapter needed graph modelling specifically: the shape those referral arrows make, all pointing around in a circle, is exactly the fact a relational foreign key was never designed to make visible at a glance.
Modelling a graph, practically, means answering two questions for every real-world thing GreenMart wants to represent: is this a node (a thing) or a relationship (a connection between two things)? And what type/label/properties does it actually need? An account is obviously a node. "Referred by" is obviously a relationship. A shared device turns out to be worth modelling as its own node too, not just a property on an account — because two different accounts can both point to that same device node, which is exactly the shape a shared-device fraud signal needs.
Key Takeaway
A relationship in a graph database is a real, first-class object — typed, directed, and able to carry its own properties — not a foreign key waiting to be joined. That's what makes a shape like a referral ring something the database can represent directly, not just something a person can eyeball in a diagram.
Why This Matters
Every chapter left in this Act builds directly on this vocabulary. Traversals ask the database to walk these exact relationships; fraud detection depends on shared nodes like the device from this chapter's own example; recommendations are just a different-shaped relationship (BOUGHT, not REFERRED_BY) walked the same way.
GreenMart's fraud sketch is now real data — nodes, labels, properties, and one real relationship. Turning "is there a ring here" into an actual question the database can answer is exactly where the next chapter goes.