참고 답변
A star schema consists of a central fact table surrounded by dimension tables.
The fact table contains measurable business events, for example, Fact_Sales with columns like OrderID, ProductKey, CustomerKey, DateKey, Quantity, and Revenue.
Dimension tables contain descriptive attributes. For example:
- Dim_Product with product name, category, brand
- Dim_Customer with customer name, region, segment
- Dim_Date with date, month, quarter, year
Each dimension table connects to the fact table using a one-to-many relationship. The dimension side has unique keys, and the fact table contains foreign keys.
I always configure relationships as single-directional from dimension to fact. This ensures predictable filter flow. Bi-directional filters can create ambiguity and unexpected results in DAX, especially in complex models.
I avoid snowflaking dimensions, meaning I don't normalize dimension tables into multiple smaller related tables. Keeping dimensions denormalized improves performance and simplifies reporting.
A dedicated Date dimension is essential. It should contain continuous dates without gaps and include columns like Year, Quarter, Month, Week, etc. I mark it as the official Date Table in Power BI to enable time intelligence functions.
In some cases, I use role-playing dimensions. For example, a sales table may have both Order Date and Ship Date. The same Date table can connect to both, but only one relationship can be active at a time. I handle the second relationship using USERELATIONSHIP in DAX.
Star schema benefits include better compression in the VertiPaq engine, simpler DAX calculations, and consistent filtering behavior.