Dimension table sharing

Hi, Gurus,
     If two(or more) cubes have some same dimensions, how are they sharing the dimension tables like SAP says? I think they can't because they have different dimension table names even they have the same infoobjects in it.
     Am I right? this is a performance issue.

Hi Kunlun,
In my mind I don't know cubes can share dimension tables.
For example, even if you have two cubes with the same structure, they will have own dimension tables and fact tables.
When you first time activate a cube named CUBENAME, the system will automatically generate the following tables:
Dimension table:
/BIC/DCUBENAMEXX
Fact table:
/BIC/FCUBENAME
So for different cubes, the dimension tables' names are different.
For the performance aspect, sharing dimension will save disk space but will not benefit the query performance. You can image if system shares dimension for one big cube and one small cube, the query execution time on the small cube will be longer.
Regards,
Frank

Similar Messages

  • In Answers am seeing "Folder is Empty" for Logical Fact and Dimension Table

    Hi All,
    Am working on OBIEE Answers, on of sudden when i clicked on Logical Fact table it showed me as "folder is empty". I restarted all the services and then tried still showing same for Logical Fact and Dimension tables but am able to see all my reports in Shared Folders. I restarted the machine too but no change. Please help me out to resolve this issue.
    Thanks in Advance.
    Regards,
    Rajkumar.

    First of all, follow the forum etiquette :
    http://forums.oracle.com/forums/ann.jspa?annID=939
    React or mark as anwser the post that the user gave.
    And for your question, you must check the log for a possible corrupt catalog :
    OracleBIData_Home\web\log\sawlog0.log

  • Multiple Hierarchies from Single Dimension Table in OBIEE-11g?

    Is it possible to have Multiple Hierarchies from Single Dimension Table in OBIEE-11g?
    Like 1)Year-Qtr-Month-Weeks 2)Year-Month-Days

    Hi,
    or if your lowest level is the same like
    Day->month->year->Total
    Day->businessMonth->businessyear->Total
    Then yes, it is.
    Create the first, then you start to create the second by adding your top(business year) level on the same level as the one you have (year) both under your total.
    Then when you would add your second base level, there is a special option for it, something like use other hierarchy level/shared level (sorry can't recall and does not have a connection right now) then you select your existing day level under your businessmonth level.
    Hope this helps,
    Regards,
    D

  • Dimension table and fact table exists data physically

    Hi experts,
    can anyone plz tell me weather dimension table and fact table exists data physically or not/

    Hi..Sudheer
    SAPu2019s BW is based on "Enhanced Star schema" or "Info Cubes" database design.This database design has a central database table, known as u2018Fact Tableu2019 which is surrounded by associated dimension tables.
    Fact table is surrounded by dimensional tables. Fact table is usually very large, that means it contains
    millions to billions of records.
    These dimension tables doesn't contain data  it contain references to the pointer tables that point to the master data tables which in turn contain Master data objects such as customer, material and destination country stored in BW as Info objects. An InfoObjects can contain single field definitions such as transaction data or complex Customer Master Data that hold attributes, hierarchy and customer texts that are stored in their own tables.
    SID is surrogate ID generated by the system. The SID tables are created when we create a master data IO. In SAP BW star schema, the distinction is made between two self contained areas: Infocube & master data tables/SID tables.
    The master data doesn't reside in the satr schema but resides in separate tables which are shared across all the star schemas in SAP BW. A numer ID is generated which connects the dimension tables of the infocube to that of the master data tables.
    The dimension tables contain the dim ID and SID of a particular IO. Using this SID the attributes and texts of an master data Io is accessed.
    The SID table is connected to the associated master data tables via teh char key.
    Fact table(Transaction data,DIM ID)<>Dimention Table(SID and Dim ID)<->Masterdata table(SID,IO)
    Thanks,
    Abha

  • Help on  Setting logical Levels  in Fact tables and on Dimension tables

    Hi all
    Can any body provide any blogs or any king of material on what exactly is levelling .
    Like after creating the Dimensional hierarchies we need to set the logical levels for the LTS of fact tabels ri8 .So what is the difference between setting logical levels to fact tabels and also Setting levelling on Dimension tables .
    Any kind of help is appreciated
    Thanks
    Xavier.
    Edited by: Xavier on Aug 4, 2011 10:50 AM

    I have read these blogs ,but what my question is
    Setting the logical levels in LTS of Fact tables i understood .
    But we can also set the logical levels for dimensions also ri8 .I didn't understand why do we set the logical levels for dimensions .Is there any reason why we go with the levelling at dimensions
    Thanks
    Xavier
    Edited by: Xavier on Aug 4, 2011 2:03 PM
    Edited by: Xavier on Aug 4, 2011 2:32 PM

  • Best practice when FACT and DIMENSION table are the same

    Hi,
    In my physical model I have some tables that are both fact and dimension table, i.e. in the BMM they are of course separated into Fact and Dim source (2 different units) and it works fine. But I can see that there will be trouble when having more fact tables and I e.g. have a Period dimension pointing to all the different fact tables (different sources).
    Seems like the best solution to this is to have an alias of the fact/transaction table and have 2 "copies" of the transaction table (one for fact and one for dimension table) in the physical layer. Only bad thing is that there will then allways be 2 lookups in the same table when fetching data from the dimension and the fact table.
    This is not built on a datawarehouse - so the architecture is thereby more complex. Hope this was understandable (trying to make a short story of it).
    Any best practice on this? Or other suggestions.

    Id recommend creation of a view in the database. if its an oracle DB, materialised views would be a huge performance benefit. you just need to make sure that the MVs are updated when the source is updated.
    -Domnic

  • How to show current date in a column of dimension table in ssas

    Hi,
    I have 2 dimension tables (ALLWORK and YOURWORK) and 1 measure table (STATS). In ALLWORK dim table, I have 4 columns, one of them is END_DATE. Based on END_DATE and current date I want to create a named calculation field. To achieve this, I
    want to show the current date in 5th column (of ALLWORK dim table) as calculated member (as named calculation wont show me correct date).
    Problem is, I am not able to create the column in the dimension table. While creating the calculated member, I am not able to select the ALLWORK dimension table, it always selects MEASURE by default. Please help.
    thanks
    Tarique
    thanks and regards Tarique Aslam

    Hi Tarique,
    According to your description, you want to add a column to your dimension to show the current date, right?
    In data source view, we can add named calculation to your table. A named calculation is a SQL expression represented as a calculated column. This expression appears and behaves as a column in the table. A named calculation lets you extend the relational
    schema of existing tables or views in a data source view without modifying the tables or views in the underlying data source.
    Reference
    http://msdn.microsoft.com/en-in/library/ms174859.aspx
    http://devmau5.wordpress.com/2010/03/25/the-getdate-of-mdx/
    If I have anything misunderstand, please point it out.
    Regards,
    Charlie Liao
    TechNet Community Support

  • Multiple columns from the same dimension table as row labels performing slowly

    (Working with SSAS tabular)
    I'm trying to figure out what the approach should be for the following scenario:
    Lets say we have a Customer table. The table has columns such as account number, department number, name, salesperson, account manager, number of customers, delivery route, etc
    A user of the model could want to see any permutation of that information as the row labels. How should that be handled?
    What we've been doing so far is that the user adds each column they want into the "ROWS" section in Excel. This works fine with smaller tables (for example, "Department" table with a "Department Code" and "Department Name",
    but on large tables this quickly chokes. I understand why this is happening, I just haven't found a better way to accomplish the same thing.
    I can add a calculated column to the model through VS, but obviously this is unsupportable and unscalable when each person needs their own permutations of the data. Can something similar be done in Excel? 
    This question seems to be what I need:
    http://social.msdn.microsoft.com/Forums/en-US/97d1157a-1402-4227-b96a-79524401ddcd/mdx-query-performance-when-selecting-multiple-attributes-from-same-dimension?forum=sqlanalysisservices
    However I can't find any information on how to add those properties (is it a multidimensional-only thing?)

    Thanks for the help. Sorry but i'm a self-taught developer, and i may be missing some basics :)
    Anyway i've done what you suggested but i get this error:
    [nQSError: 15011]The dimension table source Dimension Services.DM_D_SERVIZI_SRV has an aggregate content specification that specifies the level Product. But the source mapping contains column COD_PRODUCT with a functional dependency association on a more detailed level .
    where:
    - DM_D_SERVIZI_SRV is the physical alias for the Service Dimension (and the name of the LTS too)
    - COD_PRODUCT is the leaf of the hierarchy, the physical primary key, but it hasnt to be included in the hierarchy
    Do i have to add another level with the primary key and hide it to the users?
    I tried to solve this going to the logical tables source properties, on the tab contents, setting "logical level" to null for the hierarchy, but i don't know if this is correct.
    Thanks

  • 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 to find out the infoProvider for a given dimension table?

    Experts:
    In RSA1, I want to find out the infoProvider for a given dimension table.
    But I am not sure how to display the tables linked to a given infoProvider.
    Could you provide a way to display all tables linked to a given infoProvider?
    Thanks a lot!

    See, The dimension table starts with Dcubename1 and incremental Dcubename2 .... so on
    Ex.ZSD_C01 is your cube name
    Dim tables starts for this is /BIC/DZSD_C011 /BIC/DZSD_C012 ...
    Goto - LISTSCHEMA  - derive cube name from given dim table and enter cube name  - execute - will show you all the tables

  • Should my dimension table be this big

    Im in the process of building my first product dimension for a star schema and not sure if im doing this correctly. A brief explanation of our setup
    We have products (dresses) made by designers for specific collections each of which has a range of colors and each color can come in many sizes. For our UK market this equates to some 1.9 million
    product variants. Flattening the structure out to Product+designer+collection gives about 33,000 records but when you add all the colors and then all the colors sizes it pumps that figure up to 1.9million. My “rolled own” incremental ETL load runs
    ok just now, but we are expanding into the US market and our projections indicate that our products variants could multiple 10 fold. Im a bit worried about performance of the ETL just now and in the future.
    Is 1.9m records not an awful lot of records to incrementally load (well analyse) for a dimension table nightly as it is never mind what that figure may grow to when we go to US?
    I thought of somehow reducing this by using a snowflake but would this not just reduce the number of columns in the dimensions and not the row count?
    I then thought of separating the colors and size into their own dimension, but this doesn’t seem right as they are attributes of products and also I would lose the relationship between products,  size & color I.e. I would have to go through the
    fact table (which ive read is not a good choice.) for any analysis.
    Am I correct in thinking these are big numbers for a dimension table? Is it even possible to reduce the number somhow?
    Still learning so welcome any help.
    Thanks

    Hi Plip71,
    In my opinion, It is always good to reduce the Dimension Volume as much as possible for better performance.
    Is there any Hierarchy in you product Dimension?.. Going for a snowflake for this problem is a bad idea..
    Solution 1:
    From the details given by, It is good to Split the Colour and Size as seperate dimension. This will reduce the vloume of dimension and increase the column count in the fact(seperate WID has to be maintained in the fact table). but, this will improve the
    performance of the cube. before doint this please check the layout requirement from the business.
    Solution 2:
    Check the distinct count of Item varient used in fact table. If it is very less, they try creating a linear product dimension. i.e, create an view for the product dimension doing a inner join with the fact table. so that only the used Dimension member will
    be loaded in the Cube Product Dimension. hence volume is reduced with improvement in performance and stability of the cube.
    Thanks in advance, Sorry for the delayed reply ;)
    Anand
    Please vote as helpful or mark as answer, if it helps Regards, Anand

  • Issue using one 2 Fact tables with one dimension Table.

    Hi,
    I have 1 Dimension table X and 2 Fact tables A and B
    X is joined to Both A and B for Loan Amount ( with A) and for colleatral amount (with B) when I am selecting the X.Product_Name, A.Loan_Amt, B.Collateral Amount, it is giving an error message
    State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 15018] Incorrectly defined logical table source (for fact table EIP Collateral FACT) does not contain mapping for [EIP Reporting FACT.PD ID]. (HY000)
    Any clues???
    Is there a Inner or Outer join which needs to be created or set in the RPD to get the desired results???

    Ok..
    I have one table which is Porfolio Details which has Portfolio name, Product Category , Product Name, Product ID, Product sources code.- This is my Dimension table.
    I have another 2 set of fact tables : EIP Reporting FACT and EIP Collateral FACT..
    These two tables are joined to Portfolio Details table.
    EIP Reprting FACT gives portfolio wise Loan Amount
    and EIP Collateral FACT gives Portfolio wise Collateral Amount details for same set of customer..
    Now, I am selecting Portfolio Name, Product Category, Product Name,SUM( EIP Reporting FACT.LOAN_AMOUNT), SUM(EIP Collaetral FACT.Collateral_Amt) in a report
    Now, on selecting these columns I am getting that error message which is related to mapping.
    If I take any column from Portfolio details table and any column from EIP Reporting FACT- It works.
    If I take any column from Portfolio details table and any column from EIP Colletral FACT- It works.
    But if I take any column from portfolio table and columns from both FACT tables it gives mapping error...
    Hope I am able to explain the issue in a better way now..
    Edited by: help-required on Mar 11, 2010 6:53 PM
    Edited by: help-required on Mar 11, 2010 6:53 PM

  • Consistency Warning - [39008] Dimension Table not joined to Fact Source

    I have a schema in which I have the following tables:
    A) Patient Transaction Fact Table (i.e. supplies used, procedures performed, etc.)
    B) Demographic Dimension table (houses info like patient location code)
    C) Location Dimension table (tells me what Hospital each unique Location maps to)
    So table A is the fact, and table B is a dimension table joined to table A based on Patient ID, so I can get general info on the patient. This would allow me to apply logic to just see patient transactions where the patient was FEMALE, or was in the Emergency Room, by applying conditions to these fields in table B.
    Table C is a simple lookup table joined to table B by Location Code, so I can identify which hospital's emergency room the patient was located in for instance.
    So the schema is: A<---B<---C, where B and C are both dimension tables.
    The query works as desired, but my consistency check gives me the following WARNING:
    *[39008] Logical dimension table LOCATION MASTER D has a source LOCATION MASTER D that does not join to any fact source.*
    How do I resolve this WARNING, or at least suppress it?

    Hi,
    What you need to do is to add the (physical) location dimension table to the logical table source of the demographic dimension, for example by dragging it from physical layer on top of logical table source of demographic logical dimension table in bmm layer
    Regards,
    Stijn

  • Multiple Fact Tables and Dimension Tables

    I have been having some problems trying to model the data from Oracle E-Business Suite maintenance. I will try to give the best description of how the data is held in the tables. The structure is such that a work order can have multiple operations and an operation can have multiple resources as well. I believe the problem comes in the fact that an operation doesn't necessarily need to have a resource. I could not attach an image so I have written out an example below. I am not saying this is right or that it works, but just to give you an idea of what I am thinking. The full dimension would be Organization -> WorkOrder -> Operation -> Resource. Now, the fact tables all hold factual data for the three different levels, with the facts being at each corresponding level. This causes an obvious problem in combining the tables into one large fact table through the ETL process.
    Can anyone tell me if they think this can be done? Am I way off? I am sure that there is a solution as there always is but I have been killing myself trying to figure this one out. I currently have the entire solution in different Business Models. I would like however to be able to compare facts from multiple areas such as the Work Order level and the Resource level.
    Any help is greatly appreciated. I realize that the solution may also require additional work on the ETL side so I am open to any and all suggestions.
    Thank you in advance for anyones time. :)
    Dimension Tables
    WorkOrder_D
    Operation_D
    Resource_D
    Organization_D
    Fact Tables
    WorkOrder_F
    Operation_F
    Resource_F
    Joins
    WorkOrder_D -> Operation_D
    Operation_D -> Resource_D
    WorkOrder_D -> WorkOrder_F
    Operation_D -> Operation_F
    Resource_D -> Resource_F
    Organization_D -> WorkOrder_D
    Organization_D -> Operation_D
    Organization_D -> Resource_D

    Hi,
    Currently the dimension table is taken as a simple logical table in rpd as it does not have have any levels or hierarchy.
    Its a flat dimension. Can you guide me how can I implement a flat dimension in OBIEE? Because this dimension is taken as simple logical table
    I am not able to set appropriate level for fac tables. This dimension does not appear in the list of dimensions.

  • Static and small dimension table should I use lookup

    Hi Gurus,
    I am creating interface to load my fact table.
    Generally for different codes to replace with surrogate keys I use dimension table for look-up in interface.
    but I have question if dimension table is very small and has only static values like
    Sur_key, Code, Description.
    1, C, Create
    2 , R, Redeem
    in such case if in interface for fact table, I just write expression "if source_table.column=C then 1 else 2".
    Please advice if this is better way or not.
    Thanks in advance.

    I agree - it is much better practice to use lookups to populate surrogate keys. Using hard-coded values in code requires the developer to always remember that dependency on dimensional data and can cause unexpected results down the line if the keys are updated or are inconsistent across environments.

Maybe you are looking for