Diimensional design (long and deep!)

Question

Hi, could I have some comments here please, on best practice, and the one that is being proposed? I need a sanity check, please!!!
Consider this situation: there are two input files . . .
FILE1 contains
LEVEL1ID number
LEVEL1DESC varchar2
FILE2 contains
LEVEL2ID number
LEVEL2DESC varchar2
So, I want to create a dimension object in OWB, and at the Table level, it will look like
CREATE TABLE "DIM_2LEVELS" (
"L1_LEVEL1DESC" VARCHAR2(1),
"L1_LEVEL1ID" NUMBER, ..... (from FILE1 and renamed from 'ID' in OWB)
"L2_INTERNAL_END_DATE" NUMBER, ... (populated with NULL or some arbitrary high value)
"L2_INTERNAL_KEY" NUMBER, .......(populated from a SEQUENCE)
"L2_INTERNAL_START_DATE" DATE, ... (populated with SYSDATE from a CONSTANT)
"L2_LEVEL2DESC" VARCHAR2(1),
"L2_LEVEL2ID" NUMBER) ..... (from FILE2 and renamed from 'ID' in OWB)
(1). Is everyone in agreement with me that this is how it will look?
(2). And this for the Dimension object itself?
CREATE DIMENSION "DIM_2LEVELS"
LEVEL "LEVEL1" IS "DIM_2LEVELS"."L1_LEVEL1ID"
LEVEL "LEVEL2" IS "DIM_2LEVELS"."L2_INTERNAL_KEY"
HIERARCHY "HIER1"("LEVEL2" CHILD OF "LEVEL1" )
ATTRIBUTE "LEVEL1" DETERMINES ("L1_LEVEL1DESC" )
ATTRIBUTE "LEVEL2" DETERMINES ("L2_INTERNAL_END_DATE","L2_INTERNAL_START_DATE","L2_LEVEL2DESC","L2_LEVEL2ID" );
(3). Is this or is this not bog standard OWB so far? (Please check me every step of the way here).
Next, I go to Editor, Table Properties, Constraints Tab, and I change the UK of INTERNAL_KEY to a PK, and add a UK on LEVEL2ID (the Natural Key), giving these two SQL scripts:
ALTER TABLE "DIM_2LEVELS" ADD CONSTRAINT "LEVEL2_NK" UNIQUE("L2_LEVEL2ID");
ALTER TABLE "DIM_2LEVELS" ADD NSTRAINT "DIM12_LEVEL2_UK" PRIMARY KEY("L2_INTERNAL_KEY");
(4). Am I still OK, so far?
So, the implication is that at the lowest level of the hierarchy, this line drives the dimensional structure:
LEVEL "LEVEL2" IS "DIM_2LEVELS"."L2_INTERNAL_KEY"
The important point here is the "LEVEL2 IS . . . L2_INTERNAL_KEY". Please focus on this point.
Now,as I understand it, the purpose of the dimensional object is to aid in OLAP. The team where I am now working has seized on this point and feels that there must be a DIMENSION object (level) where there is something like "LEVEL2 IS . . . L2_LEVEL2ID'.
(5). So, the intent is to have a new policy whereby new lowest levels will be created in all dimension hierarchies, as follows:
* The lowest level in the hierarchy will be the surrogate key
* This is signified by a key symbol against the surrogate key ID in this level
* The surrogate key is the primary key and is distinct
* The data items associated with the surrogate key will become attributes in this level (typically control data)
* So the lowest level will only contain the surrogate key ID, dh_create_date, dh_update_date, SQ_Start_Date, SQ_End_Date
* The name of the surrogate key level is the same as the overall dimension name
* The next lowest level in the hierarchy is the natural key
* The natural key will have many surrogate keys (as the hierarchy changes over time)
* The data items associated with the natural key will become attributes in this level (typically descriptive or related business data)
This will also mean that the lowest level of the dimensional hierarchy will now explicitly correspond to a Start/End 'slice' of the fact table.
(6). What I have described in (1) to (4) is the way I have always handled building dimensions. To select the appropriate facts, I have constrained the join by adding start/end dates to the join selection parameters. The lowest level of the hierarchy is the lowest level that makes sense as an individual business 'thing', rather than as a data warehouse 'slice-in-time' of a slowly changing business 'thing'. To put it another way, the (1) to (4) method has at it's lowest level a business 'thing' (e.g. a customer) and selection on that (say) customer's natural key reveals all facts for that customer. (5) will do the same, but I feel that this is not what dimensions were intended to do.
So my ultimate question becomes . . . what actually are dimensions and the DIMENSION object intended to achieve? It is to support OLAP? After re-reading the OWB Users, Guide, the Data Warehousing Guide, and the OLAP manual, I cannot see where the 'LEVEL . . . IS' has any concrete value. Is it perhaps for Express? Ooops! Analytical Workspaces and CWM2?
As I said, there are two parts to this topic.
The first part is on best practices. I have described how I build Dimensions. Would others agree with me on this, or do you have a better way? In particular, would you add this additional 'basement' level to dimensional hierarchies?
The second part is around object representation, the designer's intent, and the repercussions on warehouse use in terms of business intelligence capabilities. My view has always been to represent Dimensions from the Business viewpoint - if a level makes sense from that viewpoint, it goes in. If it does not, then there is no place for it. When using summary tools like MVs, or BI tools like Discoverer or Business Objects, there have been no problems. Would there be if I were using AWM?
Looking forward to your deep thoughts!
Best,
Donna

Answer 1

Good afternoon Donna,
Have looked at this post a number of times, it surely is long and deep. I don't have any experience in using Oracle OLAP so I won't elaborate very much in that respect; neither have I actually looked at all code generated by OWB, especially dimensions. But since this thread is not getting started while the topic is certainly interesting, I'll give my few cents worth to maybe trigger the long and deep conversation you're looking for ;-)
@1 looks like what OWB generates for a dimension (the table bit)
@2 haven't really looked at that code before but looks valid
@3 indeed, looks like standard OWB
@4 that's also how I do it, the lowest level UK is the only physical one, and I add a UK on the natural key
@5 The reasoning for level-separation of SK and NK is the SCD nature of the dimension, yes? Why is that necessary? Strictly speaking the NK in combination with startdate will be unique, and both (in my opinion) are lowest level attributes. I don't see the necessity of creating separate levels, as far as I can see there's not really a hierarchy between those levels.
@6 a dimension to me is a table with an 'inbuilt' hierarchy; when used to generate a business area for Oracle Discoverer it creates hierarchies from that information. I guess it supports OLAP in a similar fashion (dimensions and cubes can be exported to generate an OLAP-cube).
Regards, Patrick
ps This is making me realise that in an SCD the natural key is going to occur more than once as soon as a record gets "SCD'd";
I better check my UK-naturalkey-definition, I might need to add 'startdate' to the natural key