The problem: technically correct, but still inconsistent
Most analytics teams eventually encounter the same frustrating pattern: one dashboard reports revenue at 10.2M, another at 10.6M, and a spreadsheet says 10.4M. Each result may be technically defensible, yet nobody is fully certain which number should guide a decision. The data platform is rarely the real problem. The issue is fragmented business logic—metric definitions, filters, joins, display names, and formatting rules scattered across SQL notebooks, BI semantic models, dashboards, extracts, and local files.
Databricks Unity Catalog Business Semantics tackles this problem by bringing governed business logic closer to the data. Instead of redefining a KPI in every downstream tool, teams can define it once, govern it centrally in Unity Catalog, and make it consistently available to SQL users, dashboards, notebooks, Genie spaces, alerts, and compatible external tools.
This article moves from the business problem to a working proof of concept. It explains the two core building blocks—metric views and agent metadata—then shows how governance, SQL, Genie, and dashboards come together in a practical adoption path based on Databricks CoE enablement material.
Why a business semantic layer matters
Business users generally ask questions in business language — for example, “Show sales by customer tier this quarter.” They are not thinking in terms of physical table names, technical column names, join paths, date-truncation logic, or whether “sales” should mean gross sales, net revenue, bookings, or recognized revenue. That gap between how people ask questions and how the data is actually modeled creates three recurring problems.
Metric drift
The same KPI gets recreated independently in dashboards, SQL notebooks, spreadsheets, semantic models, and local extracts. A revenue metric may apply one filter in a BI model, a different filter in a SQL notebook, and a third in a spreadsheet. Over time, teams spend more effort reconciling numbers than acting on them.
AI ambiguity
AI/BI tools and LLM-powered agents need more than table schemas — they need business context. Without governed definitions and vocabulary, an agent may pick the wrong table, join, dimension, aggregation, or time filter when answering a natural-language question.
Self-service friction
Business users know terms such as revenue, bookings, margin, segment, region, and fiscal quarter. They should not need to understand every physical column name or join path before they can ask a useful question.
How the Databricks semantic layer works
Unity Catalog Business Semantics is a governed semantic layer for business metrics, KPIs, and AI-friendly vocabulary. At a high level, the flow is:
- Source data lives in tables, views, SQL queries, or curated star and snowflake models.
- Business semantics are defined in Unity Catalog through metric views and metadata.
- Governance—including ownership, permissions, lineage, and audit controls—is applied through Unity Catalog.
- Consumers query governed metrics through SQL, notebooks, dashboards, Genie, alerts, and supported ecosystem tools.
Component | Purpose |
Metric views | Define and govern reusable business KPIs, measures, and dimensions. |
Agent metadata | Teach AI/BI systems the business vocabulary, display names, synonyms, and formatting rules. |
Used together, these two components standardize metric definitions, certify metadata quality, and scale trusted consumption across both human and AI-driven interfaces.
Building the proof of concept: tpch_sales_analytics
To move from concept to evidence, this POC was implemented against the TPC-H sample dataset available in Databricks, producing a single metric view — tpch_sales_analytics — used to validate both the governance model and the AI/BI consumption story described above.
From source tables to the POC
The build follows a clear flow from source data to governed semantics and, finally, to business consumption. In this POC, that flow is represented by the following objects:
Source tables | Business semantics layer | POC consumption |
TPCH sample tables — e.g. orders, customer, nation | tpch_sales_analytics metric view — governed dimensions, measures, and agent metadata in Unity Catalog | Genie natural-language queries, dashboards, and direct SQL MEASURE() queries |
How the metric view was created
- Choose the source. The TPCH source tables provide the foundation for the metric view.
- Define dimensions. Fields such as country, market segment, and order month support grouping and filtering.
- Define measures. Aggregate calculations such as total revenue and order count are evaluated at query time with MEASURE().
- Add agent metadata. Display names, synonyms, and formats help Genie and dashboards interpret plain-language terms correctly.
- Apply permissions. Approved users can query the view without requiring access to the underlying source tables.
Metric view definition
Lineage
Why this is useful
The value became visible immediately: the same figures were returned whether the question came through Genie or a direct SQL query, while dimensions and measures appeared in business language rather than as raw column names. In other words, metric drift and AI ambiguity were addressed by design rather than through policy alone.
Building block one: reusable metric views
The POC rests on two complementary capabilities. The first is the metric view, which keeps business calculations reusable and consistent. The second is agent metadata, which gives those calculations the language context needed by people and AI-driven tools.
Metric views are reusable semantic objects that separate measure definitions from dimensions. This separation matters because not every metric can be safely calculated by first aggregating raw values and then slicing the result in a dashboard — ratios, distinct counts, filtered measures, and time-based calculations can produce incorrect results if every downstream tool re-implements the logic independently.
A metric view lets a team define:
- Source — e.g. prod.sales.orders_enriched
- Dimensions — region, country, product, channel, order month, customer segment
- Measures — total revenue, customer count, gross margin, revenue per customer
- Metadata — display names, synonyms, comments, formats, and business descriptions
Example: a simplified sales metric view
Querying the metric at the grain a user needs
The important point is that the metric logic stays inside the governed semantic object. Users can analyze flexibly — by region, month, or segment — but the underlying calculation remains consistent every time, because the query engine computes the correct aggregation at runtime rather than re-aggregating a pre-grouped result.
Building block of business-aware agent metadata
Metric definitions alone are not enough — AI/BI systems also need language context. Agent metadata converts technical fields into discoverable, readable, and consistently formatted business concepts.
Metadata Type | Why It Helps |
Display names | Show “Total Revenue” instead of total_revenue. |
Synonyms | Map terms such as sales, bookings, revenue, customer tier, or segment to governed measures and dimensions. |
Formatting | Define currency, percentages, dates, abbreviated numbers, and other output formats. |
Descriptions | Explain how a business concept should be interpreted. |
Worked example
Business user prompt: “Show sales by customer tier this quarter.”
User Phrase | Governed Interpretation |
sales | total_revenue |
customer tier | customer_segment |
this quarter | current-quarter date filter on the order date |
display format | currency, abbreviated |
The goal is not simply to expose tables to an assistant — it is to give the assistant governed business meaning, so that natural-language questions resolve to the same trusted metric every time, regardless of who or what is asking.
Govern semantics like a data product
Semantic definitions should be governed with the same seriousness as any other reusable data product. A single metric view can shape executive reporting, AI-generated answers, alerts, and operational dashboards — which makes clear ownership and review essential. Unity Catalog governance brings four controls into the semantic layer:
Control | What It Enables |
Access control | Central privileges, ownership, and inheritance on governed objects. |
Lineage | Trace metrics back to upstream tables and downstream consumers. |
Auditing | Monitor access and system activity for security and compliance. |
Ownership | Assign group ownership for collaborative editing and review. |
Suggested operating model
Role | Owns | Reviews |
Domain SME | Business definition and KPI meaning | Accuracy and business acceptance |
Analytics engineer | SQL/YAML implementation and performance | Query behavior and maintainability |
Governance team | Access, PII, controls, lineage, and audit posture | Security and compliance readiness |
This split avoids a common failure mode: analytics engineers defining technically correct metrics that business teams do not recognize, or business teams defining metrics that cannot be governed or scaled.
What to consider before production adoption
Authoring
Metric views can be authored with SQL DDL or through Catalog Explorer. A low-friction path for teams starting out is to prototype in the UI, validate with SQL queries, and then move repeatable definitions into version-controlled YAML or DDL. “Generate with AI” (Genie Code) can suggest dimension and measure expressions, but AI-generated expressions should be treated as drafts for SME review, not final definitions.
Performance
Semantic reuse can increase query demand. For high-value or high-volume metric views, materialization can pre-compute aggregations, and the optimizer can route eligible queries to materialized results while falling back to source data where needed. The recommended sequence is to start with correctness first, then tune performance based on actual usage — and to note that materialization is currently positioned as an evolving capability that needs workload-specific testing.
Once authoring and performance are understood, the next question is how the governed metric behaves across real consumption paths. The POC tested that directly through Genie, SQL, and a Databricks dashboard.
Proof from the POC: one metric, three consumption paths
The strongest evidence from the POC is that one governed metric can support different experiences without changing its meaning. A business user can ask a question in natural language, an analyst can query the metric in SQL, and a dashboard can present the result visually—all while reusing the same approved definition.
Natural-language consumption through Genie
A business user question was submitted directly to the Genie space configured against tpch_sales_analytics, with no table names, column names, or SQL required.
What this demonstrates: the response surfaces business terms (e.g. “Total Revenue,” “Region”) rather than technical column names — confirming the agent metadata (display names, synonyms) is doing its job.
Direct SQL consumption
The same question was then run as a direct SQL query against the metric view, using the MEASURE() aggregate function:
Dashboard consumption
The same governed metric view was also consumed through a Databricks Dashboard. KPI cards, trend charts, and visualizations were built directly on top of the tpch_sales_analytics metric view without redefining business logic. This demonstrates that a single governed semantic layer can simultaneously power interactive dashboards while preserving consistent metric definitions across all consumers.
- Dashboard consumes the same governed Metric View.
- KPIs such as Total Revenue, Order Count, Unique Customers, and Average Order Value reuse centrally defined measures.
- Visualizations (Revenue Trend, Revenue by Country, Revenue by Market Segment) are created without redefining business logic.
The same metric across different paths
Consumption Path | Result Observed |
Genie (natural language) | Genie Agent improves the overall understanding by creating a standardized report explaining the user query with charts and key business metrics which can be downloaded as pdf. |
Direct SQL (MEASURE()) | Gives basic SQL Query based output , One table with all metrics asked. |
Dashboard | Easy to monitor KPIs and trends through interactive visualizations built on the same metric definitions. |
A practical path from POC to adoption
A good POC or enablement demo should prove that semantics are useful, governed, and consumable. The path stays narrow and business-oriented:
- Select a KPI family. Choose a small but meaningful group—such as revenue, customers, margin, bookings, or pipeline—that exposes genuine definition questions.
- Define the metric view. Choose the source, joins, dimensions, and measures, beginning with metrics stakeholders already care about.
- Add metadata. Connect the governed metric to the language users actually type through display names, synonyms, descriptions, and formats.
- Query and validate. Test the metric in SQL, a dashboard, and a Genie prompt; compare the results with known reports and have domain owners validate the meaning.
- Publish and govern. Assign ownership, permissions, lineage review, and certification status, and document how changes are approved.
Common pitfalls—and how to avoid them
- Treating metric views as only a technical feature — if the business definition is unclear, the metric view will only centralize the confusion. Start with agreed definitions.
- Skipping metadata — without display names, synonyms, formats, and descriptions, AI/BI tools may still struggle to map user language to the right metrics.
- Moving too many metrics at once — start with a KPI family that has visible pain and clear owners, prove the pattern, then expand.
- Ignoring ownership — every certified metric needs an owner, a review path, and a change process, or governed metrics can drift too.
The takeaway
The central lesson from this POC is simple: trusted analytics requires more than a shared data platform. It requires shared business meaning. By combining reusable metric views, business-aware metadata, and Unity Catalog governance, teams can give people, dashboards, SQL workloads, and AI assistants access to the same approved definitions. The result is not just more consistent reporting; it is a more reliable foundation for self-service analytics and AI-driven decision-making.
