star schema and dimensional modelling.

Where star schema and dimensional modelling fits on a long engagement.

Denormalising dimensions is a deliberate trade. Storage is repeated, which costs almost nothing in a columnar warehouse, in exchange for fewer joins, simpler queries and better optimiser behaviour. The instinct to normalise is correct for transactional systems and wrong here.

Snowflaking — normalising dimensions into further tables — is usually a mistake made for tidiness. It adds joins to every query and complexity to every analyst's mental model, and it saves storage that was not scarce. There are narrow cases where it is right, and they are narrower than the frequency with which it appears.

What an assigned team does with star schema and dimensional modelling.

Slowly changing dimensions are the part that requires an actual decision from the business. Whether historical facts should reflect the customer's segment at the time or their current segment is not a technical question, and both answers are correct for different reporting purposes.

Getting that stated explicitly rather than inferred from an implementation is what prevents a whole class of later argument, and it is settled at scoping as part of how the monthly fee is built.

What we use star schema and dimensional modelling for.

• Queries an analyst writes without help A fact joined directly to its dimensions, with no intermediate tables to learn.
• Optimiser-friendly shape A layout warehouse engines plan well, rather than a normalised graph they struggle with.
• History handled by explicit decision A stated rule on whether facts carry attributes as they were or as they are.

How star schema and dimensional modelling capacity is assigned.

Schema design is assigned inside data engineering capacity, with history-handling decisions taken by the business and implemented rather than assumed.