[Mondrian] duplicate foreign keys in foodmart

Etienne Dube 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 mailing list