Transaction description

View previous topic View next topic Go down

Transaction description

Post  dbadwh on Tue Oct 11, 2011 1:59 pm

Hi,
How to handle the transaction description? Should it be a degenerated dimension?

dbadwh

Posts : 31
Join date : 2011-09-30

View user profile

Back to top Go down

Re: Transaction description

Post  ngalemmo on 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.
avatar
ngalemmo

Posts : 3000
Join date : 2009-05-15
Location : Los Angeles

View user profile http://aginity.com

Back to top Go down

Re: Transaction description

Post  dbadwh on Wed Oct 12, 2011 4:31 am

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.
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.

dbadwh

Posts : 31
Join date : 2011-09-30

View user profile

Back to top Go down

Re: Transaction description

Post  ngalemmo on 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.
avatar
ngalemmo

Posts : 3000
Join date : 2009-05-15
Location : Los Angeles

View user profile http://aginity.com

Back to top Go down

Transaction description

Post  dbadwh on 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

View user profile

Back to top Go down

Re: Transaction description

Post  ngalemmo on 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.
avatar
ngalemmo

Posts : 3000
Join date : 2009-05-15
Location : Los Angeles

View user profile http://aginity.com

Back to top Go down

Re: Transaction description

Post  dbadwh on 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?

dbadwh

Posts : 31
Join date : 2011-09-30

View user profile

Back to top Go down

Re: Transaction description

Post  Sponsored content


Sponsored content


Back to top Go down

View previous topic View next topic Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum