Dimension Table contents
2 posters
Page 1 of 1
Dimension Table contents
Dear All ,
When designing the Dimension table is it true that all columns in the actual table(s) - in case more than one table used - must be included in the corresponding dimension .
for example in the CUSTOMER table we have the following columns :
1- ID expiry date : used in OLTP system to prevent generating an invoice for a customer with invalid ID .
2- Credit ceiling : Used to control number of unpaid Credit invoices allowed for the customer .
So I think such information are used to control the entry as a business rules , and it is not needed in the customer Dimension table.
Please Advice
Thanks
When designing the Dimension table is it true that all columns in the actual table(s) - in case more than one table used - must be included in the corresponding dimension .
for example in the CUSTOMER table we have the following columns :
1- ID expiry date : used in OLTP system to prevent generating an invoice for a customer with invalid ID .
2- Credit ceiling : Used to control number of unpaid Credit invoices allowed for the customer .
So I think such information are used to control the entry as a business rules , and it is not needed in the customer Dimension table.
Please Advice
Thanks
samimusleh- Posts : 23
Join date : 2013-03-03
Age : 58
Location : Saudi Arabia
Re: Dimension Table contents
It depends. Let the business decide what they need. A DW is often used to audit operational data. For example, identifying invoices that were sent to expired customers.
To your first point, the one rule about a dimension is they contain attributes about the entity they represent. So, anything goes.
But, in general, if capacity and performance is not an issue, then it is better to put more attributes in a dimension than less. Unless it is clear the attribute has no value, you are better off storing it. It can be hidden from users via views, but allows you to collect the information should it be needed. If a need is found, you can do the necessary validation and documentation of the attribute and expose it to the users. You avoid a significant development cycle.
To your first point, the one rule about a dimension is they contain attributes about the entity they represent. So, anything goes.
But, in general, if capacity and performance is not an issue, then it is better to put more attributes in a dimension than less. Unless it is clear the attribute has no value, you are better off storing it. It can be hidden from users via views, but allows you to collect the information should it be needed. If a need is found, you can do the necessary validation and documentation of the attribute and expose it to the users. You avoid a significant development cycle.
Re: Dimension Table contents
Thank you Mr. ngalemmo
Always you are very helpful , It is a pleasure for me to learn from you
Always you are very helpful , It is a pleasure for me to learn from you
samimusleh- Posts : 23
Join date : 2013-03-03
Age : 58
Location : Saudi Arabia
Similar topics
» Use a dimension to define contents of various reports?
» Pros and cons of consolidated dimension table Vs. many dimension table ?
» joining dimension table to dimension and again fact table
» Can a dimension table directly link to another dimension table?
» Pros and cons of consolidated dimension table Vs. many dimension table ?
» joining dimension table to dimension and again fact table
» Can a dimension table directly link to another dimension table?
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum