An outrigger dimension is a dimension that another dimension points at - a normalized branch off the star, where a foreign key sits in one dimension and references a second, shared dimension rather than the fact. It's a controlled, deliberate exception to the flat star schema's rule that dimensions don't join to each other. The classic case is a customer dimension that carries a date key for the customer's first-purchase date, pointing at the shared dim_date.

When it's acceptable

A pure star keeps every dimension denormalized and joined only to the fact. An outrigger snowflakes one branch on purpose, and it earns its place in a narrow set of cases: when the referenced dimension is a genuinely shared, conformed dimension - most often date or geography - that you don't want to copy into every dimension that needs it. Storing a customer's signup date as a foreign key to dim_date lets you describe that date with the same calendar attributes (fiscal period, day-of-week, holiday flag) the fact uses, without duplicating the calendar logic onto the customer dimension. The same applies to a store dimension referencing a shared geography dimension for its city and region attributes.

dim_customer (
  customer_key       INT,
  customer_name      VARCHAR,
  signup_date_key    INT,   -- outrigger FK to dim_date
  home_geography_key INT,   -- outrigger FK to dim_geography
  ...
)
dim_date      (date_key, full_date, fiscal_period, day_of_week, ...)
dim_geography (geography_key, city, region, country, ...)

The caveats

Outriggers buy reuse at the cost of an extra join and a more complex query, and they break the one-hop simplicity that makes star schemas easy to query and easy for BI tools to auto-generate joins from. Two rules keep them honest. First, the outrigger should point at a conformed dimension shared across the model - outriggering to a one-off table is just snowflaking with no payoff. Second, keep the chain shallow: a dimension referencing one outrigger is fine, an outrigger that references another outrigger that references another is the snowflake sprawl the star was meant to avoid. When a dimension needs only one or two attributes from another, denormalizing those attributes directly into the dimension is often the better trade than an outrigger join. Outriggers also relate to conformed dimensions, since the table on the far side of the outrigger is precisely a conformed dimension being reused.

Frequently asked questions

What is an outrigger dimension? A dimension referenced by another dimension via a foreign key - a normalized branch off the star - rather than referenced directly by the fact. The customer dimension pointing at the shared date dimension for a signup date is the standard example.

When is it acceptable? When the referenced table is a genuinely shared, conformed dimension (typically date or geography) that you'd otherwise have to duplicate into multiple dimensions. The reuse is the justification.

What are the caveats? Outriggers add a join and reduce star simplicity. Keep the chain shallow (no outriggers pointing at outriggers), and only outrigger to conformed dimensions; for one or two attributes, denormalize them into the dimension instead.

How is it different from snowflaking? Snowflaking normalizes a dimension's attributes into chained sub-tables as a general design choice. An outrigger is the deliberate, limited use of that pattern to point at a single shared conformed dimension.