Fact vs. Dimension Tables — Distinguish fact tables vs dimension tables (conceptual)

The distinction between fact tables and dimension tables did not emerge with Power BI — it is rooted in decades of research on how organizations should structure data for analytical querying. In the 1960s and 1970s, relational database theory focused on online transaction processing (OLTP), where highly normalized schemas minimized redundancy at the expense of query complexity. As businesses accumulated vast repositories of historical data, a new paradigm was needed — one optimized not for writing individual transactions, but for reading and aggregating large volumes of records. This need gave rise to the field of dimensional modeling, which treats data as a combination of measurable events and the descriptive contexts surrounding them.

The central question that dimensional modeling answers is deceptively simple: how should we organize data so that analytical queries are both fast and intuitive? The answer hinges on cleanly separating quantitative measurements from the descriptive attributes that give those measurements meaning. This separation is the conceptual foundation we will explore throughout this lesson.

At its core, dimensional modeling divides every dataset into two categories of tables. A fact table records measurable events or transactions — the "what happened" of your business. Each row typically represents a single event such as a sale, a shipment, or a web click, and the table's numeric columns (called measures) are the values you aggregate in reports: revenue, quantity, duration. A dimension table, by contrast, stores the descriptive context — the "who, what, where, when, why, and how" that qualifies each event. Dimension tables contain textual or categorical attributes such as product name, customer region, or calendar month, which analysts use to slice, filter, and group the facts.

Observe the asymmetry between the two table types. The fact table is typically tall and narrow — it may contain millions or even billions of rows (one per transaction), but its column count is modest: mostly integer foreign keys and a handful of numeric measures. Dimension tables, by contrast, are wide and short — a Product dimension might have only 5,000 rows (one per distinct product) but 30 or more descriptive columns (name, category, subcategory, brand, color, weight, introduction date, and so on). This structural difference directly influences how Power BI's VertiPaq engine compresses and indexes each table, and it is the reason star schemas consistently outperform flat, denormalized tables in analytical workloads.

In Power BI, the relationship between a dimension table and a fact table is always a one-to-many (1:N) relationship where the dimension table sits on the "one" side (each row has a unique primary key) and the fact table sits on the "many" side (its foreign key column may repeat the same dimension key across thousands of rows). This relationship defines the filter propagation direction: by default, filters flow from the dimension side to the fact side. When a user selects "Electronics" in a slicer connected to the Product dimension, that filter propagates through the relationship to the fact table, restricting aggregations to only those rows where ProductKey matches an electronics product.

This unidirectional filter flow is not merely a UI convenience — it reflects a deep design principle. Because dimension tables have unique keys and fact tables have repeating keys, the engine can efficiently hash-join the filtered dimension keys against the fact table's compressed column segments. Bidirectional filtering (where the fact table can also filter a dimension table) is possible but should be used sparingly, as it can introduce ambiguity, degrade performance, and create circular dependency risks in more complex models.

Types of Fact Tables

Not all fact tables are created equal. The three canonical types — transaction facts, periodic snapshot facts, and accumulating snapshot facts — capture events at different temporal resolutions. A transaction fact table records each individual event (e.g., every line item in every order). A periodic snapshot captures the state of a measure at regular intervals (e.g., daily inventory levels). An accumulating snapshot tracks the lifecycle of a process across multiple milestones (e.g., an order moving through stages: placed → shipped → delivered → returned).

Characteristics of Dimension Tables

Dimension tables share several structural hallmarks. Each has a surrogate key — typically an integer primary key generated during the ETL process to uniquely identify each row. Dimension tables are denormalized: rather than splitting Product and ProductCategory into two normalized tables with a foreign key, you flatten them into one wide table so the BI engine can resolve attributes in a single lookup. This deliberate redundancy trades storage efficiency for query speed — a classic time–space trade-off that should feel familiar from algorithm design.

• Surrogate key: A synthetic integer primary key, independent of source system identifiers, enabling consistent joins and historical tracking.
• Natural key: The original business identifier (e.g., SKU or employee ID) retained as an attribute column for reference but not used as the join key.
• Descriptive attributes: Text or categorical columns (ProductName, Color, Size) used in slicers, axes, and legends of Power BI visuals.
• Hierarchies: Columns that form a drill-down path (e.g., Year → Quarter → Month → Day in a Date dimension).

Suppose you are given a flat CSV export from an e-commerce database containing the columns: OrderID, OrderDate, ProductName, Category, Subcategory, CustomerName, CustomerEmail, City, State, Country, Quantity, UnitPrice, Discount, TotalAmount. Your task is to decompose this into a proper star schema within Power BI.

The star schema is the simplest and most performant dimensional topology, but it is not the only one. As data models grow in complexity, two extensions arise. The snowflake schema normalizes dimension tables by splitting hierarchical attributes into sub-dimension tables (e.g., a Product dimension linked to a separate Category dimension). While this reduces storage via deduplication, it increases the number of joins required at query time and complicates the model for business users — Power BI's documentation explicitly recommends avoiding snowflaking in most scenarios. The galaxy schema (also called a fact constellation) involves multiple fact tables sharing conformed dimensions, which is essential when modeling complex business domains with several distinct processes (e.g., Sales facts and Inventory facts both referencing the same Product and Date dimensions).

Looking forward, as you progress into advanced data engineering and modeling, you will encounter concepts like slowly changing dimensions (SCDs) — strategies for handling dimension attribute changes over time (Type 1 overwrites, Type 2 adds versioned rows, Type 3 adds previous-value columns). You will also encounter role-playing dimensions where a single physical dimension table (like a Date table) participates in multiple relationships to the same fact table under different roles (OrderDate, ShipDate, DeliveryDate). These advanced patterns all build on the foundational distinction between facts and dimensions that this lesson has established.