[Mondrian] duplicate foreign keys in foodmart
etdube at gmail.com
Tue Sep 29 09:39:11 EDT 2009
Thanks for your throughout reply, it answers both of my questions.
> Regarding question 1. I don't recall exactly what Dr Kimball had to say on
> the matter ofr duplicate foreign keys. (As it happens I had a meeting with
> him on Thursday, but that particular topic didn't come up!) The way I see
> it, a fact table represents a business process, and while it's not common to
> get two identical instances of the business process (transactions), it's not
> out of the question.
Here's what my trusty old worn out copy of TDWTK says... from chapter 1:
"The fact table itself *generally* has its own primary key made up of a
subset of the foreign keys" (emphasis mine) and on adding an artificial
ROWID key in fact tables: "However, such a [ROWID] key may be required
to placate the database management system, especially if you can
legitimately, from a business perspective, load multiple identical rows
into the fact table". It sounds like you both have the same view on this
topic. I may have skimmed over that chapter a little bit too quickly the
first time and assumed that fact tables must have a primary key, when in
fact it's not mandatory.
> It is reasonable for the same customer to buy the same
> product, at the same supermarket, on the same day, using the same promotion
> code. (Who hasn't hosted a party where they had to go back to the
> supermarket for another six-pack of beer or another pack of ice?)
Sounds like a reasonable use case, as long as it's a good microbrew!
More information about the Mondrian