Comparison
Bridge tablevsFan trap
Bridge table
a bank account has three owners, so you cannot put an owner key on the fact without triple-counting the balance.
An intermediate table resolving a many-to-many relationship between a fact and a dimension, often carrying an allocation weight. It is the honest way to model shared ownership, multi-valued attributes and hierarchies of variable depth. It is also a fan trap with a licence, so it usually ships with a weighting column precisely so that sums can be made to add up to a hundred percent.
Full entry →Fan trap
you joined two fact tables at different grains and every revenue figure quietly doubled.
A join that multiplies rows because one side has several matches per key, inflating any measure summed afterwards. It is grain error made visible, and it is the single most common way a correct-looking SQL query returns a wrong number. The safe patterns are to aggregate one side to the join grain first, or to keep the two measures in separate queries and union them, rather than trusting a distinct.
Full entry →