Dimension key in a fact table should be repetitive?

Question

Dimension key in a fact table should be repetitive?

manickam

Valued Member

Points: 59
More actions
October 8, 2013 at 12:30 am

#277880

We do have one to one relationship between a FACT table and Dimension table? Is it correct to have this kind of dimensional model.

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply

Koen Verbeeck SSC Guru Points: 259115 More actions · Answer 1

Normally relationships between fact and dimension are 1 to many, eg 1 dimension key can appear multiple times in the fact table.

Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP

manickam Valued Member Points: 59 More actions · Answer 2

We do have a reqirement to design a OLAP model for consolidating the issues identified on ASSETS from various sources\system.

Let us take one sample record;

We have designed the below model for this scenario:

Dimension_Asset: Conformed dimesion for assets.

Dimension_Asset_Group: Since each issue can have multiple assets we have designed a group table.

Dimension_Date: Conformed and role playing dimension for start and end date

Dimension_Issue: Issue_ID,Owner,Location,Brief Description,Source

Fact_Issue: Issue_ID,Asset_Group_ID,Status,Priority,St_DT,End_DT

Actually issues will be associated with many deatiled text and attributes. Do we need to capture this information in the FACT_ISSUE table or dimension_issue table. Dimension_Issue (though we cannot call it as dimension since its not repitative data in the fact table), is more like details of the fact table.

manickam Valued Member Points: 59 More actions · Answer 3

In the above model dimension_issue and fact_issue is have 0ne to One relationship; Is it correct to have this kind of model?

larskandersen Ten Centuries Points: 1232 More actions · Answer 4

You can have a 1 to 1 relationship between a dimension and a fact table, you often see this in a degenerate dimension.

You write “Actually issues will be associated with many deatiled text and attributes”, that is many to one between text and issue. Sounds like you need a bridge table or issue is not the grain in your fact table.

Koen Verbeeck SSC Guru Points: 259115 More actions · Answer 5

Since you have 1 fact for each issue (I guess the only measure is a count?), it is possible to have a 1 to 1 relationship.

Personally I would store status and priority in dimensions. Text attributes do not really belong in a fact table.

Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP

manickam Valued Member Points: 59 More actions · Answer 6

Many thanks for the replies

Even i am interested to have status and priority as dimensions, but does it have any impact on ETL layer.

Also the status and priority table would be having very minimal data.

Koen Verbeeck SSC Guru Points: 259115 More actions · Answer 7

manickam (10/9/2013)
Even i am interested to have status and priority as dimensions, but does it have any impact on ETL layer.
Also the status and priority table would be having very minimal data.

Sure it impacts the ETL layer. You'd have to write code to maintain those dimensions.

It doesn't matter if they contain minimal data, the point is to normalize your fact table. You need to make your fact table as small as possible, because this table will contain the most rows.

Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP