Day dimension and surrogate keys

Hello,
I'm trying to create a 'day' dimension using OWB. I was thinking about a set of levels like this:
- 'date_id'
- 'special_value' (such as unknown)
- 'calendar_date'
- 'month_day'
- 'month'
- 'year'
How can I implement something similar with OWB? I have to create one level for each dimension column? And how can I determine the value of date_id in the mapping?
Thanks in advance for the help
Cosma

Hi Cosma,
There's an example for this in the Oracle-by-Example session for OWB: http://www.oracle.com/technology/obe/obe9ir2/obe-dwh/owb/owb.htm
Around halfway through you'll find it.
Good luck, Patrick

Similar Messages

Demographics dimension and Logical Key.

Hello,
I have a simple star schema where there is a fact table linked to four dimensions. One of the dimensions is Customer Demographics. Others are Product, Time and Dealer.
Am I correct in using surrogate key of the demographics dimension as Logical Key for Demographics dimension in the BMM layer? Could you please let me know?
Thanks,
Manoj.

If the requirement is to do lots of "demographic" type queries - like sales amounts by race, gender, age, etc. - then snowflaking it off of a "person" dimension would really hurt query performance. Typically you only have demographic dimensions when either:
1. You don't have a person dimension at all - it's only the demographics you are interested in, or
2. You have a person dimension with millions of members, and splitting the demographics out into a separate dimension (typically a few thousand rows) means you can do a small join between the fact and a 3 thousand row demographics dimenion instead of doing a join between the fact table and a multi million row dimension table
In either case, snowflaking off of a person dimension table is either impossible or very bad for performance.
Thanks,
Scott

Time dimension and chronological key

HI ALL
I WORK ON OBIEE 11G REPORTS
WHAT IS THE EXACT USE OF TIME CHECK BOX AND CHRONOLOGICAL KEY??
AND HOW CAN I USE IT
ANY HELP ??

Hi,
What is the chronological key use?
A. Typically time dimension differs from all other dimensions in one way and that is,
all other dimensions dont care about the order of the values in it.
e.g. in region_dim the values are north, south, west and east. Here nobody wants to see whether north comes first or south comes first. i.e. no order is required here.
in the case of time dimension there needs to be a particular order for all the values present in it.
e.g. 2010 is earliest and 2004 is older. Dec-10 is earliest and jan-10 is older. i.e. the values in the time dimensiion needs to follow a particular sorting order. So the chronological key is the key which tells the obiee that the data is incrementing based on the chronological column.
Here you may get another doubt. i.e. you are having columns like year, half_year, quarter, month, week and day. Here which one should become the chronolgocial key?
Analyse it yourself. If you kept year as chro key then obiee will be confused whether jan-10 is earliest or feb-10 is earliest. Because it knows only that 2010 is earliest and 2009 is older.
So always it should be the lowest level oif the dimension which needs to be the chronological key. In the abouve case it should be date.
You can select either date or date_id(this could be a sequence generator values).
2. what is the use time dimension?
A.If all you want is to achieve drills from Month, Quarter and Year then treat it as a normal dimension and create the levels. But if you want to do calculations like YTD, QTD and MTD then you need to create a time dimension.
http://oraclebizint.wordpress.com/2007/11/05/oracle-bi-ee-101332-understanding-todate-and-ago-achieving-ytd-qtd-and-mtd/
Refer the above link for time dimension.
Award points it is useful.
Thanks
satya
Edited by: Satya Ranki Reddy on May 2, 2012 12:29 AM

10gR2 - dimension_key and surrogate identifier

Hi,
Both of these, dimension_key and surrogate identifier, end up deployed in the table. I am missing some basic understanding on the difference between these two. It looks that they will have the same values. Specifically, in the dimension editor under attributes we need to: "Choose the sequence that will populate the Dimension and Surrogate Keys:".
I looked through the User's Guide, but perhaps I missed the explanation of the two side by side.
Thanks for any help with this question.
Julian
Message was edited by:
juliank
Message was edited by:
juliank

Scott,
Glad to read your note. Hopefully, somebody else will be able to clarify this also.
My observations are similar. It is when I started looking at mappings imported from 10.1.0.4 that I started wondering about the dimension_key. After synchronization I planned to fix some joins I noticed that you can't rename the dimension_key. I think .... room for confusion and errors. My next thought was that perhaps the intention here is to utilize the surrogate key and to use the dimension_key at all?
Regarding your comment on surrogate keys - I see in the User's Manual on page 4-8: "A surrogate identifier uniquely identifies each level record across all the levels of the dimension." So ... will each level will get independently a key value from the same sequence?
Somewhere, I saw a nice little table comparing level indexing going from 10.1.0.4 to R2. I think it might have been in an on-line conference presentation when R2 was publicly announced. Maybe somebody else has this example handy.
Julian

How to Maintain Surrogate Key Mapping (cross-reference) for Dimension Tables

Hi,
What would be the best approach on ODI to implement the Surrogate Key Mapping Table on the STG layer according to Kimball's technique:
"Surrogate key mapping tables are designed to map natural keys from the disparate source systems to their master data warehouse surrogate key. Mapping tables are an efficient way to maintain surrogate keys in your data warehouse. These compact tables are designed for high-speed processing. Mapping tables contain only the most current value of a surrogate key— used to populate a dimension—and the natural key from the source system. Since the same dimension can have many sources, a mapping table contains a natural key column for each of its sources.
Mapping tables can be equally effective if they are stored in a database or on the file system. The advantage of using a database for mapping tables is that you can utilize the database sequence generator to create new surrogate keys. And also, when indexed properly, mapping tables in a database are very efficient during key value lookups."
We have a requirement to implement cross-reference mapping tables with Natural and Surrogate Keys for each dimension table. These mappings tables will be populated automatically (only inserts) during the E-LT execution, right after inserting into the dimension table.
Someone have any idea on how to implement this on ODI?
Thanks,
Danilo

Hi,
first of all please avoid bolding something. After this according Kimball (if i remember well) is a 1:1 mapping, so no-surrogate key.
After that personally you could use Lookup Table
http://www.odigurus.com/2012/02/lookup-transformation-using-odi.html
or make a simple outer join filtering by your "Active_Flag" column (remember that this filter need to be inside your outer join).
Let us know
Francesco

How we use Surrogate Keys for snowflake dimension

Hi All,
my question is - How we use Surrogate Keys for snowflake dimension
i heard from some body Surrogate Keys only work with star schema.
please correct me if i wrong.
Regards,
Manish

Hi manishcal16PPS,
According to your description, you can only create natural key in your dimension. But it's not working when using surrogate key. Right?
In Analysis Services, the snowflake schema of the dimensions are represented by more than one dimension table in other words its takes multiple dimension tables to define a dimension. Surrogate key are just some extra, redundant, unique key based on the
natural key. So there's no direct relationship or some limitations between surrogate keys and snowflake schema.
In this scenario, since there's relationship between the two dimensions, you should create natural key. For using natural key or surrogate key. Please refer to an article below:
Surrogate Key vs. Natural Key
For understanding star/snowflake schema, please see:
Understanding Star and Snowflake Schemas
Regards,
Simon Hou
TechNet Community Support

Loading dimensions and facts (Please verify the design is correct)

Hi,
I am very new to OWB and Datawarehousing, please find the following approach and let me know if its correct or not.
I have the following source tables,
1. Sales -->store_id,Product_id,Sales_date_Time,Unit_sales,Amount_sales
2. Product--> Product_id,Product_name,Product_category_id
3. Product_Category --> pc_id , pc_name
4. Stores -->store_id,store_name,city_id
5 City --> city_id , state
The above tables are normalized,
Now i have created Dimensions , and Fact (Please check whether its correct or not)
1 . Product_Dimension ->Product_key, product_id,product_name,pc_id,pc_name
2. Time_Dimension --> Time_key, ...Can be loaded from the Excel sheet provided (This is what people do here in my company)
3. Stores_Dimension --> Store_key,store_id,store_name,city_id,state
4. Sales_fact -->Product_key,time_key,store_key,Unit_sales,Amount_sales,sales_date
If the above design is correct, then i will create the following mappings
1. Map_Product --> loading product and product_Category from source
2. Map_Time --> loading thru SQLLDR directly
3. Map_Stores --> loading stores and city from source
Once the above mappings completed ( loading all the dimensions)
map_sales_fact --> loading from map_product, map_time, map_stores...
But if here if you closely observe Sales_Fact table, it has columns like unit_sales,amount_sales and sales_date. How do i load these as i dont have them in any dimensions,
Please help , please reply me if you need any clarifications.
Regards,
Ashoka BL
+919880890405

Hi,
first of all, there is no need for the column sales_date in your fact table. Use the time_id for date reference.
In your dimensions, use surrogate keys that are generated in your dwh. Do not use ids from your source as surrogate keys!
You may use the ids from the source as business keys, if the names are not unique.
Load your fact table from source table sales. Join all dimensions to get the surrogate keys of product, store and time.
Write the surrogate dim keys into the fact table along with unit_sales and amount_sales.
Regards,
Carsten.

Urgent expalantion about surrogate keys

Hi,
i had a big doubts about primary keys and surrogate keys, i don't know anything about surrogate keys.
need information on above..
Regards,
sh

sh wrote:
Hi,
i had a big doubts about primary keys and surrogate keys, i don't know anything about surrogate keys.
need information on above..
Regards,
shhttp://en.wikipedia.org/wiki/Surrogate_key

About Surrogate Key and Dimension Key on OWB 10.2

Hi, everyone.
I am using OWB 10.2 and I have a question about Surrogate key and Dimension Key.
I indicated the foreign key as VARCHAR2 type in Fact Table and Dimension Key as VARCHAR2 type is operated as Primary key in Dimension Table. I made Single Level in Dimension Table.
I know that Dimension Key stores the surrogate ID for dimension and is the primary key of the table. Also, Surrogate ID should be only NUMBER type.
So, in this case, Surrogate ID is NUMBER type
Dimension key should be NUMBER type to store the surrogate ID.
But, Dimension key also should operate the primary to relate Foreign key as VARCHAR2 type.
How I can solve this confusing condition?
Please let me know that.
JWS

Hi JWS,
From a SQL point of view it should not be a problem to join a NUMBER field to a VARCHAR2 field because during execution there will be an implicite cast for the NUMBER value to a VARCHAR2 value. See the example below.
SELECT * FROM DUAL
WHERE 1 = '1'From an OWB point of view it is not possible to have a Dimension with an NUMBER value Key that has a relation to a VARCHAR2 value Foreign key in a Fact table. This is caused due to the creation of a Fact table in OWB in which the Foreign keys in it are build from de Dimension tables that refer to them.
You will loose the reference to the Dimension when changing the type of the Foreign Key.
To resolve this issue I would advise you to use a Sequence that generates your Surrogate Key (NUMBER type) for the Dimension table and store it in the Primary Key Column (VARCHAR2 type).
When validating the mapping you will get a warning, but when executing this should give no problems.
Regards,
Ilona

Building dimensions that are based on surrogate keys

Hi -
I am new to AWM and have a question.
I read the docs, but I still do not understand how to build a cube using AWM.
So we have a DW with dimensions and fact tables. The dimension tables use surrogate keys.
The fact table uses the surrogate keys of the dimensions.
I want to define the time dimension in AWM.
The unique key for the dimension is the surrogate key (time_key).
In AWM I defined levels: day, month and year.
Would the hierarchy for the day level be:
time_key -> day?
Thanks,
Frank

Thankyou so much.
now when I try that here is the error that I get for that
line:
1118: Implicit coercion of a value with static type
flash.display:DisplayObject to a possibly unrelated type
flash.display:MovieClip.
I've placed a zipfile with my FLA, .as and .xml here:
http://bigfins.com/temp/test5xml.zip
The actionscript alone is below.
Thankyou again for any assistance.

MDX Query to show the latest product text again historical facts (Type 2 dimenion linking on Surrogate key and also Natural Key)

I need to write a MDX query to show the latest product text again historical facts or a chosen product text in time. I can write this query in TSQL, but new to MDX.
The way I do it in TSQL is joining two queries together on the Natural Key as opposed to the surrogate key.
Can this be done in MDX. I know I could write two separate MDX queries, one which get the product text I wan and the other to get the measure with the actual product text and Natural Key, and use a lookup function in ssrs to show the two result sets I the
same tablix by looking up the Natural Keys. But this should be able to be done in one query shouldn't it.
In the dsv the fact knows to join to the dimension using the surrogate key.
Thanks J

Hi Jamster,
According to your description, you want to write a query to show the latest product text, right?
In MDX, we can use LastNonEmpty function to return the lastest member winth a dimension. LastNonEmpty is an aggregation function available in the Enterprise version of SQL Server. However, you can create your own with a little bit of recursive MDX. Here
is a sample query for you reference.
With Member Measures.LastHits as
iif(isempty(Measures.Hits),
([Date].[Year Month Day].prevmember,
Measures.LastHits
),Measures.Hits)
Reference
http://cwebbbi.wordpress.com/2011/03/24/last-ever-non-empty-a-new-fast-mdx-approach/
http://richardlees.blogspot.com/2010/07/getting-last-non-empty-value.html
If this is not what you want, please provide us the detail structure of your cube and the expected result, so that we can make further analysis and give you the exactly MDX query.
Regards,
Charlie Liao
TechNet Community Support

Best Practice loading Dimension Table with Surrogate Keys for Levels

Hi Experts,
how would you load an Oracle dimension table with a hierarchy of at least 5 levels with surrogate keys in each level and a unique dimension key for the dimension table.
With OWB it is an integrated feature to use surrogate keys in every level of a hierarchy. You don't have to care about
the parent child relation. The load process of the mapping generates the right keys and cares about the relation between the parent and child inside the dimension key.
I tried to use one interface per Level and created a surrogate key with a native Oracle sequence.
After that I put all the interfaces in to one big Interface with a union data set per level and added look ups for the right parent child relation.
I think it is a bit too complicated making the interface like that.
I will be more than happy for any suggestions? Thank you in advance!
negib
Edited by: nmarhoul on Jun 14, 2012 2:26 AM

Hi,
I do like the level keys feature of OWB - It makes aggregate tables very easy to implement if your sticking with a star schema.
Sadly there is nothing off the shelf with the built in knowledge modules with ODI , It doesnt support creating dimension objects in the database by default but there is nothing stopping you coding up your own knowledge module (use flex fields maybe on the datastore to tag column attributes as needed)
Your approach is what I would have done, possibly use a view (if you dont mind having it external to ODI) to make the interface simpler.

How to create surrogate key in dimension without unique value

Hi, I have a dimension where there is no column with unique value. I want to add a surrogate key to replace the existing primary key which is derived from concatenating 3 columns(e.g. 'A'||'B'||'C'). I'm thinking of using sequence. But this won't allow me to link the dimension to fact table. How do I come up with surrogate key under this situation? Thanks. ~Tracy

I'm actually trying to accomplish something similar myself.
In my sources I've got two sorts of customers, ones that are directly reported, and ones whose information is provided with sales records (this is stored in module ODS).
Of course identification is different, but in the datamart (module DWH) I'm sort of forced to use an equivalent way of loading (due to the way it first used to work). To accelerate lookups on dimensions, I copy the ODS surrogate key to DWH dimensions, but this does not work for the 'inbuilt' customers because they do not have a surrogate key in the ODS.
They DO have means of unique identification, and at first I thought I could concatenate these (also 3) columns to use as identification code. Unfortunately this is VARCHAR2, where the surrogate key is (naturally) NUMBER.
So now it looks like I'm forced to first build a table in ODS especially for these 'inbuilt' customers and assign a surrogate key (by sequence) to it, this way it conforms to how 'normal' customers are loaded into DWH.
I guess you'll have to pull of the same trick, i.e. create a table with either only the 'translation' of D-code to a surrogate key or all information that is fed into the dimension, which then can be used as a lookup or as complete source when loading data into your datamart.
Good luck, Patrick

Primary Key and Chronological Key for Time Dimension

Could someone please shed light whether it's better to use normal PK or Calendar Date (which is a chronological key on the most detailed level). I tried both and haven't noticed any difference. But my understanding is that I still need to have the PK key on the most detailed level in time hierarchy.
Thanks

Matt,
the PK of the Time Dimension is a regular sequence numeric key. I have it defined as a logical PK for the dimension. However, I guess I was talking about hierarchy key. I tested it either way and the query time is the same. So I guess it doesn't really matter.
--------Year
Year (chronological key and primary key)
------------------Quarter
Quarter (key)
Quarter+Year (primary key, chronological key)
---------------------------------Day Detail
PK (key)
Date (primary key , chronological key)
I hope it makes sense.

Surrogate Key and Map for Cube

Hi
I am new to Data Warehousing and am trying to use OWB 11g.
I am trying to create dimensions with multiple levels. When I create more than one level it need to have surrogate as well business key for each dimension level. But I can create only one surrogate in the dimension, there is no option to create multiple surrogate keys in the same dimension. so what am I missing?
My second question is regarding cube. Do I need to create a Mapping for a cube? if yes, should I move the data to the cube from the dimensions? and where will the measures come from? do i need to load the measures or they will be calculated automatically?
please reply...
regards
Arif

hi
Got it, Yes that was the reason,
The table was not properly deployed after the dimension was modified.
Anyway, the describe of the table is as follows
describe arif.QUESTION_DIM
Name Null Type
DIMENSION_KEY NOT NULL NUMBER
IGV_ID NUMBER
PER_ID NUMBER
DIM_ID NUMBER
IGO_ID NUMBER
INQ_ID NUMBER
ID NUMBER
DIM_ORDEM NUMBER
DIM_AMBITO VARCHAR2(3)
DIM_NOME VARCHAR2(150)
10 rows selected
Now, I am having another problem,
when, I deploy the Map to load the data from three different tables, it gives the following problem
Name               Action               Status          Log
QUESTION_MAP          Create               Warning          ORA-06550: line 297, column 25:
                                        PLS-00302: component 'ID' must be declared
QUESTION_MAP          Create               Warning          ORA-06550: line 1153, column 11:
                                        PL/SQL: SQL Statement ignored
QUESTION_MAP          Create               Warning          ORA-06550: line 1155, column 15:
                                        PL/SQL: ORA-00904: "QUESTION_DIM"."ID": invalid identifier
QUESTION_MAP          Create               Warning          ORA-06550: line 1155, column 31:
                                        PLS-00302: component 'ID' must be declared
QUESTION_MAP          Create               Warning          ORA-06550: line 233, column 1:
                                        PL/SQL: SQL Statement ignored
QUESTION_MAP          Create               Warning          ORA-06550: line 2539, column 11:
                                        PL/SQL: SQL Statement ignored
QUESTION_MAP          Create               Warning          ORA-06550: line 2541, column 15:
                                        PL/SQL: ORA-00904: "QUESTION_DIM"."ID": invalid identifier
QUESTION_MAP          Create               Warning          ORA-06550: line 2541, column 31:
                                        PLS-00302: component 'ID' must be declared
QUESTION_MAP          Create               Warning          ORA-06550: line 297, column 9:
                                        PL/SQL: ORA-00904: "QUESTION_DIM"."ID": invalid identifier
Edited by: user643560 on Oct 22, 2008 9:38 AM

Day dimension and surrogate keys

Similar Messages

Maybe you are looking for