vault backup: 2026-07-19 16:34:17
This commit is contained in:
@@ -0,0 +1,419 @@
|
||||
## 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]]
|
||||
Reference in New Issue
Block a user