Home
Kimball Group Home
Search
Register
Log inTransaction description
2 posters
Page 1 of 1
Transaction description
dbadwh Tue Oct 11, 2011 1:59 pm
Hi,
How to handle the transaction description? Should it be a degenerated dimension?
How to handle the transaction description? Should it be a degenerated dimension?
dbadwh- Posts : 31
Join date : 2011-09-30
Re: Transaction description
ngalemmo Tue Oct 11, 2011 2:08 pm
As a dimension. If this is a free text field then treat the text as the dimension natural key and only store a unique description once. You may consider storing a hash of the text to serve as a alternate non-unique key to serve as an index rather than indexing the entire text field.
ngalemmo- Posts : 3000
Join date : 2009-05-15
Location : Los Angeles -
Re: Transaction description
dbadwh Wed Oct 12, 2011 4:31 am
What to do in case a customer data is updated many times a day and the description is of 2000 characters. Then the dimension will be bulky and cause trouble right? The dimensions are supposed to be thinner than fact.ngalemmo wrote:As a dimension. If this is a free text field then treat the text as the dimension natural key and only store a unique description once. You may consider storing a hash of the text to serve as a alternate non-unique key to serve as an index rather than indexing the entire text field.
dbadwh- Posts : 31
Join date : 2011-09-30
Re: Transaction description
ngalemmo Wed Oct 12, 2011 9:50 am
Exactly the opposite. Thin facts, dimension width is immaterial. A typical star query usully winds up scanning the fact table. Wide fact tables significantly degrade performance.
ngalemmo- Posts : 3000
Join date : 2009-05-15
Location : Los Angeles -
Transaction description
dbadwh Wed Oct 12, 2011 1:36 pm
Still, a transaction data where record is added for each call made by the customer with the remarks column can be considered in dimension?
dbadwh- Posts : 31
Join date : 2011-09-30
Re: Transaction description
ngalemmo Wed Oct 12, 2011 2:34 pm
Not sure what you are asking.
If you don't like the idea of putting the remarks in a dimension table, investigate how your database handles CLOB objects. Some databases allow you to store such columns in a separate area from the main table. In such cases, the overhead inherent in the large column only becomes a factor if the column is used in a query. In such cases, you could store it as a degenerate dimension value in a fact table. Otherwise, store it in its own dimension table. Treat it as a junk dimension and only include rows with unique values.
If you don't like the idea of putting the remarks in a dimension table, investigate how your database handles CLOB objects. Some databases allow you to store such columns in a separate area from the main table. In such cases, the overhead inherent in the large column only becomes a factor if the column is used in a query. In such cases, you could store it as a degenerate dimension value in a fact table. Otherwise, store it in its own dimension table. Treat it as a junk dimension and only include rows with unique values.
ngalemmo- Posts : 3000
Join date : 2009-05-15
Location : Los Angeles -
Re: Transaction description
dbadwh Thu Oct 13, 2011 11:20 am
Actually a customer may call the bank several times a day. In this case, his concerns or opinions can be stored as free text.
Here Customer is a dimension but the text happens to be a transaction. Which means for a customer, there could be multiple texts coming in a day,week or month. Hence storing the text in the dimension could cause a lot of problems. How to handle this?
Here Customer is a dimension but the text happens to be a transaction. Which means for a customer, there could be multiple texts coming in a day,week or month. Hence storing the text in the dimension could cause a lot of problems. How to handle this?
dbadwh- Posts : 31
Join date : 2011-09-30
Similar topics» Multiple transaction types, Average Transaction Value, and KPIs
» Transaction fact without obvious transaction type field
» Booking number and description in the fact table?
» How to handle several single description field dimensions
» Transaction fact table and Transaction line item fact table
» Transaction fact without obvious transaction type field
» Booking number and description in the fact table?
» How to handle several single description field dimensions
» Transaction fact table and Transaction line item fact table
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum