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.FactSales
• dm.DimCustomer
• dm.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.