Dr. Dave Rogers

← Portfolio

Operations Recap: Multi-Grain Semantic Layer at Restaurant-Chain Scale

One published Tableau Data Source  ·  800+ restaurants  ·  Four audiences  ·  One set of metric definitions

Industry: QSR / Multi-Unit Restaurant Role: Sr. Director, BI & QA Period: 2020–2024

Why

A fast-growing quick-service restaurant chain expanding from ~250 to 850+ locations needed one authoritative source of truth for daily operations reporting. Legacy dashboards computed the same metrics in three or four different places; same-restaurant-sales numbers drifted across reports, fiscal-week boundaries disagreed, and new-restaurant openings were treated inconsistently. Leaders spent time reconciling numbers rather than acting on them.

What

I designed and built the Operations Recap Data Mart - a single conformed-grain operational fact table paired with a published Tableau Data Source that functioned as the semantic and metrics layer for the entire restaurant base. One schema. One set of metric definitions. Four very different audiences served without building a separate model for each.

Architecture: One Source, Four Surfaces

SQL Server / Snowflake
source warehouse
Operations Recap Data Mart
multi-grain fact table
Published Tableau Data Source
semantic & metrics layer
Mobile dashboard
restaurant managers & area directors
Daily operator scorecard
forecast, prior-year, SRS
Executive recap
regions, ownership, channels
Multi-year strategic view
ramp curves, lifecycle

How: The Multi-Grain Design

The key architectural decision was deliberately variable grain, controlled by a single History classifier on the reporting date dimension. Each business date was tagged at load time: Today, L90, FY1, FY2, FY3, Future, and every measure-group SELECT filtered and coarsened accordingly. Detail where decisions depended on it; rollup where detail had no consumer.

History WindowSalesDrive-Thru SpeedForecasts & Labor
Today & L90Hourly by item, order type, serving periodBy serving periodForward & actuals
FY1 (current year)Daily, coarsened dimensionsBy serving periodActuals only
FY2 (prior year)Weekly rollupRolled to "All"Not loaded
FY3 (2 years back)Weekly rollupNot loadedNot loaded
FutureNot loadedNot loadedForecasts & targets

After staging each measure-group into temp tables, a stored procedure unioned them into a single conformed schema where every measure column is present in every row, zero-filled where not applicable, and a dummy-row pass guaranteed every restaurant appeared on every date in the window, ensuring downstream Tableau joins never silently dropped rows for closed days or pre-opening restaurants.

How: Conformed Lifecycle Dimensions

Several operational dimensions were pre-computed at load time and embedded in every row, so downstream consumers could filter without re-implementing the rules:

  • Restaurant Status - NRO (first two weeks), Honeymoon (~first four months), Mature (~first 16 months), Comp (thereafter). Lifecycle thresholds were configurable but consistent across all consumers.
  • Same-Restaurant-Sales Include - a flag that applied SRS comparability rules, including paired open/closed status on the matched prior-year date. One filter, no guesswork.
  • Operating Day - a 1/0 flag accounting for closures and a controlled list of event-driven special dates.
  • Days Open - count since opening, used as the input for lifecycle classification.

How: The Semantic Layer

The operational fact table was published to Tableau Cloud as a single Data Source - the semantic layer where business metric definitions lived. Every workbook, every mobile dashboard, and every executive recap inherited these definitions. Representative calculations:

Customer Satisfaction (ratio of sums) Item Mix Share (LOD fixed denominator) Revenue Per Store by channel Unit-economics yield ratios Crew Staffing Ratio Rolling 12-Period Retention New-Restaurant Ramp Curves

These were not metrics in the SQL; they were definitions in the Data Source, with the SQL producing atomic facts and conformed dimensions. This is the distinction that matters: the semantic layer defined the business meaning; the warehouse held the facts. A new metric required one column in the SQL, one calculation in the Data Source, and every consumer inherited it automatically.

▶ Dashboard Demo: Operations Recap (Mobile)

Screen capture of the Tableau mobile dashboard: the Operations Recap as seen by restaurant managers and area directors on a tablet or phone.

Video coming soon

See migration guide for
video upload instructions

Outcomes

1

Single source of truth replaced multiple conflicting legacy operational reports; same-restaurant-sales numbers stopped drifting across reports

4

Distinct audiences: field operators, regional leadership, finance, and executives, served from one model without separate builds per audience

250→850+

Restaurant footprint supported over four years without rebuilding the analytics architecture

When a metric definition changed, the change propagated automatically to every consumer. When a new audience needed a dashboard, they inherited the same calculations through a different layout; that is the test a semantic layer either passes or fails.

Stack

SQL Server Snowflake T-SQL Stored Procedures Tableau Cloud Tableau LOD Expressions Published Data Source AWS

The Pattern in 2026

The multi-grain History classifier and the presentation-time KPI library are the same design discipline expressed in modern platforms as Snowflake Semantic Views, Databricks Metric Views, and dbt MetricFlow. The metric definitions that lived in the Tableau Data Source map directly to the Open Semantic Interchange specification. The work is portable. The discipline is the same: define metrics where every consumer can reach them, not inside the consumer.