According to Kimball:


A dimension can contain a reference to another dimension table. For instance, a bank account dimension can reference a separate dimension representing the date the account was opened.

This suggests to me you'd be able to just query the Account dimension directly if you wanted to track number of accounts opened over time, for example. Is this common?

In my case, I'm modeling Customer as a dimension, which also references Date (for Signed Up Date) and Demographic dimensions.

A common kind of query the business ask is how many signups we've had over time by demographic, for example. This doesn't involve a fact table at all. All this can be worked out by summarizing the dimension itself. Does this indicate some kind of a smell in the schema design, or is this just a trait of certain kinds of dimensions where the dimension itself has some significance to the business?

1 Answer 1


Conceptually, CustomerSignup is a fact. But if every Customer has exactly one Signup, you only care about the date, and there no measures associated with it, it might as well just be stored on the Customer dimension.

  • Thanks, that makes a lot of sense. Yeah I can't see what we'd put in a CustomerSignup fact right now, but we could always introduce it if we discover a need for it. There are some definite facts surrounding Customers that are wanted too. This is for a bank, and two measures are wanted: first transaction date, last transaction date. Obviously the first transaction date won't change, but the last transaction date may change frequently for active customers. I think these would go in a CustomerTransaction fact, potentially summarized by date.
    – d11wtq
    Apr 17, 2021 at 8:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.