October 8, 2013 at 12:30 am
We do have one to one relationship between a FACT table and Dimension table? Is it correct to have this kind of dimensional model.
October 8, 2013 at 1:35 am
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
October 8, 2013 at 3:48 am
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;
Issue | Asset | Status |Priority |St_DT |End_Dt | Brief Description | Owner | location | Source
ISS1 | ASS1,ASS2 |Open |High |1-Jan-13 |NULL | issue description | scott | CA | SRC1
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.
October 8, 2013 at 3:49 am
In the above model dimension_issue and fact_issue is have 0ne to One relationship; Is it correct to have this kind of model?
October 8, 2013 at 9:58 am
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.
October 8, 2013 at 12:20 pm
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
October 9, 2013 at 1:37 am
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.
October 9, 2013 at 1:50 am
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
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply