Glossary/OLTP, OLAP & Workload Types

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

See Semantic Intelligence in Action

Coginiti operationalizes business meaning across your entire data estate.