Dimension table, indexing business key

Hi.
I my dimension table business key is Unique key constraint and business key is also a index key (unique).
My question is why is important for dimension to have index?
In my mapping I first load data into dimension and to merge data I use business key. Ok, business key is unique so I'm merging by constraint (UK).
I have a fact table mapping where I use previous dimension for lookup, and I do lookup by a business key.
I understand why we have index in fact tables, but in dimension?
When and why does business key index help me?

Hi,
There are many reasons why we use indexex on dimensions.
1) The source key or natural key may or may not be a unique one in case of SCD2 and hence its faster to look up w.r.t the index key rather than the source key.
2) It is not a good idea to have all the source keys from ur dimensions in ur fact. We have to have the index keys anyway to speed up the process of quering.
3) The index key is always unique and so u will always land on only 1 record on any look up
Regards
Bharath

Similar Messages

Dimension table indexes

All dimension table, non-key columns
should have individual bitmap indexes.
All fact table, foreign key columns must
have individual bitmap indexes on them.
By doing the above will the performance for joins be better.?
Rakesh

Well do remember bitmap indexes are best on columns where there not so many unique values. Everyone has differing opinions on what that # ought to be. In other words, the cardinality, or # of unique elements is not extremely high.
IN general, bitmap indexes will improve performance given that the CBO is using them.
Look at this post, it is a pretty good discovery on this sort of thing. it tends to be a design process, where you test with your given dataset and optimize it.
http://www.rittmanmead.com/2007/07/27/playing-around-with-star-transformations-and-bitmap-indexes/
-Greg

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.

Update/Load Dimension table attributes(non-key elements)

Hi,
Is there a configuration change in DAC or Informatica where I can opt to load all the dimension tables during an incremental load, irrespective of an associated transaction in the fact table? I observed that for all those accounts with no corresponding transactions are extracted but dropped by the time they reach the actual dimension table. So in the final target DWH, only those unique accounts are brought which have an associated transaction.
I know we can create an aux mapping to include some kind of a flag to trick DAC into thinking the corresponding base fact table also has changed and then bring over the dimension data. But is there a simple alternative?
For example, In GL we have an account dimension which has an associated line transaction details for each account in the fact table. I just change the Account name from A to B. No change or updates to the associated line entry in the FACT table. Now I run an incremental load. Will the change ( new account name) be recognized and brought over? OR will it be brought over only when the associated line entry also changes?
Usually when the dollar amounts dont change, nobody cares but in our case the client wants it. I have googled extensively to understand incremental loading but cud not get a clear response to the above question. Does SCD2 play any role in this?
Thanks,
Dan

Ahsan,
The question primarily revolves around dimension tables and incremental load. If we take out SCD1/2 out of the scene for now, could you please answer Yes or No for the below questions? Please it is kind of urgent as the client is really worried about these aspects of data transfer in incremental loads. As always, appreciate your quick response. Assume that first full load has been done.
1. If we change a key field (effective date) of an account that does not have a new transaction associated with it in the ledger – will the change come over after an incremental load?
2. If we change a non key field (title) on a prior effective date of an account that does not have a new transaction associated with it in the ledger – will the change come over after an incremental load?
3. If we change a non key field (title) on a prior effective date of an account that does have a new transaction associated with it in the ledger – will it reflect after an incremental load?
4. During a load process Full/Incremental, dimension tables get loaded first right? IF not, and facts are loaded first, wont they error out seeing that no associated dimension details exist?
5. We have a few custom tables which dont have any sort of a datetimestamp columns. Is bringing them all over everytime load happens, the only option? What is the best method to handle these kind of situations?
Thanks,
Dan

Should I relate a fact table to a fact table to a dimension table?

Hi All,
I'm designing a dimensional data mart for a client and I'm now forced to think about many-to-many relationships, among other complexities I haven't dealt with until now. Said client needs to be able to analyze contracts, subcontracts, bids, and bidders.
Each contract and subcontract can have multiple bids. Each bidder can only submit a single bid for any single contract or subcontract. And each bidder can submit a bid for any number of contracts and subcontracts.
My initial plan is this: FactContracts, with FactContractKey, ContractID, SubContractID; FactBids, with FactBidKey, FactContractKey, and BidderKey; finally, DimBidders, with BidderKey.
I've left out degenerate dimensions and original business keys only to keep this message short. Please let me know if more info is required, I really need a qualified designer or architect to advise me but I don't know anybody else that's accessible.
Thanks,
Eric B.

Thanks, SQLBIGuyMN, you answered our question. It makes sense, too, because bids are only analyzed if they've been accepted and contracted, and they would only be related to the bidder through the contracts fact. I think we've also determined that contracts
needs to be an Accumulating Snapshot Table.
Thanks again,
Eric B.

How and when does a dimension table gets generated

Hi Gurus,
                 I am new into BI and I will be put into a project within 2 months. I have learned that dimension table contains the sid's of all the charateristics in the dimension table. My conclusions are like
1. Dimension table contains the dim id as the primary key.
2. Dimension table contains sid's of the characteristics.
3. Though sid's in the dimension table are primary keys in thier 'S' table they are not key in the dimension table.
My question is
1. Is there any chance to generate new dim id's for the same combination of sid's because sid's are not part of the key?
2. I got confused when and how does the dimension table gets generated ?
I have searched in the forum and google but still my doubts didnt get clarified. If anyone could throw some light on this topic I would really appreciate it.

HI,
All your conclusions are correct.
Now for your questions the answers are in line:
1. Is there any chance to generate new dim id's for the same combination of sid's because sid's are not part of the key?
    No new dim id's will be generated, dim Id is unique for the same combination of sid's .
2. I got confused when and how does the dimension table gets generated ?
    They get generated when you activate the info provider.
Hope this helps.
thanks,
Rahul

Distinct count of dimension business key in fact table

In my cube I have a fact table which joins to a patient dimension. The patient dimension is a type 2. What I would like to do is get a distinct count of patients who have records in the fact table. The business key in the patient dimension
is the PrimaryMrn. So a SQL query would look like this.
SELECT count(distinct PrimaryMrn)
FROM EncounterFact e
INNER JOIN PatientDim p
on e.PatientKey = p.PatientKey
Is it possible to do this via MDX?
Thanks for the help.

If you have to distinct count an attribute in a SCD 2, you might choose between:
Denormalizing that attribute in the fact table, and the create a classical DISTINCT COUNT measure
Use a many-to-many approach - see the "Distinct Count" scenario in the Many-to-Many White paper here:
http://www.sqlbi.com/articles/many2many (for both Multidimensional and Tabular
If you use Tabular, you might want to read also this pattern:
http://www.daxpatterns.com/distinct-count/
Marco Russo http://www.sqlbi.com http://www.powerpivotworkshop.com http://sqlblog.com/blogs/marco_russo

No business key column is identified on existing dimension - Slow chg dimension

Hi,
I m working to insert/update my Dimension table (in datamart) using SSIS "Kimball Method SCD component " tool.
I have different columns as PK in source and identity column as PK in Dimension table.
I also have Unique Index on the columns in dimension which are PK in source table yet I m getting error from the tool that "no business key column is identified on existing dimension"
Any suggestions?
Thanks,

Business key needs to be defined in the component tool itself.
Double click the component and it will open a wizard kind dialog box.
The first tab is "Existing Dimension Input Column Definitions".
In this tab, the grid has a column "SCD Column Type" which looks like label field but if you click it twice, it turns into dropdown list and from here, you can define Business key for your dimension table.
HTH

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

What is '#Distinct values' in Index on dimension table

Gurus!
I have loaded my BW Quality system (master data and transaction data) with almost equivalent volume as in Production.
I am comparing the sizes of dimension and fact tables of one of the cubes in Quality and PROD.
I am taking one of the dimension tables into consideration here.
Quality:
/BIC/DCUBENAME2 Volume of records: 4,286,259
Index /BIC/ECUBENAME~050 on the E fact table /BIC/ECUBENAME for this dimension key KEY_CUBENAME2 shows #Distinct values as 4,286,259
Prod:
/BIC/DCUBENAME2 Volume of records: 5,817,463
Index /BIC/ECUBENAME~050 on the E fact table /BIC/ECUBENAME for this dimension key KEY_CUBENAME2 shows #Distinct values as 937,844
I would want to know why the distinct value is different from the dimension table count in PROD
I am getting this information from the SQL execution plan, if I click on the /BIC/ECUBENAME table in the code. This screen gives me all details about the fact table volumes, indexes etc..
The index and statistics on the cube is up to date.
Quality:
E fact table:
Table   /BIC/ECUBENAME
Last statistics date                  03.11.2008
Analyze Method               9,767,732 Rows
Number of rows                         9,767,732
Number of blocks allocated         136,596
Number of empty blocks              0
Average space                            0
Chain count                                0
Average row length                      95
Partitioned                                  YES
NONUNIQUE Index   /BIC/ECUBENAME~P:
Column Name                     #Distinct
KEY_CUBENAMEP                                  1
KEY_CUBENAMET                                  7
KEY_CUBENAMEU                                  1
KEY_CUBENAME1                            148,647
KEY_CUBENAME2                          4,286,259
KEY_CUBENAME3                                  6
KEY_CUBENAME4                                322
KEY_CUBENAME5                          1,891,706
KEY_CUBENAME6                            254,668
KEY_CUBENAME7                                  5
KEY_CUBENAME8                              9,430
KEY_CUBENAME9                                122
KEY_CUBENAMEA                                 10
KEY_CUBENAMEB                                  6
KEY_CUBENAMEC                              1,224
KEY_CUBENAMED                                328
Prod:
Table   /BIC/ECUBENAME
Last statistics date                  13.11.2008
Analyze Method                      1,379,086 Rows
Number of rows                       13,790,860
Number of blocks allocated       187,880
Number of empty blocks            0
Average space                          0
Chain count                              0
Average row length                    92
Partitioned                               YES
NONUNIQUE Index /BIC/ECUBENAME~P:
Column Name                     #Distinct
KEY_CUBENAMEP                                  1
KEY_CUBENAMET                                 10
KEY_CUBENAMEU                                  1
KEY_CUBENAME1                            123,319
KEY_CUBENAME2                            937,844
KEY_CUBENAME3                                  6
KEY_CUBENAME4                                363
KEY_CUBENAME5                            691,303
KEY_CUBENAME6                            226,470
KEY_CUBENAME7                                  5
KEY_CUBENAME8                              8,835
KEY_CUBENAME9                                124
KEY_CUBENAMEA                                 14
KEY_CUBENAMEB                                  6
KEY_CUBENAMEC                                295
KEY_CUBENAMED                                381

Arun,
The cube in QA and PROD are compressed. Index building and statistics are also up to date.
But I am not sure what other jobs are run by BASIS as far as this cube in production is concerned.
Is there any other Tcode/ Func Mod etc which can give information about the #distinct values of this Index or dimension table?
One basic question, As the DIM key is the primary key in the dimension table, there cant be duplicates.
So, how would the index on Ftable on this dimension table show #distinct values less than the entries in that dimension table?
Should the entries in dimension table not exactly match with the #Distinct entries shown in
Index /BIC/ECUBENAME~P on this DIM KEY?

Dropping business key from existing dimension

A business key needs to be removed from an existing dimension in a data warehouse.
I couldnt locate any documentation regarding this topic, so please let me know of any links to documentation if you know of any.
Im needing to know if this can be done, or will I need to create another dimension (with correct keys), transfer data,
then swap dimensions in the mapping.
Thanks for any input.

I am sure th business key would be a part of the constaint with which u load the data into the table. So its better u make an analysis of how the data is going to affect the load before u make the change.either create a new one with the correct keys test it for the data and then swap the data or take the existing table, make the changes ,test it in DE?V/SIT and once u r confident it is not affecting the load u can move it to quality and production.
Regards
Bharath

Non Unique Indexes on Dimension Table

Hello ,
I have Material Dimension that has Product MainGroup, Brand , SPC code broken from Product Hierarchy.
As per Business Requirement , we don't want to use the Product Hierarchy , that should need to split into 3 pieces.
Since The Cube Dimensions already reached the 13 , we can not increase the dimensions to keep these 3 fields into separate dimensions.
I heard from Basis guy as <b>we can have index on three fields in same dimension table</b> & read some negative impact on aggregate definition.
Is it true , which one is true , am not sure.
Which one impact causes more worst & usefull..?
Could please some experts throw some light on this.
Cheers
Martin

Martin -
Not sure what you mean by "read some negative impact on aggregate definition".
But as far as adding additional indices on other columns of a dimension table, that certainly is doable. I have never done this as part of an actual intentiional design, but it seems like a valid apporach if you are limited by dimensions. I'm assuming when you say you already have 13, that the 13 does not include the three standard dimensions for time, request, (drawing a blank, is it currency), so that you really have 16 dimensions, 13 of which are user defined.
We have added dimension tabl e indices in our shop when we have found large dimension tables that, either from poor initial design, or changes to the data and/or queries, have resulted in full tables scans against large dimension tables. In some cases, the query costs of the full scan of the dimension table was more than the cost for the access of the fact table itself.
These indices must be added by your DBA as they can not be added thru the Admin Wkbench. You should also probably keep a record of any of these indices you create because if for some reason you delete the tables and reactivate the cube, you'll probably lose them.
Pizzaman

How to load composite business key into Dimension

Hi,
Maybe what I'm asking is very basic but, well, here I go:
I have a dimension, CollectingAgent, and several tables to populate from:
Bank (bank_code, bank_name ) [PK: bank_code]
Agency (bank_code, agency_code, agency_name, address, etc) [PK: bank_code, agency_code]
Now, for my purposes, collecting agent is the bank+agency descriptions concatenated. I don't know hoy to load, or map, the combinated key (bank_code, agency_code) into the business field of the dimension. OWB won't let me define more than one attribute as business key.
I'm using OWB 10g Rel2.
Thanks in advance for your help,
--oswaldo.
[osantos]

Ok, let me try to give an example made up with completely bogus information. I'm going to make a dimension called clothing that has two hierarchies that look like this:
"Item" hierarchy:
All Clothing --> Item Type --> Color / Item
"Color" hierarchy:
All Clothing --> Color --> Color / Item
Item type would be values such as pants, shirts, dresses, etc. The low level "color / item" is just a combination of those two (i.e. "Blue Shirt") - and note in this example that it will have 2 composite natural keys. It will roll up over the item type hierarchy under shirts, and under the color hierarchy in blue. Here's a sample of what I'm talking about:
(Item hier)
All Products
...Pants
......Blue Pants
......Red Pants
......Green Pants
...Shirts
......Blue Shirts
......Red Shirts
etc.
(Color Hier)
All Products
...Blue
......Blue Pants
......Blue Shirts
...Red
......Red Pants
......Red Shirts
like I said, completely bogus, but this will let me illustrate how to set up the dimension. I'd create the following attributes (hard to format, sorry):
Key....................Surrogate Key
ID.......................Natural Key
Item_Type_ID......Natural Key
Color_ID..............Natural Key
Short_Desc.........short description
Long_Desc..........long description
Having created these attributes, I'd then create the following levels and assign the attributes as follows:
All_Products_Level:
...Key
...ID
...Short_Desc
...Long_Desc
Item_Type_Level:
...Key
...Item_Type_ID
...Short_Desc
...Long_Desc
Color_Level:
...Key
...Color_ID
...Short_Desc
...Long_Desc
Color_Item_Level:
...Key
...Color_ID
...Item_Type_ID
...Short_Desc
...Long_Desc
Should be pretty easy from there. The whole trick is to have a SERIES of different natural keys - a "generic" one (ID) for dimension levels you don't really care about, and "named" ones (color_id, item_type_id) you can use for given levels. And note that you CAN have more than one natural key at any level, and you can have some natural keys that are not used at all levels.
For your simple dimension, you can probably do the following (note that I'm assuming the lowest level has your composite two business keys, while the top level is completely separate):
TOP_LEVEL:
...Key (for the surrogate key)
...ID (for the business natural key)
...Short_Desc
...Long_Desc
BOTTOM_LEVEL:
...Key (for the surrogate key)
...Business_natural_key_1 (rename to be match your first business key)
...Business_natural_key_2 (rename to match your second business key)
...Short_Desc
...Long_Desc
Hope this helps! If you need to see something a little more concrete, feel free to email me at SPowell at columbus.rr.com, send me some details on exactly what your keys are, etc. and I'll whip up a quick example for you.
Thanks,
Scott

Dimension key 16 missing in dimension table /BIC/DZPP_CP1P

Hi all,
I have a problem with an infocube ZPP_CP1. I am not able to delete nor load any data. It was working fine till some time back.
Below is the outcome of running RSRV check on this cube. I tried to run the error correction in RSRV. But n o use
Please help.
Dimension key 16 missing in dimension table /BIC/DZPP_CP1P
Message no. RSRV018
Diagnosis
The dimension key 16 that appears as field KEY_ZPP_CP1P in the fact table, does not appear as a value of the DIMID field in the dimensions table /BIC/DZPP_CP1P.
There are 17580 fact records that use the dimension key 16.
The facts belonging to dimension key 16 are therefore no longer connected to the master data of the characteristic in dimension.
Note that errors that are reported for the package dimension are not serious (They are thus shown as warnings (yellow) and not errors (red). When deleting transaction data requests, it can arise that the associated entries in the package dimension have already been deleted. As a result, the system terminates when deleting what can be a very large number of fact records. At the moment, we are working on a correction which will delete such data which remains after deletion of the request. Under no circumstances must you do this manually. Also note that data for request 0 cannot generally be deleted.
The test investigates whether all the facts are zero. If this is the case, the system is able to remove the inconsistency by deleting these fact records. If the error cannot be removed, the only way to re-establish a consistent status is to reconstruct the InfoCube. It may be possible for SAP to correct the inconsistency, for which you should create an error message.
Procedure
This inconsistency can occur if you use methods other than those found in BW to delete data from the SAP BW tables (for example, maintaining tables manually, using your own coding or database tools).

Hi Ansel,
There has been no changes in the cube. I am getting this problem in my QA server. So I retransported the cube again from Dev to QA. But did not help me..
Any other ideas??
Regards,
Adarsh

Define logical Key on Logical Dimension Table

It's recommended to define a logical key for any logical dimension table - in 10g there was a function on the right mouse button, as far as I remember - but in 11g there is no such functionality ? the foreign key can be added by "green plus" button, but not the primary key ?? you have to type in the name of the key, then you can choose the column and then you select as primary key ... funny.
bug or undocumented feature?

Hi Srini,
Since my main logical fact table consists of two LTS and the dimension being created from this table will also have 2 LTS, the content level will be set to all levels on which the fact is joined.
So I would like to create a logical dimension based out of my dimension and then assign the content level at the detail level.
Please let me know if I am not clear.
Thanks

Dimension table, indexing business key

Similar Messages

Maybe you are looking for