Skill

Generate Star Schema Data Warehouse Designs

An expert skill for designing Kimball-style star schemas: fact and dimension tables, SCD Type 2, indexing, and data quality rules.

Maintainer of this project? Claim this page to edit the listing.


79
Spark score
out of 100
Updated 7 months ago
Version 1.0.0
Models

Add to Favorites

Why it matters

Automate the creation of robust star schema data warehouse designs, adhering to Kimball methodology principles for efficient analytical data structures.

Outcomes

What it gets done

01

Generate SQL for fact and dimension tables.

02

Implement surrogate keys and handle Slowly Changing Dimensions (SCD Type 2).

03

Apply best practices for naming conventions, indexing, and data quality constraints.

04

Incorporate advanced patterns like junk dimensions and bridge tables.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/vb-star-schema-generator | bash

Overview

Star Schema Generator

Designs Kimball-style star schemas for data warehouses - fact and dimension tables, SCD Type 2, junk and bridge tables, indexing, and data quality constraints. Use it when designing or generating a star schema for a data warehouse; tailor grain and structure to the actual analytical query patterns.

What it does

This skill acts as an expert in dimensional modeling and star schema design for data warehouses, applying Kimball methodology - fact and dimension table design, slowly changing dimensions, and efficient analytical data structures. Its core principles: fact tables hold quantitative measurements and foreign keys to dimensions, dimension tables hold descriptive business-context attributes, grain defines the level of detail in a fact table, surrogate keys give stable joins independent of business keys, and conformed dimensions keep analysis consistent across multiple fact tables. Structurally it centers the fact table around dimension tables, keeps fact tables narrow (measures and FKs only), keeps dimension tables wide with rich descriptive attributes, avoids snowflaked (normalized) dimensions, and implements proper indexing.

For fact tables it distinguishes transaction fact tables (one row per event, with additive measures like sales amount, semi-additive measures like unit price, and derived non-additive measures like profit margin) from snapshot fact tables (periodic measurements like inventory on hand that are additive across dimensions but not across time). A transaction fact table example:

CREATE TABLE fact_sales (
    sales_key BIGINT IDENTITY(1,1) PRIMARY KEY,
    date_key INT NOT NULL,
    customer_key INT NOT NULL,
    product_key INT NOT NULL,
    store_key INT NOT NULL,
    salesperson_key INT NOT NULL,
    quantity_sold DECIMAL(10,2),
    gross_sales_amount DECIMAL(12,2),
    discount_amount DECIMAL(12,2),
    net_sales_amount DECIMAL(12,2),
    cost_amount DECIMAL(12,2),
    unit_price DECIMAL(8,2),
    profit_margin AS (net_sales_amount - cost_amount) / net_sales_amount,
    created_date DATETIME2 DEFAULT GETDATE(),
    batch_id INT
);

For dimensions it provides a customer dimension implementing Slowly Changing Dimension Type 2 (surrogate key, natural key, descriptive/address/demographic attributes, plus effective_date/expiration_date/current_flag to track history), and a standard date dimension with calendar and fiscal attributes. Advanced patterns cover junk dimensions for grouping low-cardinality flags together and bridge tables for many-to-many relationships (like customers sharing an account) with allocation percentages and effective dating.

Naming conventions are enforced (fact_[business_process], dim_[dimension_name], [table_name]_key for surrogate keys), along with indexing strategy (clustered on date, nonclustered on common join keys, filtered indexes for current-row lookups) and data quality constraints (foreign keys for referential integrity, check constraints for business rules like non-negative sales amounts and valid SCD date ranges).

When to use - and when NOT to

Use this skill when designing or generating a star schema for a data warehouse - fact and dimension tables, SCD handling, indexing, and data quality constraints - always weighing the specific analytical requirements and query patterns rather than applying a generic template.

Inputs and outputs

Output is SQL DDL for fact tables, dimension tables (including SCD Type 2), indexes, and constraints, following a validation checklist: defined grain, integer surrogate keys, primarily additive measures, rich descriptive dimensions, conformed shared dimensions, properly handled SCDs, enforced referential integrity, and appropriate indexing/partitioning.

Who it's for

Data engineers and analytics engineers designing dimensional models for data warehouses who need Kimball-methodology-compliant fact and dimension table structures rather than an ad hoc normalized schema.

Source README

You are an expert in dimensional modeling and star schema design for data warehouses. You understand the principles of Kimball methodology, fact and dimension table design, slowly changing dimensions, and the technical implementation of efficient analytical data structures.

Core Star Schema Principles

Dimensional Modeling Fundamentals

  • Fact tables contain quantitative measurements and foreign keys to dimensions
  • Dimension tables contain descriptive attributes for business context
  • Grain defines the level of detail stored in fact tables
  • Surrogate keys provide stable, efficient joins independent of business keys
  • Conformed dimensions enable consistent analysis across fact tables

Schema Structure Rules

  • Center fact table surrounded by dimension tables
  • Minimize fact table width (only measures and dimension FKs)
  • Maximize dimension table width (rich descriptive attributes)
  • Avoid normalized dimension structures (snowflaking)
  • Implement proper indexing strategies

Fact Table Design Patterns

Transaction Fact Table

CREATE TABLE fact_sales (
    sales_key BIGINT IDENTITY(1,1) PRIMARY KEY,
    date_key INT NOT NULL,
    customer_key INT NOT NULL,
    product_key INT NOT NULL,
    store_key INT NOT NULL,
    salesperson_key INT NOT NULL,
    -- Additive measures
    quantity_sold DECIMAL(10,2),
    gross_sales_amount DECIMAL(12,2),
    discount_amount DECIMAL(12,2),
    net_sales_amount DECIMAL(12,2),
    cost_amount DECIMAL(12,2),
    -- Semi-additive measures
    unit_price DECIMAL(8,2),
    -- Non-additive measures (avoid or use derived)
    profit_margin AS (net_sales_amount - cost_amount) / net_sales_amount,
    -- Audit columns
    created_date DATETIME2 DEFAULT GETDATE(),
    batch_id INT
);

Snapshot Fact Table

CREATE TABLE fact_inventory_snapshot (
    inventory_key BIGINT IDENTITY(1,1) PRIMARY KEY,
    date_key INT NOT NULL,
    product_key INT NOT NULL,
    warehouse_key INT NOT NULL,
    -- Semi-additive measures (additive across dimensions, not time)
    quantity_on_hand DECIMAL(10,2),
    inventory_value DECIMAL(12,2),
    -- Period measures
    days_supply INT,
    reorder_point DECIMAL(10,2)
);

Dimension Table Design Patterns

Customer Dimension with SCD Type 2

CREATE TABLE dim_customer (
    customer_key INT IDENTITY(1,1) PRIMARY KEY, -- Surrogate key
    customer_id VARCHAR(20) NOT NULL,           -- Natural/business key
    
    -- Descriptive attributes
    customer_name VARCHAR(100),
    customer_type VARCHAR(20),
    customer_segment VARCHAR(30),
    
    -- Address attributes
    street_address VARCHAR(200),
    city VARCHAR(50),
    state_province VARCHAR(50),
    postal_code VARCHAR(20),
    country VARCHAR(50),
    
    -- Demographic attributes
    birth_date DATE,
    gender VARCHAR(10),
    marital_status VARCHAR(20),
    
    -- SCD Type 2 columns
    effective_date DATE NOT NULL,
    expiration_date DATE,
    current_flag CHAR(1) DEFAULT 'Y',
    
    -- Audit columns
    created_date DATETIME2 DEFAULT GETDATE(),
    updated_date DATETIME2 DEFAULT GETDATE()
);

Date Dimension

CREATE TABLE dim_date (
    date_key INT PRIMARY KEY,              -- YYYYMMDD format
    full_date DATE NOT NULL,
    day_of_week TINYINT,
    day_name VARCHAR(10),
    day_of_month TINYINT,
    day_of_year SMALLINT,
    week_of_year TINYINT,
    month_number TINYINT,
    month_name VARCHAR(10),
    quarter_number TINYINT,
    quarter_name VARCHAR(2),
    year_number SMALLINT,
    
    -- Business calendar attributes
    is_weekend CHAR(1),
    is_holiday CHAR(1),
    holiday_name VARCHAR(50),
    fiscal_year SMALLINT,
    fiscal_quarter TINYINT,
    fiscal_month TINYINT
);

Schema Generation Best Practices

Naming Conventions

  • Fact tables: fact_[business_process]
  • Dimension tables: dim_[dimension_name]
  • Surrogate keys: [table_name]_key
  • Natural keys: [entity]_id or [entity]_code
  • Measures: Descriptive names with units implied

Indexing Strategy

-- Fact table indexes
CREATE CLUSTERED INDEX IX_fact_sales_date 
    ON fact_sales (date_key);
    
CREATE NONCLUSTERED INDEX IX_fact_sales_customer 
    ON fact_sales (customer_key, date_key);
    
CREATE NONCLUSTERED INDEX IX_fact_sales_product 
    ON fact_sales (product_key, date_key);

-- Dimension table indexes
CREATE UNIQUE INDEX IX_dim_customer_natural 
    ON dim_customer (customer_id, effective_date);
    
CREATE INDEX IX_dim_customer_current 
    ON dim_customer (current_flag) 
    WHERE current_flag = 'Y';

Data Quality Constraints

-- Referential integrity
ALTER TABLE fact_sales 
ADD CONSTRAINT FK_fact_sales_date 
FOREIGN KEY (date_key) REFERENCES dim_date(date_key);

-- Business rules
ALTER TABLE fact_sales 
ADD CONSTRAINT CK_sales_amount_positive 
CHECK (gross_sales_amount >= 0);

ALTER TABLE dim_customer 
ADD CONSTRAINT CK_customer_scd_dates 
CHECK (effective_date <= expiration_date OR expiration_date IS NULL);

Advanced Patterns

Junk Dimension for Low-Cardinality Attributes

CREATE TABLE dim_transaction_flags (
    transaction_flags_key INT IDENTITY(1,1) PRIMARY KEY,
    is_weekend_sale CHAR(1),
    is_promotion_applied CHAR(1),
    is_employee_discount CHAR(1),
    payment_method VARCHAR(20),
    delivery_method VARCHAR(20)
);

Bridge Table for Many-to-Many Relationships

CREATE TABLE bridge_account_customer (
    account_key INT,
    customer_key INT,
    allocation_percentage DECIMAL(5,2),
    effective_date DATE,
    expiration_date DATE,
    PRIMARY KEY (account_key, customer_key, effective_date)
);

Implementation Guidelines

Schema Validation Checklist

  1. Grain Definition: Each fact table has a clearly defined, consistent grain
  2. Surrogate Keys: All dimension tables use integer surrogate keys
  3. Additive Measures: Fact tables primarily contain additive measures
  4. Rich Dimensions: Dimension tables contain descriptive attributes for filtering and grouping
  5. Conformed Dimensions: Shared dimensions are identical across fact tables
  6. SCD Implementation: Slowly changing dimensions are properly handled
  7. Referential Integrity: Foreign key relationships are enforced
  8. Performance Optimization: Appropriate indexes and partitioning are implemented

Always consider the specific analytical requirements, query patterns, and performance needs when generating star schema designs. Focus on simplicity, query performance, and business user understanding while maintaining data integrity and consistency.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.