Your semantic layer starts with your business model.
Daana generates the warehouse structures underneath your semantic layer. Connect what a metric means to the business model and source fields it comes from.
For the semantic layer you already use. For the BI tools and agents that query it.
BUSINESS
Amount charged
Tax-inclusive order-line amount
SOURCE
line_total
quantity × price − discount + tax
REPORTING
Daily revenue
Sum by order day + currency
Declare the meaning.
Generate the foundation.
Daana generates reporting tables from your declarations. Your team connects those tables to your existing semantic layer and configures its metric definitions.
FROM DECLARATION TO QUERY
01 / DECLARE
YOUR TEAM
Business model + requirements
Define the entities, source mappings and reporting grain.
daily_revenue: kind: fact.consolidated grain: [order_date, order_line_amount_currency] spine: {driving: lines}02 / GENERATE
DAANA
Reporting tables
Daana generates the warehouse foundation from your declarations.
fct__order_line_daily_revenue
03 / CONFIGURE
YOUR TEAM
Your existing semantic layer
Connect the generated tables and align your metric definitions.
Manual configuration + definition alignment04 / QUERY
BI TOOLS + AGENTS
Daily revenue
Query through the semantic layer your team configured.
Your existing query stack
BOOKSTORE / ONE QUESTION
What does daily revenue actually count?
The amounts charged on order lines, tax included. Behind those two words are decisions about amount, event time, grain and currency.
Read the business model ↗PUBLIC YAML / SELECTED FIELDS
SOURCE-TO-TARGET MAPPING
line_total → order_line_amount_amount
transformation_expression: line_total
MAPPING → EVENT TIME
order_date → eff_tmstp
entity_effective_timestamp_expression:
(SELECT o.order_date FROM stage.sales_orders o
WHERE o.order_id = sales_order_lines.order_id)REPORTING → DAILY REVENUE
one row / day + currency
grain: [order_date, order_line_amount_currency]
MAPPING → CURRENCY
literal USD → lines’ currency
transformation_expression: &order_currency "'USD'"
- // 01
Amount
line_total = quantity × unit price − discount + tax. A missing tax counts as zero; a missing discount leaves the total empty. The business amount is tax-inclusive; daily revenue sums it.Order-line contract ↗Verify the calculation and missing-value rules. - // 02
Date
order_date comes from the order header. The mapping sets the line’s effective timestamp to this event time, not load time; reporting groups by its date.Order contract ↗Verify the order header’s event date. - // 03
Grain
An order line is identified within its order. Daily revenue has one row per day and currency.Reporting grain + sum ↗Verify the day + currency grain and aggregation. - // 04
Currency
USD is declared in the sample mapping. No currency conversion is applied; reporting keeps the lines’ currency.Amount, time + currency mapping ↗Verify the amount, event-time and USD mappings.
Trace the meaning. Own the definition.
Start with one business area. Compare its metric definitions with the declared model. Where they disagree, decide which one is the definition and make the other refer to it, so each metric has one owner, whether people query it through a BI tool or a text-to-SQL agent.
MODEL.YAML / ORDER_LINE_AMOUNT
“Amount charged for the line, tax included”
Column-level lineage shows which fields feed a result. The business model, source contracts and mappings also explain what the result means: its calculation, grain, time basis and relationships.
Why context alone is not enough- 01Agree the definition and metric grain with the people who use it.
- 02Declare the model, mappings and reporting requirements.
- 03Point your semantic layer at the resulting tables. Keep its definitions aligned.