OWB Dimension Key

Hi Everyone,
I have a simple question for you guys, can anyone explain to me why that my PK from owb on Type I SCD is always starting a the number of rows that I inserts? If I'm loading a dimension for the first time, beit INSERT/UPDATE or UPDATE/INSERT and I'm loading n rows, the sequence starts at n instead of 1, I know that I should bother with that since it is only a PK but would like to understand what is being done in the background
Thank you
Jacques

Hi
OWB create the sequence to start at 1, when deployed it is ok, but when i run my mapping, it is like it is caching all the key for all rows and then generate new ones when inserting, I did start my sequence at minus n (-n) and then it started at 1, on the insert. Just curious to know what is happening under the hood.
Thanks for your reply

Similar Messages

  • 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

  • Load fact table with null dimension keys

    Dear All,
    We have OWB 10g R2 and ROLAP star schema. In our source system some rows don’t have all attributes populated with values (null value), and this empty attributes are dimension (business) keys in star schema. Is it possible to load fact table with such rows (some dimension keys are null) in the OWB mappings? We use cube operator in mappings.
    Thanks And Regards
    Miran

    The dimension should have a row indicating UNKNOWN, this will have a business key outside of the normal range e.g. -999999.
    In the mapping the missing business keys can then be NVL'd to -999999.
    Cheers
    Si

  • Difference between Dimension Id and Dimension Key

    I am reading the third chapter of Rittman's OBIEE book on design of Repository.
    It says while building the BMM, don't drag the dimension Id columns from physical layer to logical layer as the BI Server takes care of the join for you but make sure you drag across the dimension key columns as you will need these later on to create your logical table keys.
    Can someone enlighten me on what is the difference between a dimension id and dimension key (may be with an example).
    Thanks.

    Besides the theory says that a fact table can reference any level of a dimension, I couldn't do it with OWB. I don't know if there is a specific way to do that, but I only could assign a dimension detail level to a fact table.
    The ID's can have different values when I use a hierarchy in a dimension. OWB generates automatically negative ID's for the more summarized levels.
    For example, a product dimension with 2 levels: category and detail. If the product has 4 categories and 20 products (detail level), the table has 4 rows for categories with negative id's. Each row has a category and the fields specific for detail level are empty. The table will have other 20 rows for the detail level, with all fields filled, and all id's positive. The table will have 24 rows in the end.

  • CBO: OWB Dimension Performance Isssue (DIMENSION_KEY=DIM_LEVEL_ID)

    Hi
    In my opinion the OWB Dimensions are very useful, but sometimes there are some Performance Issues.
    I am working with the OWB Dimensions quite a lot and with the big Dimensions ( > 100.000 rows) , i often get some Performance problems when OWB generates the code to Load (Merge Step) or Lookup these Dimensions.
    OWB Dimensions have a PK on DIMENSION_KEY and Level Surrogate IDs which are equal to the DIMENSION_KEY if the The Row is an Element of that Level (and not a Parent Hierarchic Element)
    I am hunting the Problem down to the Condition DIMENSION_KEY= (DETAIL_)LEVEL_SURROGATE_ID. The OWB does that to get only the Rows with (Detail-) Level Attributes.
    But it seems, that the CBO isn´t able to predicted the Cardinality right. The CBO always assume, that the Result Cardinality of that Condition is 1 row. So I assume that Conditon is the reason for the "bad" Execution Plans, the Execution Plan
    "NESTED LOOPS OUTER" With the Inline View with Cardinality = 1;
    Example:
    SELECT COUNT(*) FROM DIM_KONTO_TAB  WHERE DIMENSION_KEY= KONTO_ID;
    --2506194
    Explain Plan for:
    SELECT DIMENSION_KEY, KONTO_ID
    FROM DIM_KONTO_TAB where DIMENSION_KEY= KONTO_ID;
    +| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |+
    +| 0 | SELECT STATEMENT | | 1 | 12 | 12568 (3)| 00:00:01 | | |+
    +| 1 | PARTITION HASH ALL | | 1 | 12 | 12568 (3)| 00:00:01 | 1 | 8 |+
    +|* 2 | TABLE ACCESS STORAGE FULL| DIM_KONTO_TAB | 1 | 12 | 12568 (3)| 00:00:01 | 1 | 8 |+
    Predicate Information (identified by operation id):
    +2 - STORAGE("DIMENSION_KEY"="KONTO_ID")+
    filter("DIMENSION_KEY"="KONTO_ID")
    Or: For Loading an SCD2 Dimension:
    +|* 12 | FILTER | | | | | | Q1,01 | PCWC | |+
    +| 13 | NESTED LOOPS OUTER | | 328K| 3792M| 3968 (2)| 00:00:01 | Q1,01 | PCWP | |+
    +| 14 | PX BLOCK ITERATOR | | | | | | Q1,01 | PCWC | |+
    +| 15 | TABLE ACCESS STORAGE FULL | OWB$KONTO_STG_D35414 | 328K| 2136M| 27 (4)| 00:00:01 | Q1,01 | PCWP | |+
    +| 16 | VIEW | | 1 | 5294 | | | Q1,01 | PCWP | |+
    +|* 17 | TABLE ACCESS STORAGE FULL | DIM_KONTO_TAB | 1 | 247 | 489 (2)| 00:00:01 | Q1,01 | PCWP | |+
    I tried a lot:
    - statistiks are gathered often, with monitoring Informations and (Frequencey-)Histograms and the Conditions Colums
    - created extend Statistiks DBMS_STATS.CREATE_EXTENDED_STATS(USER, 'DIM_KONTO_TAB', '(DIMENSION_KEY, KONTO_ID)')
    - created combined idx one DIMENSION_KEY, LEVEL_SURROGATE_ID
    - red a lot
    - hinted the Querys in OWB ( but it seems the inline View is to complex to use a Hash Join)
    Next Step:
    -Tracing the Optimizer CBO Events.
    Does some one has an Idea how-to help the CBO to get the cardinality right?
    If you need more Information, please tell me.
    Thanks a lot.
    Moritz

    Hi Patrick,
    For a relational dimension, these values must be unique within the LEVEL. It is not required to be a numeric ID (although that follows the best practices of surrogate keys best).
    If you use the same sequence for the dimension you have insured that each entry in the entire dimension is unique. Which means that you can move your data as is into OLAP solutions. We will do this as well in the next major release.
    Hope that helps,
    Jean-Pierre

  • Want binary_float dimension key

    Hi,
    I would like to set up a star schema with binary_float dimension keys to make them much smaller than the numeric datatype. When I do, I get validation warnings in the dimensions built in OWB. Can I ignore the warnings and use the smaller binary_float datatypes or am I setting myself up for trouble later in the project. We are running Oracle 10G 10.2.0.4 on HP Unix. We have OLAP installed but I am deploying dimensions and cubes with the "Deploy Data Objects Only" option because of all of the bugs in OWB. The fact table has about 110 million rows and about 100 gig.
    Has anyone used OWB with a star schema that uses binary_float surrogate keys?
    Thanks
    Don K.

    I am using the dimension operator in the map that loads the dimension and it seems to create the surrogate key correctly for new rows and merge the data for existing rows. I am have all of the dimensions set to Type 1. For the fact table map, I could not get the dimension objects to work correctly so I am using lookups into the dimension tables to get the surrogate keys. When I tried to use the dimension objects in the lookups it keeps adding an extra column with "_1" for the dimension key. It works correctly when I do the lookup using the dimension table. It seems like everything works okay. I am just worried about the warning message and wondering why OWB forces a number datatype when a float is much smaller.
    Thanks
    Don

  • Partitioning using a Dimension Key

    Hi -
    We have a dimension called Partner. We want to partition the facts for every partner using the partner dimension key. The challenge we have is that the dimension key is generated by OWB during run time, so we cannot create the partitions in the MDL. Is there any way to accomplish this?
    One workaround is to use the natural key as the surrogate key? Can this be done in OWB?

    Currently.... to partition the fact table by a meaningful column (for example a DATE column representing the time dimension ref) can be done with a little work with the downside that you cannot use the cube operator (and the CWM2 code is not correct either, but this is less of a priority..if you are not using it). The map to load the fact table must use the table operator and lookups performed for the dimensions using surrogate key references. This is not so bad a loss for those concerned with orphan handling with fact tables since incorporating orphan checking would result in a double lookup when using the cube operator in OWB 10.2.
    To do this:
    1. must add a key on the time dimension table for the DATE column.
    2. can then change the datatype of the column in the fact table referencing the time dimension table to DATE.
    3. then change the foreign key from the fact table to the time dimension table to use the new key on the DATE column.
    4. can now sensibly partition the fact table using time periods.
    5. The fact mapping will now use the fact table (rather than the cube operator) to load directly into the table.
    Cheers
    David

  • 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

  • Delete dimension key

    Hi SAP Gurus,
    Can anyone please tell me is there any way to delete dimensions key.
    I have one characterstic info object which is used in infocube.I want to delete it.Please tell me how can i do this.
    Regards
    Meenu

    Hi,
    Are you taking about the deletion of infoobject  thats being used in the IC right?
    Yes you can delete the char, first make sure there is no data exist in the IC before deleting the char from the Info cube.
    Regards
    KP

  • Dimension key in a fact table should be repetitive?

    Hi All,
    We do have one to one  relationship between a FACT table and Dimension table? Is it correct to have this kind of dimensional model.

    You may find this link of some help.
    How to Model Fact table having 1:1 relationship with key Dimension attributes

  • 10.2 OWB Dimension "binding" erases all Table metadata!

    I need some help with dimension definitions in OWB. I have a dimension that I created and deployed as ROLAP which includes its corresponding table.
    I added a number of indexes on the table and some default values on the columns - trying to avoid NULLS in the dimension fields.
    I then realized I needed one additional attribute in the dimension. I put the additional attribute in, selected "Bind" and poof - no more indexes, constraints or default values. It appears to have completely recreated the table metadata.
    Also, the column ordering of the corresponding table for the dimension appears to be random.
    Is there some better way to control this? I'm sure I'll have to add future attributles to existing dimenions!
    TIA,
    Mike

    OK, after perusing the manual for awhile, I found that to add columns to an existing dimension I need to:
    1. Go into dimension object editor, select the Storage tab and set it to "Manual" instead of Star.
    2. Add the columns to both the dimension and table
    3. right click the dimension to show "detailed view"
    4. manually map the column
    5. deploy (after juggling the creation type of the dimension and table)
    I don't find it at all intuitive and if you forget you wipe out your table metadata for the dimension but at least it works.

  • Dimensions: Key and Description by default

    Hi All,
    is there any chance to have Kex and Description of selected dimensions by default ... even in new reports?
    After changing this in the Query Designer for selected InfoObjects this isn't recognized by SPM. Every Dimension has Only Description by default.
    Thanks
    Pascal

    Hi Pascal,
    I don't think there is any setting to display the Key and Description by default on new report creation.
    But, when a report is created and saved setting to display the Key and Description, it will do so when the report is opened later.
    Note: such changes to display in the back-end or query will not affect the display in SPM frontend.
    Regards,
    Vimal G

  • BPC 75 NW - BPF driver dimension key and description in Data region

    Hello All,
    In our BPF templates we have used Costctr as our driver dimenion. When we go to My activities to view BPF instances- we only see the Costctr Description in the data region which is the default.  In our example- we have muliple cost centers globally with the same description.. so having the key displayed in the step region is critical. Is there a way to specify the key as well?
    We are on BPC 75 NW SP07 patch 3.
    Any help is appreciated.
    Thanks,
    Shai

    Hi,
    "Inherit from Data Region" means - when you open the BPF, you need to specify members for few of the dimensions. These members can be used by specifying "inherit from data region".
    For example, if, while opening the BPF, you enter USA for Entity and 2009.Total for Time. If "inherit from data region" is specified for entity dimension, then it will take USA, irrespective of the current view and the fact that the user is owner of some other dimension.
    In this case, either you can take it from CV or you can specify the member explicitly while designing the BPF. However, it will not serve your purpose.
    When you acces read access to the user for some entity, the user can still view the data. However, he wont be able to send data. So, restricting the view access is not possible in this case.
    Hoep this helps.

  • Ragged Hierarchy Snowflake Displays Dimension Key as Descriptor

    Hello All -
    I am having an issue with OWB 10gR2 and any help would be appreciated.
    I have created a Product Dimension using the "ROLAP" - "Manual" storage method which I've modeled as a snowflake to support our ragged hierarchy.
    I can create, validate, and view the data in the dimension and it is correct ... but the only level of my three levels (All Products, Products, Sub Products) to display the descriptor is the Sub Products level. The other two levels display the Surrogate ID - regardless of what settings I change.
    I know this might sound trivial but it does make a huge difference when you're working with a large number of product hierarchies or demonstrating to non-technical superiors.
    Thanks in advance for any assistance!

    I took a look at this thread, but I think you have a different issue than mine. My Snowflake dimension isn't implemented as MANUAL. I use the Snowflake option and it isn't a "ragged" hierarchy.
    In reality I do, but I "force" the levels to the maximum number. This lets me attach all facts at the base level and have a single grain. For example if I had a mix of 2 level and 3 level hierarchies, I repeat level 2 into level 3 for the 2 level items.
    I rarely use the data viewer, but I did see that if I use it on the table objects, I see my short descriptors. If I use it on the dimension objects it doesn't work - probably because I only implement relational objects.

  • OWB Dimensions

    DBME:Oracle 10gR2
    OS:WindowsXp
    hello,
    I am using OWB 10gR2 .I am working with dimensions.I know the basics of DWH but while reading "10R2 owb user guide" I get confused with some concepts.
    Can any one send me some good link from where I can read Dimension using OWB 10gR2. That might include detail.
    thanks
    tanveer

    Hi,
    I hope this link would help :
    http://download-uk.oracle.com/docs/cd/B31080_01/doc/owb.102/b28223/ref_dim_objects.htm

Maybe you are looking for