You know Acme Corp bought from you three times last year.
But you just discovered their CEO is also on the board of TechStart, another customer.
No one in your company knew. You almost pitched them competing solutions.
The data was there. The connection wasn't.
ESSENTIAL - Once you know entities exist, you need to know how they connect.
You've cleaned your data. You've resolved entities. You know Customer 47 is Acme Corp across all your systems. But what do you know about Acme Corp?
Relationship mapping answers: Who works there? What have they bought? Who referred them? What other companies do their executives connect to? It's not just about the entity itself. It's about the web of connections around it.
Without relationship mapping, every query starts from scratch. With it, you can traverse connections: 'Show me every company where Acme Corp's executives also serve on the board' takes seconds.
Entity resolution tells you WHO exists. Relationship mapping tells you HOW they're connected. One gives you a list. The other gives you a graph.
Every entity exists in a web of relationships. Mapping those relationships transforms isolated records into actionable intelligence.
Identify the entity. Define relationship types. Link entities through typed connections. Store attributes on both entities and relationships. Enable traversal in any direction.
Click relationships below to add them. Some people connect to multiple companies. Find the bridges.
Click relationships above to start mapping
No bridges yet. Keep adding relationships.
Hint: Some people connect to multiple companies...
Simple but limited
Create a table where each row links two entities. customer_contacts has customer_id and contact_id. Easy to query direct connections, but finding paths (A knows B who knows C) requires multiple joins.
Purpose-built for relationships
Store entities as nodes and relationships as edges. Neo4j, Amazon Neptune. Queries like 'find all paths between A and B within 3 hops' are fast and natural. The database is optimized for traversal.
Best of both worlds
Keep your relational database for transactions. Sync a graph database for relationship queries. Updates flow from the source of truth to the graph. Use each where it excels.
Your sales VP wants to find cross-selling opportunities through executive networks. With relationship mapping, you discover that 12 of your customers share board members with other customers, revealing warm introduction paths worth $400K in potential revenue.
Hover over any component to see what it does and why it's neededTap any component to see what it does and why it's needed
Animated lines show direct connections · Hover for detailsTap for details · Click to learn more
You store 'Acme is a customer of TechCorp.' But when you query TechCorp, there's no way to find Acme. You built a highway system with all one-way roads. Half your queries return nothing.
Instead: Store relationships bidirectionally or use a data structure that handles traversal in both directions.
You know John works at Acme. But when did he start? What's his role? Is this his primary job or a side gig? Without metadata on the relationship itself, you're missing the context that makes connections useful.
Instead: Treat relationships as first-class entities with their own attributes: start date, type, strength, source.
Jane was Acme's CEO. You stored that relationship. She left two years ago. But your system still shows her as CEO because you never track when relationships end.
Instead: Add temporal attributes to relationships. Track when they started and when they ended. Query with time context.
You've learned how to connect entities into a traversable web. The next step is establishing authoritative sources for your most important entities.