OLAP CUBES

Question

Hi I am a little confused.
I am trying to build a cube with 3 dimensions COUNTRY,ORDER and PVPERIOD.
I have mapped the dimensions to the tables . The country table is WD_AUTO_ORDER_GEO. The order table is WD_AUTO_ORDERS and PVPERIOD is WD_AUTO_ORDER_DATES. The dimensions did map correctly. Now I added some measures from my fact table and I am trying to map my cube.
I mapped my measures fine. I still have to map my order dimension in my cube which ORDER is part of my key in the fact table which MAPPED CORRECTLY... Then I mapped country which is part of my key in the fact table. My problem is pvperiod which is not a column or part of my key in the fact table. Pvperiod needs to be a foreign key in my fact table or part of the primary key. Correct??

Answer 1

Hi Pam,
I have taken a look at the table definitions you sent. My guess is that these are the raw tables used by your OLTP system to register orders. This guess is based on the fact that all three 'dimension' tables and the 'fact' table share five columns:
ORDER_NUMBER
COUNTRY
RCN
TYPE
VFILE
The meaning of the ORDER_NUMBER and COUNTRY seem clear enough, though I am less clear on the other columns. But it appears that when a new order is entered you update all four tables. Is this correct?
In a typical data warehouse system the raw transaction data needs to be transformed by a process know as Extract, Transform, and Load (ETL -- http://en.wikipedia.org/wiki/Extract,_transform,_load) to create a Star Schema (http://en.wikipedia.org/wiki/Star_schema). The cube is then loaded directly from the star schema. It may be possible to load the cube directly from your OLTP tables, but that is probably not optimal.
The correct definition of star schema for your system depends on your requirements, but it could include tables like these
TABLE "GEOGRAPHY_TABLE"
  "CUSTOMER_ID" NUMBER,  -- is this RCN in your system?
  "COUNTRY"    VARCHAR2(3 BYTE),
  "STATE"      VARCHAR2(5 BYTE),
  "NAME"       VARCHAR2(45 BYTE),
  "ADDRESS"    VARCHAR2(45 BYTE),
  "ZIP"        VARCHAR2(15 BYTE)
TABLE "DATE_TABLE"
  "DAY"     DATE,
  "MONTH"   NUMBER,
  "YEAR"    NUMBER
)Note that these are not specific to one order -- they can be shared between orders. Your DATE_TABLE would be pre-populated for the period of interest -- a few years, say. The GEOGRAPHY_TABLE would be updated when a new customer appears or when someone changes address. (Changes of address gets you into the world of 'slowly changing dimensions', so you would need to decide how you want your OLAP system to react to this.) Perhaps you don't need the address detail in the cube at all -- it all depends on what queries you want to run against it.
The 'order dimension' is more difficult since it is really an OLTP concept that is harder to fit into an OLAP system. Do you really want your cube to go down to the level of individual orders? What kind of analysis do you want to do there? A single order is pinned to one customer and one order date, so there is really not much dimensional analysis you can perform. An alternative, for example, would be to aggregate up to the level of 'warehouse' in your cube so that you could see how much traffic goes through an individual warehouse. This is certainly multi-dimensional. Your remaining star schema tables could then look as follows
TABLE "WAREHOUSE_TABLE"
"WAREHOUSE"    NUMBER
TABLE "ORDER_FACT"
  -- dimension keys
  "ORDER_DAY"        DATE,
  "CUSTOMER_ID"      NUMBER,
  "WAREHOUSE"        NUMBER,
  -- measures, aggregated from the OLTP tables
)My point in all this is that you need to have a clear idea of what analysis you want to perform on your cube, including which levels (e.g. ORDER) that you need to use. This should be the driver of the cube design, and from here you can work back to the design of the star schema. Perhaps you have already done this analysis, in which case you will be a long way ahead.