Quantcast
Channel: Debunking Kimball Effective Dates
Viewing all articles
Browse latest Browse all 83

re: Debunking Kimball Effective Dates

$
0
0

Hi Peter,

Your 2 cents are very welcome :)

"In your reply to my post you referred to the point that you want to avoid storing data twice. Does that mean you are snowflaking your dimensional model in order to avoid doing that?"

No. When I say I don't want to store data twice I am referring to these metadata fields (i.e. [SCDStartDate]&[SCDEndDate]) only, not to the attributes of the dimension member.

"The whole purpose of using a star schema is to enable business users with hardly any knowledge of the SQL language to pull out the data they need, and as fast as possible."

I'd mostly agree with that. Yes, a star schema is to pull the data out as fast as possible, I disagree that the SQL-authoring abilities of the end-user has any influence over our data model because the end-user will be (in the majority of cases) be abstracted away from the actual SQL anyway by a reporting/analysis tool. Therefore, if it were me I would rephrase your sentance as:

"The whole purpose of using a star schema is pull out the data as fast as possible."

"it is far easier to allow end users to figure out relevant questions by storing data redundantly"

Sorry Peter, I disagree with that! It makes it quicker, that is not the same as easier.

I should clarify something. I am not disregarding Kimball's dimensional model, nor denormalisation, as a means of enabling end-user querying and I believe I clarified that in the above blog post when I said: "I do not think the practise of managing dimension members as Type 2 slowly changing dimensions is a bad idea". Apologies if that wasn't clear. Furthermore I advocated denormalision of dimension record effective dates if absolutely necassary when I said: "If you absolutely need the [SCDEndDate] persisted somewhere then the view resultset can be materialised into a table"

What I do object to is the practice of unnecessarily storing data (i.e. [SCDEndDate]), especially when (IMO) a better method exists. I suspect you will say that storing that data is NOT unnecassary and IS indeed the best method - and that's OK. There's no correct answer here and that's why this comment section is currently 34-comments-strong.

Thanks for the comment Peter. As I keep alluding to I'm happy for the debate to continue.

-Jamie


Viewing all articles
Browse latest Browse all 83

Trending Articles