A dimension table holds descriptive properties of a business entity, such as a customer or user. In a star schema, it connects to a central fact table: facts record business events or actions, while dimensions describe attributes relevant to analyzing them. section 11.4.2 section 11.5
A useful dimension brings together properties that analysts would otherwise retrieve through repeated joins or calculations. These may come from multiple source tables or be derived or aggregated. Choose them around the questions stakeholders ask, not simply by reversing a normalized schema. Make the resulting columns readable and clear. section 11.4.2 section 11.5
A users dimension
A users dimension can combine activity, preference, behavior, and location properties in one table. In one implementation, analysts reviewed more than 20 columns, including cleaned text fields that had previously needed manual editing. Documentation recorded each column’s meaning, sources, and transformations, alongside sample queries and an update process. section 11.4.1
Figure 11.21 Star schemas have fact tables at the center connected to dimensions with related attributes.
The diagram shows where dimensions sit in relation to the central fact table of a star schema. section 11.4.2
To plan a dimension, identify the business entities in the available tables, then identify the events that belong in fact tables. Check how the tables connect through their keys, and review the proposed properties with analysts and stakeholders. A dimension saves work only when its contents match the analyses people need. section 11.4.3 section 11.4.2
