0

I'm beginning to look at data warehousing and I'm coming across examples where, for instance, we have check payment transactions. I understand that this should be the "fact" and we would have dimensions around it that would describe the fact (account, product, etc.). However, it also contains things like "memo line" and string "transaction id" values which, as strings, don't really belong in the fact table.

My question is, should there be a separate payment "meta" dimension that contains these descriptors, or is it ok to say that something like the memo can't be reported on since it's different every time, so we should leave it out of the warehouse. I know it's somewhat of an abstract question, but I'm not finding much on this in my reading. Any suggestions would be greatly appreciated.

1

If you have an attribute with the same granularity of the Fact table (i.e.: "TransactionID") and it is usually used to filter one single Fact table, you don't have to create a separate table (aka Shared Dimension) for it. Instead, this attribute can live in the fact table itself. This is know as Degenerate Dimension

You can find more about it here: Degenerate Dimensions

| improve this answer | |
  • 1
    Thanks for the information. That makes perfect sense. – jordaniac89 Apr 30 at 18:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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