Course contentsShow
← Databases & SQL
Lesson 1801 of 1,95317. Analytics and Data PipelinesFree lesson

Dimensional Modeling Fundamentals

Translate complex business processes into star schemas using fact and dimension tables.

In this lesson, you will learn how to translate complex business processes into structured star schemas to facilitate high-performance analytical queries.

From Process to Star Schema

Dimensional modeling is the art of organizing data into a "star schema," consisting of a central Fact Table surrounded by de-normalized Dimension Tables. While operational databases (OLTP) prioritize transactional integrity through normalization, analytical databases (OLAP) prioritize query speed and intuitive data navigation.

To translate a business process—such as a "Product Sale"—into a star schema, we follow a two-step classification:

  1. Identify the Fact: A fact table stores quantitative metrics (measures) of a process, such as quantity_sold, discount_amount, or total_price. Each row in a fact table represents a specific event or grain, usually linked by surrogate keys to the dimensions.
  2. Identify the Dimensions: These are the "context" descriptors of your event. If the process is a sale, the dimensions are the Who (Customer), What (Product), Where (Store), and When (Date).

The Structural Layout

Unlike normalized tables, dimensions are kept wide to minimize joins. Instead of joining through multiple categories to find a product name, you keep product_name, brand, and category in one dim_product table.

-- Fact Table: Grain is one line item per transaction
CREATE TABLE fact_sales (
    date_key INT,
    product_key INT,
    store_key INT,
    customer_key INT,
    quantity_sold INT,
    total_amount DECIMAL(18, 2)
);

-- Dimension Table: De-normalized context
CREATE TABLE dim_product (
    product_key INT PRIMARY KEY,
    product_name VARCHAR(255),
    brand_name VARCHAR(100),
    category_name VARCHAR(100)
);

Why this works

By creating a star schema, you enable your business intelligence tools to generate SQL that performs simple, predictable joins. Because your dimensions are de-normalized, you avoid the "join explosion" that occurs in highly relational systems, allowing the database engine to aggregate billions of rows of facts efficiently. As you build your data pipelines, think of your transformation logic as the mechanism that populates these tables by enriching events with contextual metadata at the moment of ingestion.

Key Takeaway: Dimensional modeling transforms raw, transactional event data into a business-centric star schema by separating quantitative facts from the qualitative dimensions that provide context.