Core Graph Concepts

Most of the architecture questions you'll be handed arrive shaped like tables — counts, averages, totals per account. But some of them aren't table questions at all, and the cost of not noticing is that a team spends weeks joining their way toward an answer the structure was never built to give. This course teaches you to recognize the difference and to argue it in front of product, analytics, and governance stakeholders without reaching for tooling.

This lesson builds the shared vocabulary everything else rests on: the core graph concepts, how relationship-centered reasoning differs from record-centered reasoning, and how connected context changes a decision.

In this lesson, you will learn to:

• Identify the six core graph concepts — nodes, edges, labels, properties, paths, and neighborhoods — and express relationship claims as triples
• Contrast relationship-centered with record-centered reasoning by the questions each better supports
• Explain to a stakeholder how governed, connected context could change a decision without overclaiming

A conceptual graph has six working parts, and it is worth learning them as a set of core graph concepts rather than as isolated jargon:

• Nodes are things: a customer, a device, an account, a case.
• Edges are the connections between them, such as opened, installed on, or billed to.
• Labels give a node or edge its type, so a node is not just a thing but a Device or an Account.
• Properties describe nodes and edges: a fault code, an open date, an installation timestamp.
• Paths are sequences of connections, letting you follow customer to device to prior account to earlier case.
• Neighborhoods are the closely connected context around one node — everything within a hop or two of a single faulty router.

Before you model any of it, discipline yourself to state each relationship as a triple: Subject → Predicate → Object. Customer → subscribes to → Plan. Device → was previously installed at → Address. The triple forces you to name the predicate explicitly, and naming the predicate is where most disagreement surfaces. Two teams will happily agree that a customer and a device are linked until you ask them to name the verb.

To see why that matters, consider a short exchange. Dan, a reporting engineer, already has the customer-to-device link in his dashboards. Natalie, a senior data steward, shows him what naming it precisely adds:

• Dan: We already have a customer-to-device link in the reporting layer. I'm trying to understand what writing it as a triple would actually add.
• Natalie: Try saying it out loud with a verb. Which one is it: "Customer → currently uses → Device", or "Device → was previously installed at → Address"?
• Dan: Both are true, but they mean different things. The first is about a person, the second is about a location.
• Natalie: Right. Your reporting layer records one connection. The triples show there are two different claims in there, and only one of them survives the customer moving house.
• Dan: So the ambiguity was always there. We just never had to name it.

Notice that Natalie didn't argue about technology. The triple did the work by forcing a predicate into the open.

Record-centered reasoning organizes the world by rows and aggregates across them. It answers how many cases were opened last week, what is the average resolution time, and what is the total cost per account cleanly and efficiently, and you should say so plainly rather than overselling the alternative. Relationship-centered reasoning organizes the world by connections, and it better supports questions where the connection itself is the subject: which devices have traveled between these accounts, how many hops separate two apparently unrelated complaints, what sits in the neighborhood of one recurring fault.

The sharpest distinction is variable depth. A table-based approach typically needs the number of hops decided in advance, because each hop is another join — and although recursive CTEs and hierarchical queries can traverse variable depth in SQL, they grow harder to write, read, and maintain as the depth stays open-ended. Relationship-centered reasoning lets the depth stay open by default, which matters when nobody knows yet whether the answer is two hops away or five. Avoid claiming tables cannot answer these questions — a recursive query can. The honest claim is about effort, readability, and maintainability at open-ended depth: one framing supports the question naturally, while the other makes you guess its shape first or reach for progressively more elaborate SQL.

Product and governance audiences don't need graph vocabulary; they need to know whether the connections change what they'd decide. That's the argument to make, and it turns on one axis: whether the connected view is governed — built against an agreed vocabulary — or not.

Keep two design choices separate here, because they get collapsed into one another constantly:

• Structure describes how the data is shaped: labeled nodes and edges that carry properties. This is what people usually mean when they say "property graph," and the term says nothing on its own about where those labels came from or whether two teams mean the same thing by them.
• Governance describes where the vocabulary comes from: whether device, customer, and installed on are defined once, in an agreed ontology — an agreed set of concepts and relationship types, as covered previously — and used the same way by every team, or whether each team names things its own way, so device can mean the physical unit to one team and the service line to another.

These are independent choices, not two names for the same fact. A property graph can be built directly against a governed, agreed vocabulary — nothing about the structure prevents it. And a graph someone has already labeled a "knowledge graph" can still drift into inconsistent, team-by-team naming if nobody keeps the ontology behind it maintained. In practice, "knowledge graph" is commonly used as shorthand for a property graph that a team has committed to governing — the label describes an intended discipline, not a different underlying data structure — but it is the commitment that does the work, not the name on the box.

The trap to avoid is assuming governance comes bundled with whichever label a connected view happens to carry. Ask the real question instead: is there an agreed ontology behind these node and edge types, or is each team still free to mean something different by the same word? Stakeholders will conflate structure with governance, and that conflation matters most at the moment of inference. When you tell a governance lead that a path exists between two accounts, you are reporting an observed connection, not a conclusion about behavior — so offer any inference cautiously, as a possible reading rather than a certain fact. A governed vocabulary lets you show your working: here is the claim, here is its type, here is the reading it might support. An ungoverned one lets everyone project their own meaning onto the same picture, which is precisely how connected evidence turns into unearned confidence.

The takeaway to carry from this lesson: a graph earns its place not by being connected but by being governed, so that a relationship means the same thing to every team reading it — and that governance is a discipline you build and maintain, not a property of whatever the structure happens to be called. Two quick checks come first, one on the kinds of questions each reasoning style supports and one on the core concepts. Then you'll be in a live conversation with an analytics lead who can join three tables in his sleep and wants to know what any of this adds, which is exactly the right question and exactly the hardest one to answer without overclaiming.