4.11.1 - Fact-based models and graph schemas

A fact captures one piece of information

A fact-based model records individual facts rather than treating a whole narrative as one indivisible item. Each fact states one piece of information about an object, a property or a relationship. Several facts can refer to the same identified object.

“Amina is a member of Robotics and joined in 2025” contains linked information. With stable identifiers P17 for the person and C3 for the club, we can distinguish:

• Person P17 has the name Amina.
• Club C3 has the name Robotics.
• Person P17 is a member of Club C3.
• That membership has the joining year 2025.

The membership fact links two objects; the joining-year fact describes that particular relationship. A different member might have joined the same club in 2026. Storing one joining year on the club would wrongly make it a fact about the club as a whole.

Identifiers distinguish objects from their labels. Two people can share a name, and a club's name can change without becoming a different club. Reusing P17 across facts expresses that they refer to the same person. Splitting information into facts must preserve these references; otherwise the relationships are lost.

This lesson focuses on the fact-based and graph-model row of 4.11.1. The companion Big Data lesson explains volume, velocity, variety and distributed functional processing. Those concerns can motivate a different data representation, but a graph is not defined by having a huge dataset.

Nodes, edges and properties

A graph schema captures the intended structure of a dataset: the kinds of nodes and edges and the properties they may have. In a property-graph model, a node represents an object, an edge represents a relationship connecting nodes, and a property stores a named value on a node or an edge.

In a club model, Person and Club are node types. A person node can have id and name properties. A MEMBER_OF edge points from a Person to a Club and can have a joined property. The relationship's type explains what the connection means; its direction identifies the roles of the endpoints.

[DIAGRAM: asset_slug: property_graph; description: Two Person nodes have MEMBER_OF edges to one Club node; each membership edge has its own joining year, while the lower schema gives the shared structure.]

The upper graph contains actual instances: P17/Amina, P24/Ben and C3/Robotics. Its two edges record two memberships with different years. The lower schema gives the common structure Person(id, name) — MEMBER_OF(joined) → Club(id, name). A schema describes permitted kinds of data; it is not merely the names and years from this one sample.

Choose property placement by asking what the value describes. A person's name belongs on the Person node. A club name belongs on the Club node. A joining year describes one membership edge. Graph models can also use event nodes for relationships that need their own identity or many connections; the key requirement is to preserve the facts unambiguously.

Matching a graph structure to requirements

Build a graph model by identifying the objects, the relationships between them and the facts attached to each. The representation must answer the intended questions without silently changing their meaning.

A training network records people and projects. Each person has an ID and name; each project has an ID and title. People can contribute to several projects, and a project can have several contributors. Each person–project contribution has a role, such as designer or tester, with one recorded role per pair.

A suitable schema has Person(id, name) and Project(id, title) nodes, with a CONTRIBUTES_TO edge from Person to Project. Put role on that edge, because the same person may be a designer on one project and a tester on another. The shared Project node prevents the title being treated as a different project for each contributor.

An instance could store P1/Amina connected to J4/Greenhouse with role tester and P2/Ben connected to the same J4 with role designer. Reading the incoming contribution edges identifies that project's contributors. Reading P1's outgoing edges identifies their projects. These are relationships in stored data, rather than a spreadsheet's implied proximity between cells.

In your notebook, draw the two person nodes and one project node, label and direct the two edges, then place the role beside the corresponding edge. Written assessment can ask you to specify this design in words or entity-style descriptions, or interpret a supplied graph; it need not depend on marking a submitted drawing.

If one person can have several separate contribution events to the same project, a single role per pair no longer captures the rules. Separate event nodes with event identifiers, or distinct identifiable edges with appropriate event properties, can preserve the extra facts. State the rules before deciding which representation is sufficient.

Graph models make connected relationships explicit. Relational models can also represent them using keys and link relations. A graph is useful when connections are central to the intended analysis; it is not automatically the best storage model for every large or unstructured dataset.