Consume Data in Data Marts and Semantic Models
After workflows have been executed, the data warehouse is populated and ready for consumption. The final step is to access the processed data through data marts and semantic models.
AnalyticsCreator generates structures that are optimized for analytical consumption. These include dimensional models and semantic layers that can be directly used by reporting and BI tools.
Purpose
Provide structured, query-ready data for analytical tools and reporting use cases.
Design Principle
AnalyticsCreator separates data processing from data consumption.
- STG and CORE layers handle ingestion and transformation
- DM and semantic models provide consumption-ready structures
Consumers should not access staging or intermediate layers directly.
Inputs / Outputs
Inputs
- Processed CORE structures
- Generated DM layer (facts and dimensions)
- Deployed semantic model
Outputs
- Queryable data marts
- Semantic models with defined relationships and measures
- Data available for reporting tools (e.g. Power BI)
Internal Mechanics
1. DM layer exposure
The DM layer contains consumption-ready structures such as fact and dimension tables or views. These are generated based on the CORE transformations and are optimized for analytical queries.
2. Semantic model generation
AnalyticsCreator can generate a semantic model that defines:
- Relationships between facts and dimensions
- Measures and calculated fields
- Hierarchies and aggregation logic
3. Data access
Reporting tools connect to the semantic model or directly to the DM layer. Typical access patterns include:
- DirectQuery or import into BI tools
- Connection to tabular models
4. Refresh behavior
After workflow execution, the semantic model can be refreshed to reflect updated data. This ensures consistency between the data warehouse and reporting layer.
Types / Variants
Consumption layers
- DM tables or views
- Tabular models
- External BI tool connections
Access patterns
- Direct query on DM layer
- Semantic model (recommended)
- Hybrid approaches
Example
After execution, the following structures are available:
dm.FactSalesdm.DimCustomerdm.DimProduct
A semantic model defines relationships between these tables and exposes measures such as:
TotalSales = SUM(FactSales.Amount)
A reporting tool connects to this model and visualizes sales by customer, product, and time.
When to Use / When NOT to Use
Use when
- Data warehouse has been executed and populated
- Users require analytical access to data
- Reporting or dashboarding is required
Do NOT use lower layers when
- Accessing STG or CORE directly for reporting
- Building reports on non-finalized structures
Performance & Design Considerations
- DM layer should be optimized for query performance
- Semantic models reduce complexity for end users
- Pre-aggregations can improve performance for large datasets
- Direct access to CORE can negatively impact performance and consistency
Design trade-off:
- Direct access offers flexibility
- Semantic models provide consistency and usability
Integration with other AnalyticsCreator features
- CORE transformations: provide input for DM layer
- Deployment: creates semantic models
- Execution: ensures data is up to date
- Macros and transformations: influence calculated fields and measures
Common Pitfalls
- Querying STG or CORE layers directly
- Ignoring semantic model design
- Missing refresh after data load
- Overloading DM layer with unnecessary complexity
Key Takeaway
The DM layer and semantic model provide consumption-ready data for reporting tools and should be the primary access point for analytical workloads.