Retail Point of Sale Fact Table Question

View previous topic View next topic Go down

Retail Point of Sale Fact Table Question

Post  blynch on Thu Jan 19, 2012 11:48 am

For a retail, point of sale fact table I am thinking of taking what Ralph said in class that the "grain is the beep" literally.

So talking this through, everytime an item is scanned as a "sale" that would go into the fact table.

Does this also mean that rows that might come over in ETL, such as a row that is not a "sale" but a "tender" of a SKU, or a "return" of SKU, should go into their own fact table?

Something like:

FactSales
FactTenders
FactReturns
FactDiscount
...etc.?

Or should I put all point of sale rows into one fact table, FactSales and just filter on the different transaction types from a DimTransactionType key?

Thank you very much for any insights.

Brad

blynch

Posts : 18
Join date : 2011-10-16

View user profile

Back to top Go down

Re: Retail Point of Sale Fact Table Question

Post  ngalemmo on Thu Jan 19, 2012 11:53 am

I would go with one fact and include a transaction type dimension. I would include classification codes as attributes to ease selection (such as a 'this is a sale' transaction type indicator). This would allow you to flag multiple types (such as sales and returns) as sales transactions.
avatar
ngalemmo

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

View user profile http://aginity.com

Back to top Go down

Re: Retail Point of Sale Fact Table Question

Post  blynch on Thu Jan 19, 2012 12:02 pm

The reason I ask this is because the FactSales table could be drastically reduced if it was only, sales, line item corrects and trx voids which only make up ~25% of the rows. The rest are some other transaction type that we care about, but not as much as these 'sales' types.

Thank you for your insights.

blynch

Posts : 18
Join date : 2011-10-16

View user profile

Back to top Go down

Re: Retail Point of Sale Fact Table Question

Post  Jeff Smith on Thu Jan 19, 2012 12:32 pm

I think one fact is better.

Each transaction requires an action at the POS. If you grab everything, you can answer "Total $ in Sales", "Total $ in Returns", and "Net Dollars" as well as "Total Sales Transactions", "Total Returns", "Total Discounts", "Total non monetary transactions", and "Total Transactions". The transaction volumes can be more useful than the sales. It can be used in staffing models, it can be used to measure the effectiveness of changes in processes.

Jeff Smith

Posts : 471
Join date : 2009-02-03

View user profile

Back to top Go down

Re: Retail Point of Sale Fact Table Question

Post  blynch on Thu Jan 19, 2012 12:35 pm

Enlightening points, thank you very much for that!

blynch

Posts : 18
Join date : 2011-10-16

View user profile

Back to top Go down

Re: Retail Point of Sale Fact Table Question

Post  arnaudnorgdegren on Sun Jan 22, 2012 8:40 pm

ngalemmo wrote:I would go with one fact and include a transaction type dimension. I would include classification codes as attributes to ease selection (such as a 'this is a sale' transaction type indicator). This would allow you to flag multiple types (such as sales and returns) as sales transactions.


I agree


_____________________
What are Backlinks| Article Marketing Robot Review

arnaudnorgdegren

Posts : 2
Join date : 2012-01-08

View user profile

Back to top Go down

Re: Retail Point of Sale Fact Table Question

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