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.
1.0.0Add 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
Generate SQL for fact and dimension tables.
Implement surrogate keys and handle Slowly Changing Dimensions (SCD Type 2).
Apply best practices for naming conventions, indexing, and data quality constraints.
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]_idor[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
- Grain Definition: Each fact table has a clearly defined, consistent grain
- Surrogate Keys: All dimension tables use integer surrogate keys
- Additive Measures: Fact tables primarily contain additive measures
- Rich Dimensions: Dimension tables contain descriptive attributes for filtering and grouping
- Conformed Dimensions: Shared dimensions are identical across fact tables
- SCD Implementation: Slowly changing dimensions are properly handled
- Referential Integrity: Foreign key relationships are enforced
- 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.