DatolioAn entity–relationship diagram describes structural relationships: entities or tables, their keys and how records can relate. It supports governance by making join assumptions visible and reviewable, but it does not show how data moved or changed over time.
Names alone are weak evidence. A credible relationship combines compatible types, uniqueness or key evidence, observed matches, business meaning and a human decision about cardinality. Suggested relationships should remain visibly different from confirmed ones.
Review a proposed relationship
- Check the endpoints Confirm the exact table and field on both sides, including compatible types and formats.
- Inspect key evidence Verify whether the parent side is unique and whether nulls or duplicates change the expected cardinality.
- Test business meaning Ask whether the identifiers represent the same entity, not merely whether sample values overlap.
- Record status and rationale Keep the relationship Suggested until a reviewer confirms cardinality and purpose.
| Question | ER diagram | Data lineage |
|---|---|---|
| What does it represent? | Tables, keys and structural relationships | Origin, movement, transformation and use |
| Typical edge | Transaction.customer_id → Customer.customer_id | Source file → transformation → reporting table |
| Change question | Will this join preserve expected cardinality? | Which downstream assets are affected? |
| Datolio today | Reviewable ER relationships | Roadmap capability; not presented as released |
What good looks like
Confirm a relationship because its technical evidence and business meaning agree. Similar field names are a reason to investigate, not proof.