One model across email, calendar, CRM, and tasks.
Email, calendar, a CRM or two, and a task list each keep their own shape. Here is the field that turns them into one current view, in plain language.
A canonical data model is one shared way to describe a person, a company, a meeting, a deal, and a task, that every tool maps into and out of. We walk it the way the field is built: what it is, why it is hard, how a system actually does it, what it makes possible, and where it is heading. The papers behind each idea are linked, so you can read the source yourself.
The three ideas to carry: a shared model in the middle, the mapping that connects it, and trade-offs you cannot escape.
- Given name
- Dana
- Family name
- Okafor
- [email protected]
One shared shape that every tool maps to.
The everyday name is a canonical data model. The same idea shows up in research as a mediated schema.
A salesperson's day is scattered across separate tools. The inbox holds the email threads. The calendar holds the meetings. One or two CRMs hold the accounts, contacts, and deals. The task list holds the follow-ups. The same customer lives in all of them, but each tool keeps its own copy with its own field names. One calls it Company, the next calls it Account Name, a third splits a phone number into pieces the others store as one string. The information is the same. The shape is not.
A canonical data model is the field's answer to that scatter. Instead of teaching every tool to talk directly to every other tool, you define one shared shape in the middle: a single agreed way to describe a person, a company, a meeting, a deal, and a task. Each system maps into that shared shape and back out of it. The structural payoff is the heart of the Canonical Data Model pattern (Hohpe & Woolf, 2003): point-to-point wiring grows with the number of pairs of tools, while a shared model grows with the number of tools, because each maps to the center once.
Native fields
Canonical field
organization.nameEach integration translates its own schema into the shared vocabulary.
The shared shape is a judgment call, not a lookup.
A canonical model is the calm center, but designing it and keeping it honest is real work. Several hard parts sit underneath.
Rich enough, not a junk drawer.
The model has to hold what every source means, yet not collect every field anyone ever had. Too thin and information is lost on the way in. Too thick and it becomes unusable. There is no single correct answer, only a balance.
Sources disagree on structure.
One CRM models a deal with one set of stages, another uses different stages, and the calendar has no concept of a deal at all. One phone string here, three phone fields there. Lining these up is schema mapping, and a clean one-to-one map often does not exist.
Each direction pays somewhere.
Global-as-view makes querying simple but makes changing a source painful. Local-as-view makes adding a source easy but makes answering a query harder. The Lenzerini (2002) framing names the trade rather than hiding it.
Same company, different spelling.
A shared shape does not decide that Acme Corp and Acme Corporation are one company. That is entity resolution, also called record linkage, layered on top. The model makes it addressable in one place. It does not solve it.
The tools keep changing.
Connected tools are autonomous and change on their own schedules. A field is renamed, a new stage appears, an API version changes. The model and its mappings have to be maintained, not set once. The Sheth & Larson (1990) architecture named this autonomy problem early.
One model in the middle, mappings on every side.
Present a shared view, translate each source into it, and answer questions against it. The engineering lives in the mappings.
- 01Wrap
Translate each source schema.
- 02Model
Define the shared concepts.
- 03Map
Specify fields and transformations.
- 04Query
Combine relevant source views.
- 05Maintain
Keep mappings and data current.
The integration spine the Lenzerini (2002) framing lays out: shared model, sources, and the mapping between them.
1Mediator and wrapper
A middle that speaks for everyone.
A classic design splits the work in two. A mediator presents the unified model and routes requests. A wrapper per source translates that source's shape to and from the shared model. This is the mediator concept from Wiederhold (1992), and it maps straight onto the example: one shared model in the middle, one wrapper each for the inbox, the calendar, and each CRM.
Add a tool and you write a wrapper for it. The mediator and the rest of the tools do not change.
| Source | Native field | Canonical field |
|---|---|---|
| From | sender.address | |
| CRM | Account Name | organization.name |
| Tasks | Due At | task.due_at |
2The integration triple
Three things, held in view at once.
Following Lenzerini (2002), a data integration system is three parts. The mediated schema is what the user sees. The source schemas are what each tool actually has. The mapping connects them. Most of the real engineering is in the mapping, not in either schema on its own.
Keeping the three separate is what lets you reason about the system. Change a source, and you know the mapping is where the work lands.
- Source schemas
The fields each connected tool actually exposes.
- Mappings
Rules for transformations, units, relationships, and missing values.
- Mediated schema
The common model a user or query can address.
3GAV vs LAV vs GLAV
Two ways to write the mapping, both with costs.
Global-as-view, or GAV, defines each concept in the shared model as a view over the sources. Querying is simple, but adding or changing a source means rewriting those definitions. Local-as-view, or LAV, describes each source as a view over the shared model. Adding a source is easy, but answering a query is harder, because the system has to work out how to reassemble an answer from source views. GLAV combines the two.
Present these as named options with stated trade-offs, not as one right answer. Each pays somewhere.
Global-as-view
- Define
- The shared field as a query over sources.
- Trade-off
- Queries are direct; source changes may require updating definitions.
Local-as-view
- Define
- Each source as a view of the shared model.
- Trade-off
- Adding sources is easier; answering queries needs rewriting.
4Answering queries using views
Reassemble one answer from many sources.
Under LAV, answering a question against the shared model means figuring out which source views can be combined to produce the answer. This is query rewriting, surveyed in Halevy (2001). It is a studied problem with known methods, and it is the engine behind reading one model that is physically spread across many tools.
That capacity has a name in practice: data virtualization, a unified view assembled on demand without first copying everything into one store.
What is Acme’s current phone number?
- Query the shared model
organization.phone for the resolved Acme identity.
- Read mapped sources
Fetch the CRM record and the latest verified contact details.
- Reconcile evidence
Return the supported value with its source and update time.
5Materialize vs virtualize
Copy it, or leave it in place.
Two honest options sit under any shared model. Materialize means copying everything into one store and keeping it in sync. Virtualize, also called data federation, means leaving data in place and assembling answers on demand through the shared model. Each has costs in freshness, load, and complexity.
Name both. Neither is always right. The choice turns on how fresh the data must be and how much load the sources can take.
Materialized
- Read
- Query a locally stored, unified view.
- Maintain
- Keep that copy synchronized.
Virtual
- Read
- Query sources and combine their current results.
- Maintain
- Handle source latency, load, and availability.
A shared model is a stable base for everything built on top.
At the field level: one current view, cheaper growth as tools are added, two-way flow back to each source, and a steady base for search, reporting, and assistance.
For a salesperson, the bridge is at the outcome level. When email, calendar, the CRM, and the task list all map to one agreed model, the same customer can appear once instead of four times, the latest phone number can be read in one place, and an update can flow back out to each tool in its own native shape. The hard cases above are exactly the ones that decide whether four scattered copies become one view you can trust.
One current, de-duplicated view.
When every tool maps to one model, the same customer appears once, with the latest agreed values, instead of several drifting copies.
Growth gets cheaper.
Adding a sixth tool means writing one mapping to the shared model, not wiring it to the five tools already present.
Edits can flow both ways.
Because each tool has a mapping in and a mapping out, an update read in one place can be written back to each tool in its native shape. The writing-back direction is two-way sync, a related problem the model enables but does not solve on its own.
A steady base downstream.
Search, reporting, and assistance get easier when they read one agreed model instead of negotiating four raw formats. This is a property of the approach, not a claim about any one system.
This explainer covers published research. To see how AI REV Voice helps with sales conversations, explore Prism.
The direction the field is heading.
We describe the direction, not a roadmap of our own.
Beyond matching labels.
Schema mapping has moved from hand-written rules toward learned and language-model-assisted matching, with a person confirming results. Tighter mappings mean a cleaner shared model.
Integrate the parts that earn it.
A direction from the teenage-years (Halevy et al., 2006) line of work: do not build the full perfect model up front. Start loose, integrate the parts that earn it, and tighten over time. Partial integration is a valid state, not a failure.
Leave data in place, more often.
Federated query engines that assemble answers on demand keep improving, narrowing the old gap with copy-everything approaches for many workloads.
A center, not a cure.
A canonical model does not by itself resolve identity, merge concurrent edits, or guarantee the values are correct. It makes those problems addressable in one place rather than scattered across every pair of tools.
The papers behind this page.
- Wiederhold (1992). Mediators in the Architecture of Future Information Systems. IEEE Computer. Open PDF: ilpubs.stanford.edu.
- Sheth & Larson (1990). Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases. ACM Computing Surveys.
- Lenzerini (2002). Data Integration: A Theoretical Perspective. ACM PODS. Open PDF: diag.uniroma1.it.
- Halevy (2001). Answering Queries Using Views: A Survey. The VLDB Journal. Open PDF: seas.upenn.edu.
- Halevy, Rajaraman, Ordille (2006). Data Integration: The Teenage Years. VLDB.
- Hohpe & Woolf (2003). Canonical Data Model. Enterprise Integration Patterns.
Keep reading.
Sibling explainers in the Research section.
One customer. One record.
That is the whole field in one promise: email, calendar, CRM, and tasks read as one current view. See it on a real call.
No app required. Just your phone number.