In this lesson, you will learn how to design descriptive dimension tables to provide the essential "who, what, and where" context for your business metrics.
Why Context Matters
Imagine you have a sales_fact table containing only numbers like transaction_id, product_id, and amount. While these numbers are critical, they aren’t very useful on their own. If you want to know which Region sold the most Products during a Holiday Season, you need supplemental tables that "decorate" your metrics with descriptive attributes. These are your dimensions.
Designing the Dimension Table
A dimension table should be wide and descriptive. Unlike a fact table, which stores measurements, a dimension table stores the context. A well-structured dim_product table doesn't just store an ID; it stores the attributes you’ll use to group and filter your data.
Consider this example for a product dimension:
CREATE TABLE dim_product (
product_key INT PRIMARY KEY, -- Surrogate key
product_name VARCHAR(255), -- Descriptive attribute
category VARCHAR(100), -- Used for grouping
brand VARCHAR(100), -- Used for filtering
color VARCHAR(50), -- Additional context
is_active BOOLEAN -- Filter for current inventory
);
Best Practices for Structuring
When building these tables, keep these three principles in mind:
- Use Descriptive Attributes: If you have an attribute that you might want to slice your data by (like "Category" or "Region"), include it as a column.
- Keep it Human-Readable: Dimensions should use text-based labels rather than internal system codes (e.g., use "Electronics" instead of
cat_id_09). - Surrogate Keys: Always use a simple integer as a primary key (
product_key) rather than relying on natural source system keys. This keeps your dimension resilient if the source system changes its ID format.
By creating these descriptive tables, you transform a raw list of numbers into a dashboard that stakeholders can actually understand, allowing them to filter by category, group by brand, or drill down into specific product details.
Key Takeaway: Dimension tables act as the "adjectives" of your data model, providing the descriptive context necessary to transform raw measurements into meaningful business intelligence.