Surrogate dimension

( OWB CLIENT 11.1.0.6.0 )
how to implementation this dim_lok,
because I just want to Surrogate just 1.
Thanks.
Ineed Suggestion
Level CENTER
Level STORE
--DIM_LOK
DIMENSION_KEY SURROGATE
CENTER_ID
CENTER_DESCRIPTION
CENTER_NAME BUSINESS
STORE_ID
STORE_DESCRIPTION
STORE_NAME BUSINESS

All these 3 hierarchies are level based hierarchies and hierarchies 2 (P&L) and 3 (BS) are subsets of main hierarchy 1 (TB).
There should not be any duplication if you use generic level identifiers for the levels of the hierarchies instead of using the actual member names which (kind of) represent the levels.
Try
TOT level for "Total" in Main hierarchy
ELEM level to represent the generic level containing members: "Profit" and/or "Balance Sheet"
=> Use level to represent L2 in Main containing "Profit" and "Balance Sheet"
=> Use level to represent L1 in P&L containing "Profit"
=> Use level to represent L1 in BS containing "Balance Sheet"
LEAF level to represent the leaf level in each hierarchy
=> Use level to represent L3 in Main containing "Gross Profit", "Expenses", "Assets" and "Liabilities"
=> Use level to represent L2 in P&L containing "Gross Profit" and "Expenses"
=> Use level to represent L2 in BS containing "Assets" and "Liabilities"
3 Hierarchies
Main: LEAF -> ELEM -> TOT
P&L: LEAF -> ELEM
BS: LEAF -> ELEM
There wouldnt be any duplication in this case.
In fact the Profit member in Main hierarchy and Profit Member in P&L hierarchy would be the same in all respects (All attributes including Name, Desc, Fact Value stored against the member). The front end or UI will not be able to distinguish b/w the member in different hierarchies w/o regard to the context of the report and/or additional reporting metadata.

Similar Messages

  • Do surrogate dimension keys duplicate data in the AW?

    According to AWM, level-based hierarchies must have unique dimension values across hierarchies (correct me if this is not accurate).
    So a dimension with two or more hierarchies that share common leaf-level dimension members will essential duplicate (or triplicate) that member in the analytic workspace,
    Does this then mean that data for a 'single' dimension value gets written to three separate surrogate dimension values in the AW cube?

    All these 3 hierarchies are level based hierarchies and hierarchies 2 (P&L) and 3 (BS) are subsets of main hierarchy 1 (TB).
    There should not be any duplication if you use generic level identifiers for the levels of the hierarchies instead of using the actual member names which (kind of) represent the levels.
    Try
    TOT level for "Total" in Main hierarchy
    ELEM level to represent the generic level containing members: "Profit" and/or "Balance Sheet"
    => Use level to represent L2 in Main containing "Profit" and "Balance Sheet"
    => Use level to represent L1 in P&L containing "Profit"
    => Use level to represent L1 in BS containing "Balance Sheet"
    LEAF level to represent the leaf level in each hierarchy
    => Use level to represent L3 in Main containing "Gross Profit", "Expenses", "Assets" and "Liabilities"
    => Use level to represent L2 in P&L containing "Gross Profit" and "Expenses"
    => Use level to represent L2 in BS containing "Assets" and "Liabilities"
    3 Hierarchies
    Main: LEAF -> ELEM -> TOT
    P&L: LEAF -> ELEM
    BS: LEAF -> ELEM
    There wouldnt be any duplication in this case.
    In fact the Profit member in Main hierarchy and Profit Member in P&L hierarchy would be the same in all respects (All attributes including Name, Desc, Fact Value stored against the member). The front end or UI will not be able to distinguish b/w the member in different hierarchies w/o regard to the context of the report and/or additional reporting metadata.

  • What is technical advantage 0f having 16 dimension tablefor an fact table

    Hi ALL,
      Clarify my doubt.
    Regards
    DEEPAK

    Hi Sudhir,
    the limit of 16 key fields comes from the underlying DB ... Most of them do not support more. There is no difference from this point of view using different DBs becauses SAP abstracts the underlying DB BUT does consider their "common" limits, so it's built considering that an ABAP table can't be formed with more than 1 key fields, because some DB don't support this requirement.
    As far it concerns the consideration of 248 Chars per Dim ... in a Dimension table there is a surrogate DIMension ID (DIMID) as a key field! Characteristics are "attribute" fields. So this limitation hasn't the same cause.
    Hope it's clear
    GFV

  • Fact table/Cube mapping

    I'm relativly new to the OWB but I'm in the learing proces...I have some serious problems mapping the cube.
    How do I map my surrogate dimension key into the cube (which has the same surrogate key)?
    Do I have to map them at all or are they automatically mapped during the creation of the constraints within the cube?
    If anybody could help me (or recommend a source/book where to look), this is much appreciated.
    Thanks in advance,
    Manuel

    Igor,
    thanks for your reply and your help.
    Just to clarify: I created a two dimensions, mapped and executed them (data was successfully loaded!) and finally I created a cube which is linked to the dimensions through the foreign keys (as you described)...
    Now I want to load a calculated measurement (which i get through the aggregation operator from one dimension) into the cube and in the same mapping map the surrogate key of the other dimension with the (dimension) foreign key of the cube. But when I try this then I directly get an error in the mapping editor: "API8003: Connection target attribute group is already connected to an incompatible data source".
    I'm even not sure if I have to do it like this or if through the foreign key relationship between cube and dimension no direct mapping is necessary! Or if the design is wrong as I have no direct relationship between the measurement and other dimension...
    Please help as my thesis is dependend on the data warehouse :-)
    Thanks
    Mani

  • Compile Model does not work

    I am trying to test a model using a surrogate dimension:
    ->dsc bulr_pl_sum_rl_mdl
    DEFINE BULR_PL_SUM_RL_MDL MODEL
    LD test
    MODEL
    dimension su_rl
    02010 = 03000
    END
    The version I am using is:
    ->shw eversion
    Oracle OLAP Build 84089
    No matter what syntax I use (putting quotes around the dimension values, using the base dimension values, putting this_aw! in the dimension statement, etc), I get a compilation error which says "ERROR: (ORA-33774) 02010 is not a command. I am very concerned here, as this is about the simplest model I can think of
    Are models not allowed in OLAP? Is there a patch that should be applied? Is there a syntax change in Oracle OLAP for defining or using models in 10.2.0.3? Is this merely a bug? I seem to be missing something basic here, but can see what.

    Try referring to the dimension members as DIM('<<dim_value>>') instead.
    Your model should look like this:
    DEFINE BULR_PL_SUM_RL_MDL MODEL
    LD test
    MODEL
    dimension su_rl
    su_rl('02010') = su_rl('03000')
    END

  • Production Cube painfully slow when resolving partitioned data

    Hi,
    We have a few 10g cubes in our production environment on Unix servers. For the most part the users are very satisfied with the response time. Most are of a similar design Global Composites, compressed around 9 dimensions.
    Recently we introduced a new cube and took advantage of the Parallell processing
    feature and partitioned it on the month level of time . It has 9 dimensions (see portion of load log below for specifics). All dimensions are sparse , global composites, Compression, 15 measures .. Most dimensions are aggregated fully or 1 below the top with the exception product aggregated only to the leaf level.
    The load works fine 9million data rows loaded and aggregated in 2 hours. The problem we are having is in the response time to a query. It's fine when only 1 month is selected. When you select qtr and years the query becomes painfully slow. When selecting 1 measure for 1 month it takes about 15 seconds to return. When selecting the same measure for the year or qtr it takes about 6 minutes to return. The same is true when I run a report from the Olap worksheet using olap DML so i know that it has nothing to do with the front end or network.
    Any ideas on what could be causing the bottleneck in summing the partitions or on how to diagnose the problem. Version is 10.2.0.2
    There are only 7 months in the cube and it's 25gb.
    thx
    Mike
    SQL> select xml_loadid, xml_recordid, xml_date, xml_message
    2 from OLAPSYS.xml_load_log
    3 where xml_loadid = 1006;
    XML_LOADID XML_RECORDID XML_DATE XML_MESSAGE
    1006 1 12-AUG-07 14:17:30 Job# AWXML$_1006 to Build(Refresh) Analytic Workspace RLCUBEMGR.ACP_MTH Submitted to the Queue.
    1006 11 12-AUG-07 14:17:31 Started Build(Refresh) of RLCUBEMGR.ACP_MTH Analytic Workspace.
    1006 12 12-AUG-07 14:17:31 Attached AW RLCUBEMGR.ACP_MTH in RW Mode.
    1006 13 12-AUG-07 14:17:31 Started Loading Dimensions.
    1006 14 12-AUG-07 14:17:33 Started Loading Dimension Members.
    1006 15 12-AUG-07 14:17:33 Started Loading Dimension Members for A_FICO_MTH.DIMENSION (1 out of 8 Dimensions).
    1006 16 12-AUG-07 14:17:34 Finished Loading Members for A_FICO_MTH.DIMENSION. Added: 27. No Longer Present: 0.
    1006 17 12-AUG-07 14:17:34 Started Loading Dimension Members for A_GEN4_MTH.DIMENSION (2 out of 8 Dimensions).
    1006 18 12-AUG-07 14:17:34 Finished Loading Members for A_GEN4_MTH.DIMENSION. Added: 11. No Longer Present: 0.
    1006 19 12-AUG-07 14:17:34 Started Loading Dimension Members for A_LOC_MTH.DIMENSION (3 out of 8 Dimensions).
    1006 20 12-AUG-07 14:17:44 Finished Loading Members for A_LOC_MTH.DIMENSION. Added: 22,887. No Longer Present: 0.
    1006 21 12-AUG-07 14:17:44 Started Loading Dimension Members for A_MAKE_MTH.DIMENSION (4 out of 8 Dimensions).
    1006 22 12-AUG-07 14:17:45 Finished Loading Members for A_MAKE_MTH.DIMENSION. Added: 59. No Longer Present: 0.
    1006 23 12-AUG-07 14:17:45 Started Loading Dimension Members for A_PROD_MTH.DIMENSION (5 out of 8 Dimensions).
    1006 24 12-AUG-07 14:17:45 Finished Loading Members for A_PROD_MTH.DIMENSION. Added: 31. No Longer Present: 0.
    1006 25 12-AUG-07 14:17:45 Started Loading Dimension Members for A_SUBV_MTH.DIMENSION (6 out of 8 Dimensions).
    1006 26 12-AUG-07 14:17:45 Finished Loading Members for A_SUBV_MTH.DIMENSION. Added: 3. No Longer Present: 0.
    1006 27 12-AUG-07 14:17:45 Started Loading Dimension Members for A_TERM_MTH.DIMENSION (7 out of 8 Dimensions).
    1006 28 12-AUG-07 14:17:45 Finished Loading Members for A_TERM_MTH.DIMENSION. Added: 12. No Longer Present: 0.
    1006 29 12-AUG-07 14:17:45 Started Loading Dimension Members for A_TIME_MTH.DIMENSION (8 out of 8 Dimensions).
    1006 30 12-AUG-07 14:17:45 Finished Loading Members for A_TIME_MTH.DIMENSION. Added: 11. No Longer Present: 0.
    1006 31 12-AUG-07 14:17:45 Finished Loading Dimension Members.
    1006 32 12-AUG-07 14:17:45 Started Loading Hierarchies.
    1006 33 12-AUG-07 14:17:45 Started Loading Hierarchies for A_FICO_MTH.DIMENSION (1 out of 8 Dimensions).
    1006 34 12-AUG-07 14:17:46 Finished Loading Hierarchies for A_FICO_MTH.DIMENSION. 1 hierarchy(s) STANDARD Processed.
    1006 35 12-AUG-07 14:17:46 Started Loading Hierarchies for A_GEN4_MTH.DIMENSION (2 out of 8 Dimensions).
    1006 36 12-AUG-07 14:17:47 Finished Loading Hierarchies for A_GEN4_MTH.DIMENSION. 1 hierarchy(s) STANDARD Processed.
    1006 37 12-AUG-07 14:17:47 Started Loading Hierarchies for A_LOC_MTH.DIMENSION (3 out of 8 Dimensions).
    1006 38 12-AUG-07 14:18:03 Finished Loading Hierarchies for A_LOC_MTH.DIMENSION. 5 hierarchy(s) DLRGRP, RGNDLRGRP, RGNSTATE, STANDAR
    D, STATE Processed.
    1006 39 12-AUG-07 14:18:03 Started Loading Hierarchies for A_MAKE_MTH.DIMENSION (4 out of 8 Dimensions).
    1006 40 12-AUG-07 14:18:03 Finished Loading Hierarchies for A_MAKE_MTH.DIMENSION. 1 hierarchy(s) STANDARD Processed.
    1006 41 12-AUG-07 14:18:03 Started Loading Hierarchies for A_PROD_MTH.DIMENSION (5 out of 8 Dimensions).
    1006 42 12-AUG-07 14:18:03 Finished Loading Hierarchies for A_PROD_MTH.DIMENSION. 2 hierarchy(s) NEWUSED, STANDARD Processed.
    1006 43 12-AUG-07 14:18:03 Started Loading Hierarchies for A_SUBV_MTH.DIMENSION (6 out of 8 Dimensions).
    1006 44 12-AUG-07 14:18:03 Finished Loading Hierarchies for A_SUBV_MTH.DIMENSION. 1 hierarchy(s) STANDARD Processed.
    1006 45 12-AUG-07 14:18:03 Started Loading Hierarchies for A_TERM_MTH.DIMENSION (7 out of 8 Dimensions).
    1006 46 12-AUG-07 14:18:04 Finished Loading Hierarchies for A_TERM_MTH.DIMENSION. 1 hierarchy(s) STANDARD Processed.
    1006 47 12-AUG-07 14:18:04 Started Loading Hierarchies for A_TIME_MTH.DIMENSION (8 out of 8 Dimensions).
    1006 48 12-AUG-07 14:18:04 Finished Loading Hierarchies for A_TIME_MTH.DIMENSION. 1 hierarchy(s) STANDARD Processed.
    1006 49 12-AUG-07 14:18:04 Finished Loading Hierarchies.
    1006 50 12-AUG-07 14:18:04 Started Loading Attributes.
    1006 51 12-AUG-07 14:18:04 Started Loading Attributes for A_FICO_MTH.DIMENSION (1 out of 8 Dimensions).
    1006 52 12-AUG-07 14:18:04 Finished Loading Attributes for A_FICO_MTH.DIMENSION. 2 attribute(s) LONG_DESCRIPTION, SHORT_DESCRIPTION
    Processed.
    1006 53 12-AUG-07 14:18:04 Started Loading Attributes for A_GEN4_MTH.DIMENSION (2 out of 8 Dimensions).
    1006 54 12-AUG-07 14:18:04 Finished Loading Attributes for A_GEN4_MTH.DIMENSION. 2 attribute(s) LONG_DESCRIPTION, SHORT_DESCRIPTION
    Processed.
    1006 55 12-AUG-07 14:18:04 Started Loading Attributes for A_LOC_MTH.DIMENSION (3 out of 8 Dimensions).
    1006 56 12-AUG-07 14:18:11 Finished Loading Attributes for A_LOC_MTH.DIMENSION. 11 attribute(s) A_DEALER_AMERICREDIT_IND, A_DEALER_E
    CONTRACTING_IND, A_DEALER_MARKET_SEGMENT, A_DEALER_ONEGAP_IND, A_DEALER_RESERVE_PLAN, A_DEALER_RETAIL_SALES_AGR_APV, A_D
    EALER_SEGMENT, A_DEALER_STATUS_CD, A_FLOOR_PLAN_PROVIDER_NAME, LONG_DESCRIPTION, SHORT_DESCRIPTION Processed.
    1006 57 12-AUG-07 14:18:11 Started Loading Attributes for A_MAKE_MTH.DIMENSION (4 out of 8 Dimensions).
    1006 58 12-AUG-07 14:18:11 Finished Loading Attributes for A_MAKE_MTH.DIMENSION. 2 attribute(s) LONG_DESCRIPTION, SHORT_DESCRIPTION
    Processed.
    1006 59 12-AUG-07 14:18:11 Started Loading Attributes for A_PROD_MTH.DIMENSION (5 out of 8 Dimensions).
    1006 60 12-AUG-07 14:18:11 Finished Loading Attributes for A_PROD_MTH.DIMENSION. 2 attribute(s) LONG_DESCRIPTION, SHORT_DESCRIPTION
    Processed.
    1006 61 12-AUG-07 14:18:11 Started Loading Attributes for A_SUBV_MTH.DIMENSION (6 out of 8 Dimensions).
    1006 62 12-AUG-07 14:18:11 Finished Loading Attributes for A_SUBV_MTH.DIMENSION. 2 attribute(s) LONG_DESCRIPTION, SHORT_DESCRIPTION
    Processed.
    1006 63 12-AUG-07 14:18:11 Started Loading Attributes for A_TERM_MTH.DIMENSION (7 out of 8 Dimensions).
    1006 64 12-AUG-07 14:18:11 Finished Loading Attributes for A_TERM_MTH.DIMENSION. 2 attribute(s) LONG_DESCRIPTION, SHORT_DESCRIPTION
    Processed.
    1006 65 12-AUG-07 14:18:11 Started Loading Attributes for A_TIME_MTH.DIMENSION (8 out of 8 Dimensions).
    1006 66 12-AUG-07 14:18:12 Finished Loading Attributes for A_TIME_MTH.DIMENSION. 2 attribute(s) LONG_DESCRIPTION, SHORT_DESCRIPTION
    Processed.
    1006 67 12-AUG-07 14:18:12 Finished Loading Attributes.
    1006 68 12-AUG-07 14:18:12 Finished Loading Dimensions.
    1006 69 12-AUG-07 14:18:12 Started Updating Partitions.
    1006 70 12-AUG-07 14:18:12 Finished Updating Partitions.
    1006 71 12-AUG-07 14:18:26 Detached AW RLCUBEMGR.ACP_MTH.
    1006 72 12-AUG-07 14:18:26 Starting Parallel Processing.
    1006 10073 12-AUG-07 14:18:27 Attached AW RLCUBEMGR.ACP_MTH in MULTI Mode.
    1006 10074 12-AUG-07 14:18:27 Started Load of Measures: V_APP_RECEIVED, V_APP_APPROVED, V_APP_COUNTERED, V_APP_CANCELLED, V_APP_DECISIONE
    D, V_BKD_UNIT, V_BKD_DOLLAR, V_OS_UNIT, V_OS_DOLLAR, V_DELQ_UNIT, V_DELQ_DOLLAR, V_CHGOFF_UNIT, V_CHGOFF_DOLLAR, V_REPO_
    UNIT, V_DLRRSVUNEARN from Cube ACPMTH.CUBE. DEFAULT Partition.
    1006 10075 12-AUG-07 14:18:42 Finished Load of Measures: V_APP_RECEIVED, V_APP_APPROVED, V_APP_COUNTERED, V_APP_CANCELLED, V_APP_DECISION
    ED, V_BKD_UNIT, V_BKD_DOLLAR, V_OS_UNIT, V_OS_DOLLAR, V_DELQ_UNIT, V_DELQ_DOLLAR, V_CHGOFF_UNIT, V_CHGOFF_DOLLAR, V_REPO
    UNIT, VDLRRSVUNEARN from Cube ACPMTH.CUBE. DEFAULT Partition. Processed 0 Records. Rejected 0 Records.
    1006 10076 12-AUG-07 14:18:42 Started Auto Solve for Measures: V_APP_APPROVED, V_APP_CANCELLED, V_APP_COUNTERED, V_APP_DECISIONED, V_APP_
    RECEIVED, V_BKD_DOLLAR, V_BKD_UNIT, V_CHGOFF_DOLLAR, V_CHGOFF_UNIT, V_DELQ_DOLLAR, V_DELQ_UNIT, V_DLRRSVUNEARN, V_OS_DOL
    LAR, V_OS_UNIT, V_REPO_UNIT from Cube ACPMTH.CUBE. DEFAULT Partition.
    1006 90112 12-AUG-07 16:09:33 Running Jobs: AWXML$_1006_577, AWXML$_1006_578. Waiting for Tasks to Finish...
    1006 90113 12-AUG-07 16:18:57 Finished Parallel Processing.
    1006 90114 12-AUG-07 16:18:57 Completed Build(Refresh) of RLCUBEMGR.ACP_MTH Analytic Workspace.
    SQL> COLUMN DBMS_LOB.GETLENGTH(AWLOB) HEADING "Bytes";
    SQL> SELECT EXTNUM, SUM(DBMS_LOB.GETLENGTH(AWLOB)) FROM AW$acp_MTH GROUP BY EXTNUM;
    EXTNUM SUM(DBMS_LOB.GETLENGTH(AWLOB))
    1 5715538444
    3 3758960128
    2 3758960128
    0 1.1173E+10
    4 2295138076

    Watrost makes some very valid points and you should review the suggestions he has made.
    In addition I would like to add the following. When deciding on how and when to use partitioning and parallel processing I would suggest considering these points:
    1) The partition dimension - most people partition on time, probably because all the examples I have seen in this area show this as if it were the "normal" method. Using time is a good idea if you want to perform some form of rolling time window and need to quickly and easily drop data for a specific time period. However, partitioning does impact on query performance and you need to balance the needs of "ease of maintenance" against query performance for your users. Once you have selected a level to use as the partition key you will notice on the Summary tab that levels above this key are in fact grayed out and cannot be selected. As Watrost points out, the partition key in effect becomes your top level of pre-aggregation. All other levels are summed at query time. This is normally ok, but for a 9 dimensional model it means you have no summary levels computed across any of your other 8 dimensions for levels above the partition key. This will have a serious impact on your query performance.
    2) Parallel processing - many people seem to implement partitioning in the expectation that their cubes will aggregate more quickly. In most cases this can be true but there are many factors to consider. To be really effective you need to have multiple CPUs, and you should set the number of parallel jobs to a maximum of No of CPUs-1. For some reason I have seen many DBAs just randomly pick a number for this value that greatly exceeds the number of CPUs and then wonder why their cube build takes such a long time. I would start by using the No of CPUs/2 and scaling up to No of CPUs-1 to determine the sweet spot for your system based on resources. Don't forget it is not just CPUs that are important in this situation you also need fast disks as I/O contention can occur very easily.
    3) Partial vs Full aggregation - If you upgrade to the latest 10.2.0.3 patcheset and apply the OLAP A Patch as well (available from Metalink) which will allow you to take advantage of partial aggregation features. When loading data into a cube you should only aggregate data for incoming values rather than re-aggregating data for the whole cube. Although AWM does provide a radio button to control this on the second page of the maintenance wizard it is only with the above patchsets that this actually works.
    4) Sortarea size : check your sortarea size. Typically, this is set very small in most instances and OLAP operations are very sort intensive. Therefore, increasing this to 1M or higher can have a significant impact on load performance.
    5) Monitoring Builds - There are some free performance views you can download from OTN that will help you monitor what is happening during a build. See the link for SQL Scripts for OLAP DBAs and the associated readme at:
    http://www.oracle.com/technology/products/bi/olap/OLAP_DBA_scripts.ZIP
    http://www.oracle.com/technology/products/bi/olap/OLAP_DBA_README.htm
    I would look at the views AW_WAIT_EVENTS, OLAP_PGA_USE and AW_LONGOPS as well as generally monitoring your instance via OEM using the ADDM reports that can be generated. These will help you discover performance bottlenecks in your system
    Now for the dilemma - parallel processing vs partitioning. Most people would agree that partial aggregation is a good idea as there is no need to re-aggregate a complete cube when there have been no changes to the dimensions/hierarchies and you are loading data for just the current month. But if you partition by month you will never get parallel processing because you will only be aggregating data within a single partition and for parallel processing to occur aggregation must occur across multiple partitions. What it does mean is that the time take for each load and partial aggregation should be consistent which makes it easy to plan.
    If this is proving to be a significant problem then it is possible to use partitioning and generate a fully solved cube. In 11g this will be resolved using a new aggregation feature. For 10gR2 it is possible to create this type of solution. In fact I have just re-designed a customers physical data model to reduce the query time for one of their main user reports from 14 minutes to 10 seconds. The problem was the query accessed the data within the partition that was not aggregated.
    It is quite a simple process and does not change your current logical data model. Quite simply you create a surrogate partition dimension with only one two levels - All and "Level 1". Partition on "Level 1". If you are using time, which most people do, level 1 contains all the values for all months, all quarters and all years. Next create a source table that contains using GROUPING SETS to compute totals for months, quarters and years only for base levels across all your other dimensions. This will created an embedded total fact table for your surrogate time dimension.
    In the mapping editor, map the surrogate time dimension column in the fact table to your surrogate dimension "Level 1". In the Rules tab within AWM set the aggregation for this surrogate dimension to "Do not Aggregate". Load your data.
    In your existing cube you replace your existing stored measures with calculated measures, using the same name, that point to the new physical cubes via a QDR from the standard time dimension to the surrogate time dimension.
    Hope this helps.
    Keith Laker
    Oracle EMEA Consulting
    BI Blog: http://oraclebi.blogspot.com/
    DM Blog: http://oracledmt.blogspot.com/
    BI on Oracle: http://www.oracle.com/bi/
    BI on OTN: http://www.oracle.com/technology/products/bi/
    BI Samples: http://www.oracle.com/technology/products/bi/samples/

  • 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

  • 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

  • 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

  • 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.

  • Implementing surrogate keys in dimensions

    hello,
    First thing, I'm new to ODI! I am using Oracle data integrator 10.1.3.
    I have a dimension table 'Dim_Contracts' as target table. The structure is as follows:
    PK_Dim_Contract Primary key (surrogate key - to be populated from an Oracle database sequence in the target)
    Contract_ID (normal field in target - no constraints in target- to be populated from source - originally a primary key in source)
    + other dimension attributes.
    from what i have googled out and read in the forum, i cannot define 'PK_Dim_Contract' as the primary key of my dimension (target) table, to be able to update it from the oracle sequence defined - rather the 'contract_ID', which is the natural key should be the primary key. Is that correct? If yes, isn't it against dimension modelling principle?
    More to the point, my question is: How do I populate a sequence in my primary key field in the target table?
    Thanks for your help.
    Regards,
    Anju

    Hello Anju,
    Welcome in the ODI community ;).
    What I suggest you is to set the UNIQUE KEY on Contract_ID in your target. This way you will be able to use flow control and do Incremental Update Loading.
    PK_Dim_Contract (surrogate key) can be your primary key in the dabatase.
    To populate PK_Dim_Contract from an Oracle Sequence, create it first in your Oracle DB. Add a new sequence to your project (left pane), choose Natural Sequence, choose your schema and enter the name of your Oracle Sequence.
    In your interface, define the mapping of PK_Dim_Contract as
    :<ODI_SEQUENCE_NAME>_NEXTVALand execute this mapping on the target.
    Note: :<ODI_SEQUENCE_NAME>_NEXTVAL works only for SQL Statements. If you want to use the sequence somewhere else, use the following syntax :
    #<ODI_SEQUENCE_NAME>_NEXTVALHope it helps,
    Jerome

  • Surrogate identifier and Business identifier on Dimensions

    I understand that a surrogate key is useful to do loads/merges data on dimensions
    without affecting natural keys on these operations and to save space on fact tables.
    However beyond from this, I miss understanding about the two concepts above.
    Since in the doc is write: "Every level must have two identifiers: a surrogate identifier and a business identifier." -> Oracle® Warehouse Builder User's Guide
    10g Release 2 (10.2) -> 4 Defining Dimensional Objects
    1 - Why do I need obligatory a surrogate identifier on OWB10r2 ?
    2 - Either do I need specify the same surrogate key in each dimension level
    or ever level must be your own surrogate key ?
    3 - What would be the dimension behavior without them ? Moreover couldn't I have
    the same behavior using business identifier instead ?
    Thank you

    Right.
    However, what do you mean about "attributes that are on the lowest level of a hierarchy" ? This means high cardinality ? (A kind of Unique Key/PK ?)
    So, see this sample (originated from products table's Sales History sample schema )
    prod_id.prod_name........prod_subcategory..prod_category.supplier_id.min_price
    ........5.gurfield& murks...trousers - women....women....................170......137.02
    ......10.gurfield& murks...trousers - women....women....................170......155.93
    ......15.coin pocket twi....trousers and jeans..girls..........................30........12.47
    ......20.and 2 crosscour..shirts - boys...........boys.........................83........13.36
    ......25.and 2 crosscour..shirts - boys...........boys.........................83........13.36
    ......30.and 2 crosscour..shirts - boys...........boys.........................83........13.36
    ......35.kahala pleated ...shorts - men...........men........................125........24.48
    What would be the business identifiers ? (suppler_id ?) If yes, it isn't UK. Or aren't there business identifier here ?
    Now suppose that prod_id be surrogate key, ok ? What I undestand about OWB10g, it would put new keys on this table for every level from dimension
    Look the dimension:
    CREATE DIMENSION products_dim
         LEVEL product           IS (products.prod_id)
         LEVEL subcategory      IS (products.prod_subcategory)
         LEVEL category          IS (products.prod_category)
         HIERARCHY prod_rollup (
              product          CHILD OF
              subcategory      CHILD OF
              category
         ATTRIBUTE product DETERMINES
    (products.prod_name, products.prod_desc,
    prod_weight_class, prod_unit_of_measure,
    prod_pack_size,prod_status, prod_list_price, prod_min_price)
         ATTRIBUTE subcategory DETERMINES
    (prod_subcategory, prod_subcat_desc)
         ATTRIBUTE category DETERMINES
    (prod_category, prod_cat_desc)
    The table will look like:
    SQL> desc products
    Name
    PROD_ID_PROD_ID
    prod_name
    prod_desc
    PROD_SUBCATEGORY_PROD_ID
    prod_subcategory
    prod_subcat_desc
    PROD_CATEGORY_PROD_ID
    prod_category
    prod_cat_desc
    prod_weight_class
    prod_unit_of_measure
    prod_pack_size
    Why OWB do that ?
    Thank you very much for your assistance and you patience
    Marcelo Sinni

  • Surrogate or Buisness Identifier during Dimension Creation??

    Hi I am using OWB and I am confused in identifying surrogate or buisness identifiers ?? What are they and how do i know if a certain field is a buisness or surrogate identifier??

    Consider the example where a Customer dimension is sourced from 2 different systems, there is a Customer_ID = 1 in both systems but they releate to different customers.
    In this case you should assign a surrogate key to the data e.g. Customer_ID = 1 from Source System A is given a surrogate key = 100 and Customer_ID = 1 from Source System B is given a surrogate key = 101.
    This enables a FK/Join between the fact table and the dimension on a single colum i.e. the surrogate key, otherwise the join would have to be a composite key of Customer_ID and Source System.
    It's best practice to always use surrogate keys.
    Si

  • 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

Maybe you are looking for

  • How do I avoid re-entrant problems in Oracle JVM

    I have a Java program called LanguageFunctions. This Java program has several methods that translate the data within a String or CLOB. I want to use this Java program as a stored procedure, and specifically the methods as Oracle functions. I want thi

  • My iMessage isn't working when I turn it on

    i turned it off and when i went to turn it back on and it wont let me back in

  • Orga and expense hierarchy in discoverer

    Hi, we currently test the functionality and performance of the discoverer product. hierarchies which can be set up in discoverer (as described in the admin manual) are created using attributes from the underlying table(s). Business Area -> Cost Cente

  • To close the unclosed production orders without imbalancing with invoice

    Hi MRP Experts, I want solution for following situation. Mrp was not implemeted during software implementation. Now we need to implement. But since manual production entry was not done according to invoice there is no link between them. At present i

  • RemoveChild and unload

    It seems like the removeChild and unload method do the same thing. Is it necessary to do both when you're removing the display of an external swf from the stage? Also, after loading in an external file then running code to remove it, whether you use