Data Modeling
The Data Modeling domain tests whether you can translate a domain into a graph that answers the intended queries efficiently, rather than reproducing a relational schema with extra hops.
Core rules
Model entities as nodes, connections as relationships, and attributes of a connection as relationship properties. Direction should express meaning (a Flight departs from an Airport), but traversals can go either way, so never store the same relationship in both directions. Labels classify nodes and are what the planner uses to pick indexes; put frequently filtered values in indexed properties. Start from the query patterns: the shapes you must answer determine where you denormalize and which properties you duplicate onto relationships for speed.
Reification
A relationship cannot connect three nodes or be the endpoint of another relationship. When an event links several entities or needs its own connections, promote it to a node: (p:Person)-[:MADE]->(o:Order)-[:SHIPPED_TO]->(a:Address). The same technique tames dense nodes - a single celebrity node with millions of relationships becomes slow to traverse and awkward to lock; insert a per-day or per-category node to spread the fan-out.
Worked example
A flight has a flight number, departure time, and a crew, and also connects two airports. Reasoning: a direct (Airport)-[:FLIGHT]->(Airport) relationship cannot hold a crew relationship or be shared by many dated instances. Model Flight as a node with properties, DEPARTS_FROM / ARRIVES_AT to airports, and ASSIGNED_TO to crew. Queries such as "which crew flew into LHR last week" then start from an indexed Flight.departure range and traverse two hops.
Traps
Using a node where a property suffices (a Country node for a value you never traverse). Mirroring relationships in both directions, doubling writes and storage. Over-indexing every property. Forgetting that relationship properties cannot be indexed directly - if you must filter on them at scale, consider reification.