Relationships & keys — Data 360 reference
Primary keys and relationships in the Data 360 model: what makes a row unique, how DMOs connect, and why an unmodeled relationship is a join your segments and insights silently can't make.
Two model decisions quietly govern everything segmentation and Calculated Insights can do: the primary key of each DMO (what makes a row unique) and the relationships between DMOs (how one object reaches another). Both are easy to under-think at modeling time and expensive to change once data depends on them.
Primary keys
A DMO's primary key determines how its records deduplicate and how other objects join to it. Once data is ingested and identity resolution has run, changing the key re-keys every relationship and downstream join — a rebuild, not an edit.
The discipline is the one Marketing Cloud teams already apply to SubscriberKey: choose what uniquely and stably identifies a row over its whole lifetime, not what's convenient in the source today. (See gotchas — gotcha 3.)
Relationships
Relationships are what let a segment or a Calculated Insight traverse from one DMO to another — an Individual to their orders, an order to its items. A relationship you didn't model is a traversal the platform silently cannot make.
Individual ──(1:many)──▶ Order ──(1:many)──▶ Order Item
the traversals you model are the filters segmentation can buildReference:
What survives in production
Model the traversals before the consumers
The day someone needs "individuals whose orders this quarter exceed a threshold," the relationship between Individual and Order has to already exist — adding it later is a model change with everything depending on it. Map the traversals segments and insights will need before you build them. (See gotchas — gotcha 6.)
Cardinality is part of the meaning
A one-to-many and a many-to-many between the same objects produce different segment results. Model the cardinality that matches reality, and document it — the next person reads the relationship to understand what a traversal returns.
Keys and relationships travel together
A relationship joins on keys. A flaky or unstable key makes every relationship that uses it flaky too. Get the key right first; the relationships built on it inherit its stability.
Quick decision
Model a relationship when:
- A segment or Calculated Insight will ever need to traverse between the two objects.
- The objects share a real-world connection (person to orders, account to contacts).
Leave it out when:
- No downstream consumer needs the traversal, and adding it just deepens joins.
Related
- Data 360 (formerly Data Cloud) architecture gotchas — the model decisions that outlast everything
- Data Model Objects (DMOs) — the objects that carry keys and relationships
- Data spaces — the boundary the model lives within
- Data Architecture Style Guide — the discipline that ties these model decisions together