Cube Responsibilities: When to use then and when not
-
Hi Guys,
I have a very simple question that needs to be answered and as said in the heading, what are the responsibilities of a cube? Let me give you some scenarios:
Scenario 1:
A client purchases a new product, the product is sent for activation (stored in a product status history table.
). Would a cube be used to:- Return the number of customer sent for activation on a given date;
- Return the customers including their physical and postal addresses sent for activation on a given date;
- All of the above.
Scenario 2:
A customer is refunded X amount for a particular product he purchased. Would scenario 1 and scenario 2 be stored in one fact table?
No, this is not an exam... Just a question in general.
Thanks in advance...
-
It really depends on what you're attempting to do with the results. In both cases you could store / process this information, the question is should you?
Business intellegence is about understanding the generalized, analytical questions that'll be asked of the data. Typically, in involves examining trends, clusters, and correlations with sp0ecific senarios. If this information is part of that type of analysis, by all means, include it. (Think "rollup" when trying to establish the difference.)
If this is really an operational requirement, designed to alway address individual, specific information (i.e. customer look up, audit, etc.) then an operational database (OLTP) is the approach to take. If the requiremet is to always look at the specific information (and perhaps take some direct action), the you've a more traditional online requirement.
There's no hard line here, just general guidelines. As to how the data is stored, again, it's about how it'll be used. Under OLAP, ease of access is the most important consideration. Under OLTP, it's business rules and 3rd normal form.
-
To answer your question in scenario 1, c (all of the above) scenario 2 (Would scenario 1 and scenario 2 be stored in one fact table?), yes could do.
It would be good for you to get an understanding of dimensional modeling and then find out what the actual business questions are. What does the business what to know. I would assume that there is a OLTP that you are using for a source of your data mart/cube?
I would suggest that you create a prototype, drag in the transactional table, grag in and create a customer dimension (conformed if available/possible), date dimension and a measure of sales or transactions (what ever you are trying to count, sum - measure!). Then demo this to the business as a first cut, try and get them involved with the prototype, someone who understands the data in the source system. Once demo'ed you can get furthr requirements/ideas of what the business what. From this you should also get a good understanding of the source system, maybe look at the source source mapping kimball does, and use kimball for understanding dimensional modeling.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply