419 lines
7.8 KiB
Markdown
419 lines
7.8 KiB
Markdown
## Definition
|
|
|
|
A **Dimension Table** contains descriptive information that provides **context** for the events and measurements stored in a [[Fact Table]].
|
|
|
|
If a Fact Table tells us:
|
|
|
|
> **What happened?**
|
|
|
|
Dimension Tables help answer:
|
|
|
|
> **Who? What? Where? When? How?**
|
|
|
|
Examples include:
|
|
|
|
- Content
|
|
- Customer
|
|
- User
|
|
- Product
|
|
- Platform
|
|
- Device
|
|
- Geography
|
|
- Date
|
|
|
|
---
|
|
|
|
## Simple Mental Model
|
|
|
|
Think:
|
|
|
|
> **Fact = What happened?**
|
|
|
|
> **Dimension = Describe what happened.**
|
|
|
|
If the Fact Table says:
|
|
|
|
> A viewing event lasted 125 seconds.
|
|
|
|
Dimensions tell us:
|
|
|
|
> **Who:** User 7821
|
|
> **What:** Episode 1 of Show A
|
|
> **When:** July 19, 2026
|
|
> **Where/How:** Roku
|
|
|
|
Together, Facts and Dimensions turn an event into something the business can analyze.
|
|
|
|
---
|
|
|
|
## How It Works
|
|
|
|
Imagine a [[Fact Table]] called:
|
|
|
|
`fact_viewing`
|
|
|
|
It contains:
|
|
|
|
|content_id|platform_id|date_id|watch_seconds|
|
|
|---|---|---|---|
|
|
|501|3|20260719|125|
|
|
|
|
The Fact Table knows:
|
|
|
|
`content_id = 501`
|
|
|
|
But `501` doesn't mean anything useful to a business user.
|
|
|
|
A Dimension Table called:
|
|
|
|
`dim_content`
|
|
|
|
could contain:
|
|
|
|
|content_id|title|series|genre|language|
|
|
|---|---|---|---|---|
|
|
|501|Episode 1|Show A|Drama|French|
|
|
|
|
Now we know what Content 501 represents.
|
|
|
|
Instead of storing:
|
|
|
|
`Episode 1 / Show A / Drama / French`
|
|
|
|
inside every viewing event, the Fact Table stores the key:
|
|
|
|
`501`
|
|
|
|
and connects it to `dim_content`.
|
|
|
|
---
|
|
|
|
## Example
|
|
|
|
Consider another Dimension Table:
|
|
|
|
`dim_platform`
|
|
|
|
|platform_id|platform|device_type|
|
|
|---|---|---|
|
|
|1|Web|Desktop|
|
|
|2|iOS|Mobile|
|
|
|3|Roku|OTT|
|
|
|4|Android TV|OTT|
|
|
|
|
The [[Fact Table]] contains:
|
|
|
|
`platform_id = 3`
|
|
|
|
The Dimension Table tells us:
|
|
|
|
`3 = Roku`
|
|
|
|
Now the business can ask:
|
|
|
|
> How many hours were watched on Roku?
|
|
|
|
Or:
|
|
|
|
> How does OTT viewing compare with mobile viewing?
|
|
|
|
The Fact Table provides the measurable event.
|
|
|
|
The Dimension Table provides the context needed to group and analyze those events.
|
|
|
|
---
|
|
|
|
## The Date Dimension
|
|
|
|
One of the most common Dimension Tables is:
|
|
|
|
`dim_date`
|
|
|
|
It might contain:
|
|
|
|
|date_id|date|day|month|quarter|year|weekend|
|
|
|---|---|---|---|---|---|---|
|
|
|20260719|2026-07-19|Sunday|July|Q3|2026|Yes|
|
|
|
|
You might wonder why an entire table is needed just for dates.
|
|
|
|
A Date Dimension makes it easier to analyze data by:
|
|
|
|
- Day
|
|
- Week
|
|
- Month
|
|
- Quarter
|
|
- Year
|
|
- Weekend vs weekday
|
|
|
|
Organizations can also add business-specific calendars:
|
|
|
|
- Fiscal year
|
|
- Fiscal quarter
|
|
- Broadcast season
|
|
- Programming season
|
|
|
|
This allows consistent time-based analysis across multiple [[Fact Table|Fact Tables]].
|
|
|
|
---
|
|
|
|
## Natural Keys and Surrogate Keys
|
|
|
|
Dimension Tables commonly introduce the distinction between a [[Natural Key]] and a [[Surrogate Key]].
|
|
|
|
A Natural Key comes from the business or source system.
|
|
|
|
Examples:
|
|
|
|
- Employee number
|
|
- Product SKU
|
|
- ISBN
|
|
- External content ID
|
|
|
|
A Surrogate Key is generated internally by the data platform.
|
|
|
|
For example:
|
|
|
|
`content_key = 501`
|
|
|
|
The number `501` may have no business meaning.
|
|
|
|
A Dimension Table could contain:
|
|
|
|
|content_key|jwplayer_id|title|
|
|
|---|---|---|
|
|
|501|abc123|Show A|
|
|
|
|
Here:
|
|
|
|
`content_key = 501`
|
|
|
|
is the [[Surrogate Key]].
|
|
|
|
`jwplayer_id = abc123`
|
|
|
|
is the source identifier and could potentially act as a [[Natural Key]].
|
|
|
|
Surrogate Keys are useful because source systems can change.
|
|
|
|
For example, a company might use:
|
|
|
|
JW Player → New Video Platform
|
|
|
|
The analytical data model can maintain its own internal identifiers rather than making its entire structure dependent on identifiers controlled by an external vendor.
|
|
|
|
This concept becomes particularly important when studying [[Slowly Changing Dimensions]].
|
|
|
|
---
|
|
|
|
## How It Fits Into the Bigger Picture
|
|
|
|
A simplified architecture could look like:
|
|
|
|
Sources
|
|
↓
|
|
[[ETL vs ELT]]
|
|
↓
|
|
[[Medallion Architecture]]
|
|
↓
|
|
Bronze
|
|
↓
|
|
Silver
|
|
↓
|
|
Gold
|
|
↓
|
|
[[Fact Table]] + Dimension Tables
|
|
↓
|
|
[[Star Schema]]
|
|
↓
|
|
[[Semantic Layer]]
|
|
↓
|
|
Power BI
|
|
|
|
Dimension Tables make analytical data easier for humans and BI tools to understand.
|
|
|
|
Instead of analyzing meaningless IDs, users can analyze:
|
|
|
|
- Show title
|
|
- Genre
|
|
- Platform
|
|
- Device
|
|
- Country
|
|
- Month
|
|
|
|
This is one of the ways raw technical data becomes **business-ready information**.
|
|
|
|
---
|
|
|
|
## My Company / Real-World Context
|
|
|
|
For a media company, useful Dimension Tables might include:
|
|
|
|
`dim_content`
|
|
|
|
Describes:
|
|
|
|
- Program
|
|
- Episode
|
|
- Series
|
|
- Genre
|
|
- Language
|
|
|
|
`dim_platform`
|
|
|
|
Describes:
|
|
|
|
- Web
|
|
- Mobile
|
|
- Roku
|
|
- Apple TV
|
|
- Android TV
|
|
|
|
`dim_device`
|
|
|
|
Describes:
|
|
|
|
- Desktop
|
|
- Mobile
|
|
- Tablet
|
|
- Connected TV
|
|
|
|
`dim_date`
|
|
|
|
Describes:
|
|
|
|
- Day
|
|
- Month
|
|
- Quarter
|
|
- Year
|
|
- Broadcast season
|
|
|
|
These dimensions could connect to a [[Fact Table]] such as:
|
|
|
|
`fact_viewing`
|
|
|
|
allowing Power BI users to analyze:
|
|
|
|
> Watch hours **by platform**
|
|
|
|
> Unique viewers **by content**
|
|
|
|
> Viewing sessions **by month**
|
|
|
|
> Engagement **by device**
|
|
|
|
The Fact Table provides the number.
|
|
|
|
The Dimension Table provides the **"by what?"**
|
|
|
|
---
|
|
|
|
## CTO Perspective
|
|
|
|
Dimension Tables may look like a technical modeling detail, but they have important governance implications.
|
|
|
|
Imagine one system says:
|
|
|
|
`French`
|
|
|
|
another says:
|
|
|
|
`FR`
|
|
|
|
and another says:
|
|
|
|
`fr_CA`
|
|
|
|
If every Power BI report handles these independently, the organization can end up with inconsistent results.
|
|
|
|
A governed Dimension Table can establish a standardized representation.
|
|
|
|
The same applies to:
|
|
|
|
- Content categories
|
|
- Platforms
|
|
- Departments
|
|
- Regions
|
|
- Products
|
|
- Customer segments
|
|
|
|
Dimension Tables can therefore become an important part of [[Data Governance]] because they help establish shared business definitions and classifications.
|
|
|
|
A CTO should care less about personally designing `dim_platform` and more about ensuring the organization has **consistent definitions across systems and reports**.
|
|
|
|
---
|
|
|
|
### Questions to Ask
|
|
|
|
- What business entity does this Dimension Table represent?
|
|
- What attributes describe it?
|
|
- What is its [[Natural Key]]?
|
|
- Does it use a [[Surrogate Key]]?
|
|
- Which source systems feed this dimension?
|
|
- How are conflicting source values standardized?
|
|
- Who owns the business definition?
|
|
- How are historical changes handled?
|
|
- Is this dimension shared across multiple [[Fact Table|Fact Tables]]?
|
|
- Are Power BI reports using the same governed dimensions?
|
|
|
|
---
|
|
|
|
## Meeting Scenario
|
|
|
|
**Situation:**
|
|
|
|
Two Power BI reports show different viewing totals by platform.
|
|
|
|
One report categorizes:
|
|
|
|
`Roku → Connected TV`
|
|
|
|
while another categorizes:
|
|
|
|
`Roku → OTT`
|
|
|
|
The teams are debating which report is correct.
|
|
|
|
**Possible response:**
|
|
|
|
> "It sounds like the issue isn't necessarily with the viewing data itself, but with how we're classifying platforms. Before changing either report, can we confirm whether we have a governed platform dimension and agree on the business classification we want to use?"
|
|
|
|
You could then add:
|
|
|
|
> "Once that definition is established centrally, both reports should consume the same classification rather than maintaining separate platform mappings."
|
|
|
|
This moves the discussion from:
|
|
|
|
> Which analyst has the correct Power BI report?
|
|
|
|
to:
|
|
|
|
> What is our organization's governed definition?
|
|
|
|
That's a [[Data Governance]] problem rather than simply a reporting problem.
|
|
|
|
---
|
|
|
|
## Key Takeaways
|
|
|
|
- A **Dimension Table** provides descriptive context for a [[Fact Table]].
|
|
- Facts answer **what happened**; dimensions answer **who, what, where, when, and how**.
|
|
- Dimensions allow data to be grouped and analyzed using business-friendly attributes.
|
|
- [[Natural Key|Natural Keys]] usually originate from business or source systems.
|
|
- [[Surrogate Key|Surrogate Keys]] are internally generated identifiers.
|
|
- Governed dimensions help create consistent definitions across reports and systems.
|
|
- Fact Tables and Dimension Tables commonly come together in a [[Star Schema]].
|
|
|
|
## Related Concepts
|
|
|
|
- [[Fact Table]]
|
|
- [[Grain]]
|
|
- [[Measure]]
|
|
- [[Natural Key]]
|
|
- [[Surrogate Key]]
|
|
- [[Slowly Changing Dimensions]]
|
|
- [[Star Schema]]
|
|
- [[Medallion Architecture]]
|
|
- [[Data Warehouse]]
|
|
- [[Data Governance]]
|
|
- [[Semantic Layer]] |