Data Warehouse Planning is where data warehouse architects define the structural foundation before any modeling begins. On the Data Warehouse Planning page, architects work with data development and model design teams to configure Business Category, Data Domain, Business Process, Data Mart, Subject Area, and Data Warehouse Layering — giving every model a structured, layered, and domain-driven home.
How it works
Every data warehouse has the same fundamental challenge: raw data arrives shaped by source systems, but business decisions need data shaped by business concepts. Data Warehouse Planning bridges that gap through two complementary frameworks:
-
Business perspective: organizes data ownership and consumption by business structure
-
Technical perspective: defines how raw data is progressively refined into business-ready metrics
Both frameworks serve the same goal — moving data from source-conformed to business-conformed.
Business perspective planning
The business perspective uses five constructs to organize data from production to consumption.
Business Category is the top-level division of your business — for example, e-commerce, finance, or retail. It defines who owns a given set of data.
Data Domain is a high-level classification that abstracts and groups business processes. A single Data Domain can span multiple Business Categories. For example, a transaction domain might serve both e-commerce and finance.
Business Process is a specific activity within a Data Domain — for example, placing an order or making a payment. A Data Domain can contain multiple Business Processes.
Data Mart is a data endpoint for a specific business scenario, such as an operations platform mart. It represents where data is consumed.
Subject Area divides a Data Mart into topics based on analytical perspective — for example, product analysis or user behavior. A Data Mart can contain multiple Subject Areas.
Technical perspective planning
Data Warehouse Layering defines how data is processed and refined across five layers, spanning all Business Categories, Data Domains, and Data Marts.
DataWorks provides a default five-layer architecture suitable for most needs. Use the Data Layer module to add custom layers for specific requirements.
| ODS | DIM | DWD | DWS | ADS | |
|---|---|---|---|---|---|
| Full name | Operational Data Store | Dimension Layer | Data Warehouse Detail | Data Warehouse Summary | Application Data Service |
| Layer group | Data Import Layer | Common Layer | Common Layer | Common Layer | Application Layer |
| What happens here | Ingests raw data from source systems. Schema mirrors the source. | Builds enterprise-wide consistent dimension tables. | Builds fact tables for detailed data, typically as wide tables. | Builds aggregate metrics at common granularities. | Stores custom statistical metrics. |
| Model types | Source table | Dimension Table, Dimension | Fact Table | Aggregate Table | Application table, Dimension Table, Dimension |
| Metric types | — | Atomic Metric | Atomic Metric | Atomic Metric, Composite Metric, Derived Metric | Composite Metric, Derived Metric |
Design your data warehouse
Custom planning and design
Start with the business objective, then design the technical solution.
-
Plan your Business Categories, Data Domains, and Data Marts based on your organizational structure and consumption needs.
-
Design table storage layers using the five-layer architecture as the baseline.
-
Use a checker to standardize naming conventions across each layer.
-
For complex enterprises, enable Modeling Space to reuse architectures across teams.