In my earlier articles I explained how a metadata-driven data platform, dual SCD2 historization, source access views, and business-friendly mappings work together to deliver reliable, demand-driven data to consumers.
But before we can generate SQL code automatically, before we can build exposure views or perform mappings step by step, we need something more fundamental: high-quality data models.
Without them, we’re coding blind. With them, we can automate, govern, and evolve our data platform with confidence.
Why Data Models Are the Cornerstone
Data models are not “just documentation.” They are the blueprints for every transformation in a metadata-driven platform.
They allow us to:
- Describe what data means (logical models).
- Describe how data is stored (physical models).
- Translate messy source structures into consistent, business-oriented structures.
- Enable the business-friendly mapping methodology.
Think of a data model as the contract between business, engineering, and automation.
Logical vs Physical: Two Views, One Reality
Every serious data platform should maintain two versions of each data model:
- Physical model → the technical reality: tables, columns, datatypes, indexes.
- Logical model → the business view: entities, attributes, relationships, subject areas.
The logical model is what the data is about.
The physical model is how the data is stored.
Both are essential. Physical models drive database implementation, while logical models enable business understanding and mappings. The magic happens when we connect them.
Tools of the Trade
There are excellent modeling tools available, such as:
- Erwin Data Modeler
- SAP PowerDesigner
- SqlDbm
- Oracle SQL Developer Data Modeler
- Ellie.ai
- CrossModel
All of these allow us to maintain both logical and physical models, with:
- Tables and entities
- Columns and attributes
- Keys and relationships
- Domains and subject areas
- Diagrams and visualizations
But the tool itself is not the most important part. What matters is the discipline of keeping models complete, consistent, and versioned.
Source Models: Where It All Begins
In a modern data platform, we don’t invent data out of thin air. Data comes from sources – often golden sources that are authoritative in their domain.
Providers sometimes deliver data models along with the data. Often, these are only physical models: table and column definitions, optimized for delivery.
But to apply business-friendly mappings, we first need to reverse engineer these physical models into logical models.
This means:
- Translating cryptic column names into business-friendly attribute names.
- Working with source experts to capture meaning.
- Stripping away irrelevant or purely technical columns.
- Focusing only on what we need to serve use cases (demand-driven).
In short: we reshape the data into a logical source model, the first step in the mapping process.
Why Logical Models Matter for Mapping
Business-friendly mapping depends on clear, understandable structures. If we try to map directly from raw physical sources into business models, we end up with endless technical complexity.
The logical source model gives us:
- Business-friendly names for attributes and entities.
- Clear relationships between concepts (e.g. Party → Person, Organization).
- The ability to leave out what is not relevant for integration.
- A clean starting point for generating source access views.
This is where the translation from source reality to business reality begins.
Metadata as a Data Source
Finally, remember: data models themselves are metadata. And in a metadata-driven platform, metadata is treated like data:
- Imported from tools or delivered files (JSON, YAML, CSV).
- Versioned, historized, validated.
- Exposed in dashboards.
- Used to drive automation.
Good models give us good metadata. Good metadata gives us reliable automation. Reliable automation gives us a data platform that scales.
Closing Thoughts
Before we historize, before we map, before we expose — we model.
High-quality data models, both logical and physical, are the foundation of business-friendly mapping. They connect business meaning with technical implementation, and they give us the metadata we need to automate transformations.
In the next article, I’ll dive deeper into the reverse engineering of physical source models into logical source models — the practical first step of business-friendly mapping.