Glossary/OLTP, OLAP & Workload Types

Star Schema

A star schema is a data warehouse design pattern that organizes data into a central fact table containing measures and foreign keys to surrounding dimension tables containing attributes.

Star schemas solve the complexity of analyzing multi-dimensional data by separating measures (what we count) from dimensions (how we slice). The fact table stores events or transactions: each row records an occurrence like a sale, with foreign keys pointing to dimensions (which product, customer, date). Dimension tables store attributes: products have category and price, customers have region and segment.

This structure simplifies querying and accelerates performance. Joining facts to one or few dimensions is fast. Aggregating facts by dimension attributes is straightforward. Analysts naturally think in dimensions (analyze revenue by region, product, time) matching the schema structure. The approach denormalizes dimensions, storing redundant attributes to avoid multi-level joins.

Star schemas emerged as the standard for data warehouse design because they balance performance and usability. Queries are readable, optimization is straightforward, and performance is predictable. Contrast with normalized schemas (snowflake) requiring multiple joins, or denormalized designs without clear structure. Most BI tools provide native support for star schema structures, auto-generating dimensions, hierarchies, and aggregates.

Key Characteristics

  • Central fact table containing measures and foreign keys
  • Dimension tables containing attributes for analysis
  • Denormalized dimensions avoiding multi-level joins
  • Simple, predictable join patterns
  • Natural alignment with analytical query patterns
  • Hierarchical attributes enabling drill-down analysis

Why It Matters

  • Dramatically simplify analytical queries compared to normalized schemas
  • Improve query performance through reduced joins and clear optimization paths
  • Enable business users to understand schema structure intuitively
  • Support hierarchical analysis (drill-down from region to store)
  • Facilitate BI tool integration and automatic metric generation
  • Reduce development time by following established patterns

Example

`
-- Star schema structure

-- Fact Table: Sales (contains measures and foreign keys)
CREATE TABLE fct_sales (
  sale_id BIGINT PRIMARY KEY,
  date_id INT NOT NULL,
  product_id INT NOT NULL,
  customer_id INT NOT NULL,
  store_id INT NOT NULL,
  revenue DECIMAL(10, 2),
  quantity INT,
  discount DECIMAL(5, 2),
  FOREIGN KEY (date_id) REFERENCES dim_date,
  FOREIGN KEY (product_id) REFERENCES dim_product,
  FOREIGN KEY (customer_id) REFERENCES dim_customer,
  FOREIGN KEY (store_id) REFERENCES dim_store
);

-- Dimension Tables (contain attributes for analysis)
CREATE TABLE dim_date (
  date_id INT PRIMARY KEY,
  calendar_date DATE,
  year INT,
  quarter INT,
  month INT,
  day_of_week VARCHAR(10),
  is_holiday BOOLEAN
);

CREATE TABLE dim_product (
  product_id INT PRIMARY KEY,
  product_name VARCHAR(255),
  category VARCHAR(100),
  subcategory VARCHAR(100),
  price DECIMAL(10, 2)
);

CREATE TABLE dim_customer (
  customer_id INT PRIMARY KEY,
  customer_name VARCHAR(255),
  segment VARCHAR(50),
  region VARCHAR(50),
  lifetime_value DECIMAL(12, 2)
);

-- Simple analytical query using star schema
SELECT 
  d.year,
  d.quarter,
  p.category,
  c.region,
  SUM(f.revenue) as total_revenue,
  SUM(f.quantity) as units_sold,
  COUNT(*) as transaction_count
FROM fct_sales f
JOIN dim_date d ON f.date_id = d.date_id
JOIN dim_product p ON f.product_id = p.product_id
JOIN dim_customer c ON f.customer_id = c.customer_id
WHERE d.year = 2024
GROUP BY d.year, d.quarter, p.category, c.region;
`

Coginiti Perspective

Coginiti's SMDL aligns naturally with star schema design. Fact tables are modeled as entities with measures (sum, count_distinct, avg, and 9 other aggregation types), while dimension tables become entities with typed dimensions and defined relationships. Semantic SQL uses these relationships to generate joins implicitly, so analysts work with star schema data without writing join syntax. CoginitiScript pipelines can build and maintain star schemas across platforms through publication, with incremental strategies keeping fact tables current without full reloads.

See Semantic Intelligence in Action

Coginiti operationalizes business meaning across your entire data estate.