The True Value of a Data Presentation Layer

modeling Mar 26, 2025

A presentation layer is the single final layer of a data pipeline, the one place everything outside the database connects to, whether that's a person running queries or a reporting tool building dashboards. In practice it's a database, or a set of schemas and tables, designed purposely for consumption rather than for modeling. Its value comes down to three things: security, because you can isolate exactly what each group sees; control, because you can tailor columns and logic to an audience without touching the core data model underneath; and simplicity, because end users get clean tables with readable names instead of facts, dimensions and joins. Most teams structure it as a schema per department, sometimes with a shared mart for common entities. The decisions that matter are what your stakeholders actually need, how technical your analysts are, and where the official definition of each metric lives.

Key takeaways

A presentation layer is the final layer of the pipeline and the only one anything outside the data team touches. Everything below it is yours to change.
Security gets easier when there's one place to connect. Roles and groups map to presentation schemas, and nobody has free reign over the raw data or the core model.
The layer sits on top of the data model, so you can tweak columns, formatting or department specific logic for an audience without changing the model itself.
Simplicity for the user is the real payoff. Space cased column names, no joins, no need to understand a star schema. The job is to let people make decisions, not to make them learn data modeling.
The most common structure is a schema per business group. A table per report is tempting but turns into tech debt. A hybrid with a shared mart for common entities usually lands best.
Wide tables built around one concept, like an order summary, strike the balance between reusable and specific.
Define one verified version of each company wide metric, signed off by leadership, and name it that way. Department specific variants can exist alongside it.

What a presentation layer is

As data engineers we like comparing tools and talking about technical things, but the job boils down to delivering insights so a business can make better decisions. How we get there isn't always as important as we think it is.

The presentation layer is one strategic piece of the pipeline that serves that goal directly.

The definition

When I say presentation layer I mean the single final layer of a data pipeline that everything outside the database interacts with. Individuals tapping into the database, reporting tools connecting to build reports, all of it lands in one consolidated place.

Technically that's either a dedicated database or a set of schemas and tables designed purposely for presentation. In my own approach it's usually the third level of a three layer data model, sitting on top of staging and the core model.

The value of building one

The value comes down to three things: security, control and simplicity.

1. Security

By establishing a specific place where anything outside the data team connects, you can be very particular about permissions.

New teams often let anyone access the core data model or the raw data and roam around. That's understandable at first, but at some point it's counterproductive and a genuine security risk.

With separate presentation databases or schemas, you align security to them and assign people to groups tied to those schemas. Systems and people stop having access to information they don't need or shouldn't see.

2. Control

The layer also gives the data team more control over what people see. That might be:

Specific columns or tables
Custom logic that differs between departments, because the accounting team and the sales team might define a thing slightly differently
Formatting, when two groups just want the same thing shown differently

You adjust the presentation without touching the model. The presentation layer sits on top of the core data model, so the model stays stable while the way you present it changes by audience.

Take a customers dimension with a ton of columns. Most groups don't need all of them.

In the presentation layer you pick the columns one group needs and serve those in their schema. Give another group more or fewer, and nobody is overwhelmed by things that aren't relevant to them.

3. Simplicity

Simplicity here means simplicity for the end user. It's more work for us to organize things this way, but when a user goes into their area of the presentation layer everything is set up for them.

Even small things matter: space cased column names instead of snake case, no joins across the underlying model.

They may not understand facts and dimensions, and they shouldn't have to. Give them a clean table so they can plug it into a report and get on with running the business.

That's the real value. It's not renaming a column. It's saving people time and making it as easy as possible to get value from the data.

Common approaches

There are three structures I see most often, plus a question of table shape that applies to all of them.

A schema per business group

The most common structure I see is separate schemas for different departments: accounting, operations, sales, whatever the groups are.

Each schema gets specific tables served from the data model, plus any custom tables that only that group needs.

This also works cleanly with security. You create a role or group of users tied to permissions on that one schema and everyone in the group gets the same access.

A table per report

Another approach is report or deliverable based: an individual table or view for every single report.

The upside is that the logic lives in the warehouse rather than hidden in the report, and the front end becomes a matter of picking columns.

The downside is tech debt. You build something for a report, the report becomes obsolete, nobody knows whether it's still used, and you're left maintaining a pile of tables and code.

I don't think it's the most sustainable option, though the right answer depends on how many tables and reports you're dealing with.

A hybrid with a shared mart

The approach I'd point most teams toward is a hybrid. Keep individual schemas for business groups so things stay isolated, but add a shared schema, call it a presentation mart or a master schema.

The shared schema holds the things everyone uses:

A common customers table
Locations
A dates table

Rather than repeating the same thing in several places, you build it once and everyone refers to the same version.

Wide tables around one concept

The other balance to find is between tables so specific they serve one report and tables so general they need customization for every report. My answer is wide tables built around a single concept.

Something like an order summary that combines a lot of the underlying concepts is reusable across multiple reports but still focused enough to be useful.

There's no single best answer, and finding it is part of understanding your stakeholders and what they need.

Considerations before you build

1. Stakeholder expectations

What's actually needed? Giving too much information confuses people and distracts from the point.

You're not trying to be difficult by limiting what's there. You're giving people only what they need to get the job done, then adding as needed.

Once data is out there you lose control over how it's used and conflicting numbers start to appear, so be deliberate.

Along with that, understand which concepts are shared across groups. That tells you whether a shared schema makes sense or whether everything should stay isolated.

2. Analyst skill set

By analyst I mean anyone functioning that way, whatever their title: the people writing custom queries and building reports who aren't the engineers building the pipeline.

Should they be expected to understand a star schema, facts, dimensions and keys? Maybe, and then you present the facts and dimensions and let them use the model directly. Or maybe those terms will confuse people, and entity focused marts will serve them better.

I've watched data teams hand the company their facts and dimensions and say go build whatever you want. To us it seems obvious. To people outside the data world it's confusing, and they'll work around it without you knowing.

That has nothing to do with intelligence. There are plenty of tools in other departments we'd be lost in if someone just handed them to us.

Be clear about what you expect technically from the people connecting to this data, and let that drive your naming and structure.

3. Metric management

The same name, ten different numbers. One of the most common problems as a company grows is a metric returning different values on different reports. Revenue can be called revenue on ten reports and produce ten numbers.

The presentation layer helps because you can define it per department and be clear about what each group is seeing.

At the same time, establish one definition the whole company uses for universal reporting: a verified revenue column whose definition is signed off by the executive team. Departments can keep their own variants, but when it comes to the company wide number, this is the one, and it's named that way.

Ideally there'd be no conflicting numbers at all, but in reality they happen. A verified set saves a lot of time arguing over which number is right.

4. Where the logic lives

My preference is to put metric logic in the fact table at a set granularity and aggregate later.

Sometimes you need extra logic in the presentation layer. When you do, ask a few questions:

How many places is this happening? The same calculation in three marts is three places to change it.
Can it move back to the fact table? One definition upstream is reused by everything downstream.
Can a macro or function consolidate it? If it has to live in the presentation layer, define it once.

As the presentation layer grows, the rest of the architecture shouldn't lose its structure. Three things keep that in check:

Version control
Automated checks
Documentation

They can feel boring, but they're how you keep delivering things the business trusts.

Key terms

Presentation layer

The final layer of a data pipeline, a database or set of schemas designed purposely for people and tools outside the data team to connect to.

Core data model

The layer of facts and dimensions underneath the presentation layer. The presentation layer reads from it; consumers don't touch it directly.

Data mart

A schema or group of tables in the presentation layer built for a specific audience or concept, such as a sales schema or a shared customers table.

Wide table

A denormalized table built around one concept, like an order summary, that pre-joins what consumers need so they don't have to.

Verified metric

A single, named definition of a company wide number such as revenue, signed off by leadership and used for all universal reporting.

Common questions

What is a presentation layer in a data warehouse?

It's the final layer of the pipeline, the only one that people and reporting tools outside the data team connect to. It's typically a dedicated database or a set of schemas and tables that reshape the core data model into clean, purpose built tables for each audience.

Should each department have its own schema?

That's the most common and usually the best starting point. Each department gets a schema with the tables it needs, and security roles map directly to that schema. Add a shared schema for entities everyone uses, like customers or dates, so you aren't duplicating the same table across departments.

Should I build one table per report?

It's tempting because the report logic ends up in the warehouse, but it tends to create tech debt. Reports go stale, nobody knows which tables are still used, and you end up maintaining a lot of code. Wide tables built around a concept, reused by several reports, hold up better.

How do I stop the same metric showing different numbers on different reports?

Define one verified version of the metric, agreed and signed off by leadership, and name it clearly in the presentation layer. Let departments keep their own variants under different names. Keep the underlying logic in the fact table where possible so there's one place to change it.

Should analysts query facts and dimensions directly?

It depends on their skill set. If they understand a star schema, exposing the model gives them flexibility. If the terms are unfamiliar, entity focused marts with readable column names will get them to answers faster and reduce the chance they work around you.

Final takeaway

A presentation layer is one of the first things I look for when I review a small team's warehouse, because its absence explains a lot of what they're struggling with: everyone querying everything, metrics that disagree, and a data model nobody dares to change. The structure above is what I set up with those teams.

Additional Free Resources

Starter Guides & Checklists

Explore additional free resources built on the same patterns I use with real clients so you can build your own with structure and confidence. Topics include data architecture, modeling and more specifically for small data teams.

Browse Resources