SCD Required if Dimension Attributes in Transaction?
2 posters
Page 1 of 1
SCD Required if Dimension Attributes in Transaction?
Hi there
I have a situation where we have a few of the key customer attributes actually captures on the sales order.
So what happens is that when an order is raised, the sales clerk types in the customer number. The screen will then generate show the default sales rep, and default sales group. The sales clerk can then override this - and this happens fairly frequently.
The business is only really interested in analysing the data by the sales person/division as captured on the invoices - not the standard default values.
The approach I am intending is as follows:
Have a customer dimension - obviously show customer code, address etc, and then also have fileds labelled "default sales person", and "default division"
Have a separate dimension for sales rep
Have a separate dimension for sales division[/list]
This will then allow users to produce reports based on classifications as per the invoiced transaction, rather than current master data. I do not believe the classic SCD type 2 approach is required since:
The change in dimensions values in presented to us in the transaction line, and we do not need to determine this by comparing our dimension table (from yesterday) to current master data, and inserting rows to track changes as per classic SCD type 2 approach?
Any thoughts?
Regards
Chrs
I have a situation where we have a few of the key customer attributes actually captures on the sales order.
So what happens is that when an order is raised, the sales clerk types in the customer number. The screen will then generate show the default sales rep, and default sales group. The sales clerk can then override this - and this happens fairly frequently.
The business is only really interested in analysing the data by the sales person/division as captured on the invoices - not the standard default values.
The approach I am intending is as follows:
Have a customer dimension - obviously show customer code, address etc, and then also have fileds labelled "default sales person", and "default division"
Have a separate dimension for sales rep
Have a separate dimension for sales division[/list]
This will then allow users to produce reports based on classifications as per the invoiced transaction, rather than current master data. I do not believe the classic SCD type 2 approach is required since:
The change in dimensions values in presented to us in the transaction line, and we do not need to determine this by comparing our dimension table (from yesterday) to current master data, and inserting rows to track changes as per classic SCD type 2 approach?
Any thoughts?
Regards
Chrs
chewza- Posts : 1
Join date : 2013-10-22
Re: SCD Required if Dimension Attributes in Transaction?
The type of change you are tracking is not handled by a type 2 anyway. Your solution to track the assigned sales rep/division is correct. It is an explicit assignment relating to the order and should be carried as an independent dimension.
Similar topics
» dimension table design question for around 100 attributes and higher level calculated attributes
» Dimension Attributes and Fact attributes storing same data in multiple data marts??
» Status attributes on main dimension or as separate dimension
» How to Handle Data that serves as both a dimension and attributes of another dimension
» Attributes as part of employee dimension and/or own dimension
» Dimension Attributes and Fact attributes storing same data in multiple data marts??
» Status attributes on main dimension or as separate dimension
» How to Handle Data that serves as both a dimension and attributes of another dimension
» Attributes as part of employee dimension and/or own dimension
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum