Dimension Table
A dimension table is a database table in a star or snowflake schema that stores descriptive attributes used to filter, group, and drill-down in analytical queries.
Dimension tables provide context for measuring business events recorded in fact tables. While fact tables answer "how much," dimension tables answer "who, what, when, and where" questions. A product dimension describes what was sold (category, price, supplier). A customer dimension describes who bought it (segment, region, lifetime value). A date dimension describes when (month, quarter, fiscal period).
Dimensions are relatively small compared to facts. A product dimension might have millions of rows, a customer dimension hundreds of millions, but fact tables have billions. This size difference enables denormalization: storing all product attributes in one table avoids joins during analysis. Dimensions change slowly (slowly-changing dimensions), enabling straightforward versioning for historical accuracy.
Dimensions have hierarchies enabling drill-down analysis. A geographic dimension has continent, country, region, city relationships. Product dimensions have category, subcategory, brand relationships. Time dimensions have year, quarter, month, day hierarchies. These hierarchies are natural to business users and supported by BI tools, making dimensional schemas intuitive for analysis.
Key Characteristics
- ▶Store descriptive attributes for analytical filtering and grouping
- ▶Include hierarchies enabling drill-down analysis
- ▶Relatively small compared to fact tables (millions to billions of rows)
- ▶Denormalized to reduce query joins
- ▶Change slowly, enabling straightforward versioning
- ▶Support slicing and dicing of fact measures by dimension attributes
Why It Matters
- ▶Enable intuitive, business-friendly analysis of fact data
- ▶Support hierarchical drill-down from summary to detail
- ▶Simplify queries through denormalization eliminating joins
- ▶Enable consistent dimension definitions across organization
- ▶Support what-if analysis through slowly-changing dimension history
- ▶Facilitate BI tool integration with native hierarchy support
Example
` -- Example dimensions supporting a sales fact table -- Date dimension (enables temporal analysis) CREATE TABLE dim_date ( date_id INT PRIMARY KEY, calendar_date DATE, day_of_week VARCHAR(10), day_of_month INT, month INT, quarter INT, year INT, week_number INT, fiscal_month INT, fiscal_quarter INT, fiscal_year INT, is_weekend BOOLEAN, is_holiday BOOLEAN ); -- Product dimension (enables product analysis) CREATE TABLE dim_product ( product_id INT PRIMARY KEY, product_code VARCHAR(50), product_name VARCHAR(255), category VARCHAR(100), -- Hierarchy level 1 subcategory VARCHAR(100), -- Hierarchy level 2 brand VARCHAR(100), list_price DECIMAL(10, 2), current_price DECIMAL(10, 2), supplier_id INT, status VARCHAR(20) ); -- Customer dimension (enables customer analysis) CREATE TABLE dim_customer ( customer_id INT PRIMARY KEY, customer_code VARCHAR(50), customer_name VARCHAR(255), segment VARCHAR(50), -- Hierarchy level 1 subsegment VARCHAR(50), -- Hierarchy level 2 region VARCHAR(100), -- Geographic hierarchy country VARCHAR(100), state VARCHAR(100), city VARCHAR(100), lifetime_value DECIMAL(12, 2), tenure_months INT ); -- Store dimension (enables location analysis) CREATE TABLE dim_store ( store_id INT PRIMARY KEY, store_code VARCHAR(50), store_name VARCHAR(255), country VARCHAR(100), -- Hierarchy state VARCHAR(100), -- Hierarchy city VARCHAR(100), -- Hierarchy district_manager VARCHAR(100), region_manager VARCHAR(100), store_format VARCHAR(50), opening_date DATE ); -- Analytical queries use dimension attributes for filtering and grouping -- Drill-down: Revenue by category then by subcategory SELECT p.category, p.subcategory, SUM(f.revenue) as revenue FROM fct_sales f JOIN dim_product p ON f.product_id = p.product_id WHERE d.year = 2024 GROUP BY p.category, p.subcategory ORDER BY category, revenue DESC; -- Slicing: Compare segments for specific time period SELECT c.segment, c.region, COUNT(DISTINCT f.customer_id) as customers, SUM(f.revenue) as segment_revenue FROM fct_sales f JOIN dim_customer c ON f.customer_id = c.customer_id JOIN dim_date d ON f.date_id = d.date_id WHERE d.year = 2024 AND d.quarter = 2 GROUP BY c.segment, c.region; `
Coginiti Perspective
Coginiti's SMDL maps directly to dimensional modeling concepts. Dimension tables are represented as entities with dimensions typed as text, number, date, datetime, or bool, and relationships defined as one_to_one, one_to_many, or many_to_one to connect them to fact entities. Semantic SQL then uses these relationship definitions to generate correct joins automatically, so analysts query dimension attributes without writing explicit join logic. CoginitiScript publication can materialize dimension tables as Iceberg or standard tables across 24+ connected platforms.
Related Concepts
More in OLTP, OLAP & Workload Types
Analytical Workload
An analytical workload is a class of database queries that examine, aggregate, and analyze large volumes of historical data to extract business insights and support decision-making.
Fact Table
A fact table is a database table in a star or snowflake schema that stores measures (quantitative data) and foreign keys to dimensions, representing events or transactions in a business process.
HTAP (Hybrid Transactional/Analytical Processing)
HTAP is a database architecture that supports both transactional workloads and analytical workloads on the same data system, enabling real-time analytics without separate data warehouses.
Mixed Workload
A mixed workload is a database system handling both transactional and analytical queries simultaneously, requiring architecture balancing responsive operational performance with efficient aggregate analysis.
OLAP (Online Analytical Processing)
OLAP is a database workload class optimized for rapid execution of complex queries that aggregate and analyze large datasets across multiple dimensions.
OLTP (Online Transaction Processing)
OLTP is a database workload class optimized for rapid execution of small, focused transactions that insert, update, or query individual records in operational systems.
See Semantic Intelligence in Action
Coginiti operationalizes business meaning across your entire data estate.