Semantic Layer & Governance
How Daasity's Looker semantic layer works — governed metrics, Unified Schemas, and how definitions stay consistent across your organization.
Overview
The Looker Explores you interact with are data models defined in the Daasity semantic layer. Each Explore brings together the tables and metrics needed for a specific type of analysis, containing Dimensions (fields such as Product Name, Customer Address) and Measures (calculations such as Dollar Revenue, Net Sales).
This layer sits on top of Daasity's Unified Schemas and Data Marts — the normalized data models that consolidate your source data into consistent, analysis-ready structures. The result is that every report built in Looker draws from the same underlying definitions, so metrics mean the same thing regardless of who built the report or which Explore they used.
Unified Schemas
Daasity maintains seven Unified Schemas, each normalizing a specific domain of your data:
Unified Order Schema (UOS) — order and transaction data across all sales channels
Unified Marketing Schema (UMS) — paid marketing performance data across platforms
Unified Notification Schema (UNS) — customer messaging data across email, SMS, push, and in-app
Unified Traffic Schema (UTS) — digital and retail traffic data across channels
Unified Retail Sales (URS) — retail POS, wholesale shipments, and inventory data
Unified Retail Market Schema (URMS) — syndicated retail market data for category and competitive analysis
Unified Subscription Schema (USS) — subscription program data covering subscribers, churn, and repurchase behavior
For a full overview of all schemas, see the Unified Schema Introduction.
How governance works
Daasity maintains the base metric definitions in the hub — the central set of LookML files imported into your Looker instance. These files define the Explores, dimensions, and measures that power your out-of-the-box dashboards and reports. Because they are centrally managed, Daasity can push updates and improvements to all customers without requiring manual intervention on your end.
Your spoke instance contains editable files where you can extend or override base definitions using LookML refinements — without touching the imported files directly. This separation ensures that your customizations persist across Daasity updates, and that it's always clear what is base Daasity code versus what your team has built.
For details on working within this structure, see Advanced / Developer.
Last updated
Was this helpful?