How to handle 3 different fact tables and measures within a DAX query?

I am writing a DAX query in DAX studio in Excel against a tabular model that has 4 different Fact tables, but they share the same dimensions. (There's some long story I can't get into here, but unfortunately this is the structure) I want to
include measures from the 4 fact tables, summarize by the dimensions in a single query output that can be used for a pivot table.  So far I have something like this:
 EVALUATE
FILTER
    SUMMARIZE
        FactTable1,
        DimensionTable1[Value],        DimensionTable2[Value],
        DimensionTable3[Value],
        Dimensiontable4[Value],
        'dimDateTime'[Month PST],
        DimDateTIme[FiscalYear PST],
        "Measure Score",
        FactTable1[Measure 1],
        "Measure Score 2",
        FactTable1[Measure 2],
    ,Company[CompanyName]="Company ABC" 
What I want to do is summarize the 3 fact tables by the same dimensions, but I am not sure how to do that within a DAX query.  I am getting an error if I try to include another table statement in the original SUMMARIZE function, even though the FACTS
do share the same dimension.  Is there an easy way to do this?

You can use ADDCOLUMNS to add the data from other tables, but you need to use within the SUMMARIZE the fact table that determines the cardinality of the output. If you are not sure (e.g. you project cost and revenues from two fact tables by month and there
could me months with cost and no revenues, but also months with revenues and no costs), then you should use CROSSJOIN and then FILTER.
You query might be written as (please note CALCULATETABLE instead of FILTER to improve performance):
EVALUATE
CALCULATETABLE (
    ADDCOLUMNS (
        SUMMARIZE (
            FactTable1,
            DimensionTable1[Value],
            DimensionTable2[Value],
            DimensionTable3[Value],
            Dimensiontable4[Value],
            'dimDateTime'[Month PST],
            DimDateTIme[FiscalYear PST]
        "Measure Score", FactTable1[Measure 1],
        "Measure Score 2", FactTable1[Measure 2]
    Company[CompanyName] = "Company ABC"
Marco Russo http://www.sqlbi.com http://www.powerpivotworkshop.com http://sqlblog.com/blogs/marco_russo

Similar Messages

  • How to combine multiple fact tables and dimensions in one worksheet?

    Hello Forum,
    I am encountering a reporting problem when trying to create a worksheet that uses more than one cube/fact table and common dimensions. I have used Oracle Warehouse Builder 10Gr2 to design and deploy a pretty simple ROLAP data mart. We are using Discoverer Plus for OLAP as our reporting tool. We have 5 dimension tables using a star schema and 3 fact tables, when I create the worksheet I bring in our sales measure from our sales item table and then Store_Name from my Stores Dimension and then day from my time dimension, everything looks good at the stage, we're just trying to get a sum of all sales for that store on that day. Then I bring in a measure from our advertising cost table and a join window pops up asking which join to use, if I choose either the Store or the Time dimension I get correct data for the first fact table (sales) and grossly incorrect data for the ad cost measure from the second fact table (advertsing costs)...... any help would be appreciated

    You have encountered one of the key limitations of Discoverer... which I complained about to the Discoverer product manager at OpenWorld in 2001....
    Anyhow, to get around this, you are going to have to deal with it either in the database, (views, materialized views, tables), or within the admin tool by creating a custom folder.
    Discoverer also calls this the "fan trap", but never really had a solution to the problem. [The solution only worked is you joined to one and only one dimension!]
    What you want (using Sales_Fact and Inventory_Fact as an example) is to join Sales to Time, Store, and Product, and save that result. Then join Inventory to Time, Store, and Product, save that result, then do a double outer join between the two intermediate temporary tables in order to calculate something useful like inventory turns by store and product line.
    This is also known a "multipass SQL", and is supported by some (but not many) other tools.
    So, to accomplish this with Discoverer, you'll either need to create a view, or table, or materialized view that has already put Sales and Inventory into a single (virtual?) fact table. Alternatively you can write the SQL for how to do this linkage (don't forget to handle missing data), and use the Discoverer admin tool to create a custom folder that uses your SQL.
    Hope this helps!

  • How to resolve many fact tables and Dimensions tables

    Hi,
    The scenario is we have many facts and dimension tables. Based on some conditions one measure from one fact will be divided by another fact measure. I have encoutered with many errors like " Unable to navigate .... " ? How to resolve these errors and reduce many to few ? ( I assume creating logical tables, but is there any other alternatives ? )
    thanks
    Suresh

    Suresh,
    I assume that you know how to create a single logical fact from n-physical facts, ie only if the fact tables are related. Then join all the conformed dimensions to this single Logical table using a join in the Business Model layer. Remember to set the mappings in the LTS. All if you have any hierarchies please set the aggregation level for those.
    - Red

  • How to create solved fact table and corresponding cube

    Hello,
    I want to create cube with solved fact table. It means, i need to feed data for higher levels of dimension also from fact table instead of aggreting from base level.
    I am using star schema and AWM 10g R2 for creating cube.
    If anyone knows how to do this, i would be very benificial.
    Thanks
    Subash

    I have generated parent child script using cwm2_olap_pc_transform.create_script. After running this generated script, it has created 3 table/view.
    My Base Parent Child table is like this:-
    drop table PARENT_CHILD;
    create table PARENT_CHILD (PARENT varchar2(30), CHILD varchar2(30));
    insert into PARENT_CHILD values ('Eligible', 'Compliant');
    insert into PARENT_CHILD values ('Eligible', 'Non-Compliant');
    insert into PARENT_CHILD values ('All', 'Eligible');
    insert into PARENT_CHILD values ('All', 'Ineligible');
    insert into PARENT_CHILD values (null, 'All');
    After running generated script thru cwm2_olap_pc_transform.create_script, it has created :-
    Table - PARENT_CHILD_SOLVED
    View - PARENT_CHILD_SOLVED_view , PARENT_CHILD_view
    This script also inserted data in above table/view. (5 rec in each). Table/View structure is like this:-
    SQL> desc PARENT_CHILD_view
    Name Null? Type
    GID NUMBER
    CHILD1 VARCHAR2(30)
    CHILD2 VARCHAR2(30)
    CHILD3 VARCHAR2(30)
    Data:-
    0 All Eligible Compliant
    0 All Eligible Non-Compliant
    1 All Eligible
    1 All Ineligible
    3 All
    SQL> desc PARENT_CHILD_SOLVED
    Name Null? Type
    GID NUMBER
    CHILD1 VARCHAR2(30)
    CHILD2 VARCHAR2(30)
    CHILD3 VARCHAR2(30)
    Data:-
    0 All Eligible Compliant
    0 All Eligible Non-Compliant
    1 All Eligible
    1 All Ineligible
    3 All
    SQL> desc PARENT_CHILD_SOLVED_view
    Name Null? Type
    GID NUMBER
    SHORT_DESCRIPTION VARCHAR2(30)
    LONG_DESCRIPTION VARCHAR2(30)
    CHILD1 VARCHAR2(30)
    CHILD2 VARCHAR2(30)
    CHILD3 VARCHAR2(30)
    Data:-
    0 Compliant Compliant All Eligible Compliant
    0 Non-Compliant Non-Compliant All Eligible Non-Compliant
    1 Eligible Eligible All Eligible
    1 Ineligible Ineligible All Ineligible
    3 All All All
    I tried to create dim and cube based on this. I am not sure whether its correct or not! Though validate_dimension API call shows that it is valid.
    Script for Dim:-
    DECLARE
    -- variable to hold error message
    errtxt varchar(60);
    BEGIN
    -- To be on safer side just drop dimension before creating new one and catch exceptions
    BEGIN
    cwm2_olap_dimension.drop_dimension('APPS', 'HCP_DIM_PC');
    EXCEPTION
    WHEN OTHERS THEN
    dbms_output.put_line('Dimension HCP_DIM_PC not dropped');
    END;
    cwm2_olap_dimension.create_dimension(
    'APPS',
    'HCP_DIM_PC',
    'Parent Child',
    NULL,
    'Parent Child',
    'Parent Child',
    NULL);
    cwm2_olap_dimension_attribute.create_dimension_attribute(
    'APPS',
    'HCP_DIM_PC',
    'Short Description',
    'Short Description',
    'Short Description',
    'Short Description',
    TRUE);
    cwm2_olap_dimension_attribute.create_dimension_attribute(
    'APPS',
    'HCP_DIM_PC',
    'Long Description',
    'Long Description',
    'Long Description',
    'Long Description',
    TRUE);
    cwm2_olap_dimension_attribute.create_dimension_attribute(
    'APPS',
    'HCP_DIM_PC',
    'Grouping ID',
    'Grouping ID',
    'Grouping ID',
    'Grouping ID',
    TRUE);
    cwm2_olap_hierarchy.create_hierarchy(
    'APPS',
    'HCP_DIM_PC',
    'HCP_DIM_PC_HIER',
    'Standard',
    'Standard',
    'Standard Parent Child Hierarchy',
    'SOLVED LEVEL-BASED');
    cwm2_olap_dimension.SET_DEFAULT_DISPLAY_HIERARCHY ('APPS', 'HCP_DIM_PC', 'HCP_DIM_PC_HIER');
    cwm2_olap_level.create_level(
    'APPS',
    'HCP_DIM_PC',
    'ALL_PARENT_LVL',
    'All Parent Child',
    'All Parent Child',
    'All Parent Child',
    'All Parent Child Level');
    cwm2_olap_level_attribute.create_level_attribute(
    'APPS',
    'HCP_DIM_PC',
    'Short Description',
    'ALL_PARENT_LVL',
    'Short Description',
    'Short Description',
    'Short Description',
    'Short Description',
    TRUE);
    cwm2_olap_level_attribute.create_level_attribute(
    'APPS',
    'HCP_DIM_PC',
    'Long Description',
    'ALL_PARENT_LVL',
    'Long Description',
    'Long Description',
    'Long Description',
    'Long Description',
    TRUE);
    cwm2_olap_level_attribute.create_level_attribute(
    'APPS',
    'HCP_DIM_PC',
    'Grouping ID',
    'ALL_PARENT_LVL',
    'Grouping ID',
    'Grouping ID',
    'Grouping ID',
    'HTB Grouping ID',
    TRUE);
    -- Add all levels one by one to dimension hierarchy. For top most level last parameter is null.
    cwm2_olap_level.add_level_to_hierarchy(
    'APPS',
    'HCP_DIM_PC',
    'HCP_DIM_PC_HIER',
    'ALL_PARENT_LVL',
    NULL);
    BEGIN
    cwm2_olap_table_map.removemap_dimtbl_hierlevel(
    'APPS',
    'HCP_DIM_PC',
    'HCP_DIM_PC_HIER',
    'ALL_PARENT_LVL');
    cwm2_olap_table_map.removemap_DimTbl_HierLevelAttr(
    'APPS', 'HCP_DIM_PC', 'Short Description', 'HCP_DIM_PC_HIER', 'ALL_PARENT_LVL', 'Short Description');
    cwm2_olap_table_map.removemap_DimTbl_HierLevelAttr(
    'APPS', 'HCP_DIM_PC', 'Long Description', 'HCP_DIM_PC_HIER', 'ALL_PARENT_LVL', 'Long Description');
    cwm2_olap_table_map.removemap_DimTbl_HierLevelAttr(
    'APPS', 'HCP_DIM_PC', 'Grouping ID', 'HCP_DIM_PC_HIER', 'ALL_PARENT_LVL', 'Grouping ID');
    EXCEPTION
    WHEN OTHERS THEN
    dbms_output.put_line('Level map for ALL_PARENT_LVL not removed');
    END;
    -- Map ALL_PARENT_LVL level to dimension table. Last parameter is null since it is top most level
    cwm2_olap_table_map.map_dimtbl_hierlevel(
    'APPS',
    'HCP_DIM_PC',
    'HCP_DIM_PC_HIER',
    'ALL_PARENT_LVL',
    'APPS',
    'PARENT_CHILD_SOLVED_VIEW',
    'GID',
    NULL);
    -- one by one map all the level attributes to respective columns in the dimension table.
    cwm2_olap_table_map.Map_DimTbl_HierLevelAttr(
    'APPS',
    'HCP_DIM_PC',
    'Short Description',
    'HCP_DIM_PC_HIER',
    'ALL_PARENT_LVL',
    'Short Description',
    'APPS',
    'PARENT_CHILD_SOLVED_VIEW',
    'SHORT_DESCRIPTION');
    cwm2_olap_table_map.Map_DimTbl_HierLevelAttr(
    'APPS',
    'HCP_DIM_PC',
    'Long Description',
    'HCP_DIM_PC_HIER',
    'ALL_PARENT_LVL',
    'Long Description',
    'APPS',
    'PARENT_CHILD_SOLVED_VIEW',
    'LONG_DESCRIPTION');
    cwm2_olap_table_map.Map_DimTbl_HierLevelAttr(
    'APPS',
    'HCP_DIM_PC',
    'Grouping ID',
    'HCP_DIM_PC_HIER',
    'ALL_PARENT_LVL',
    'Grouping ID',
    'APPS',
    'PARENT_CHILD_SOLVED_VIEW',
    'GID');
    -- Use cwm2_olap_validate.validate_dimension to validate the dimension
    cwm2_olap_validate.validate_dimension('APPS', 'HCP_DIM_PC');
    cwm2_olap_metadata_refresh.mr_refresh;
    -- Rollback if any exception occurs during processing this script
    EXCEPTION
    WHEN OTHERS THEN
    cwm_utility.dump_error;
    errtxt := cwm_utility.get_last_error_description;
    dbms_output.put_line('ERROR: ' || errtxt);
    ROLLBACK;
    RAISE;
    END;
    Script for Cube:-
    declare
    HCP_time_dim number;
    errtxt varchar(60);
    begin
    cwm_utility.collect_garbage;
    begin
    cwm2_olap_cube.drop_cube('APPS', 'HCP_PC_CUBE');
    exception
    when others then
    dbms_output.put_line('No HCP_PC_CUBE to drop');
    end;
    begin
    cwm2_olap_catalog.drop_catalog('HCP_PC_CAT');
    exception
    when others then
    dbms_output.put_line('No HCP_PC_CAT to drop');
    end;
    CWM2_OLAP_CUBE.Create_Cube('APPS', 'HCP_PC_CUBE', 'Parent Child Cube', 'Parent Child Cube','Parent Child Cube');
    cwm2_olap_cube.add_dimension_to_cube('APPS', 'HCP_PC_CUBE','APPS', 'HCP_DIM_PC');
    cwm2_olap_measure.create_measure('APPS', 'HCP_PC_CUBE', 'HCP_PC_MEASURE', 'PC Measure','PC Measure', 'PC Measure Fact');
    cwm2_olap_table_map.map_facttbl_levelkey('APPS','HCP_PC_CUBE','APPS','HCP_PC_FACT','ET', 'DIM:APPS.HCP_DIM_PC/HIER:HCP_DIM_PC_HIER/GID:GID/LVL:ALL_PARENT_LVL/COL:CHILD3;');
    cwm2_olap_table_map.Map_FactTbl_Measure('APPS', 'HCP_PC_CUBE','HCP_PC_MEASURE', 'APPS', 'HCP_PC_FACT', 'MEASURE_COL', 'DIM:APPS.HCP_DIM_PC/HIER:HCP_DIM_PC_HIER/GID:GID/LVL:CHILD3/COL:SHORT_DESCRIPTION;');
    cwm2_olap_catalog.create_catalog('HCP_PC_CAT', 'Parent Child Catalog');
    cwm2_olap_catalog.add_catalog_entity('HCP_PC_CAT', 'APPS', 'HCP_PC_CUBE', 'HCP_PC_MEASURE');
    cwm2_olap_validate.validate_cube('APPS', 'HCP_PC_CUBE','DEFAULT','YES');
    cwm2_olap_metadata_refresh.mr_refresh;
    exception
    when others then
    cwm_utility.dump_error;
    errtxt := cwm_utility.get_last_error_description;
    dbms_output.put_line('ERROR: ' || errtxt);
    rollback;
    raise;
    END;
    My Fact Table is :-
    DROP TABLE HCP_PC_FACT CASCADE CONSTRAINT;
    CREATE TABLE HCP_PC_FACT (
    SHORT_DESCRIPTION VARCHAR2(30) NOT NULL,
    GID NUMBER NOT NULL,
    CHILD1 VARCHAR2(30) NOT NULL,
    CHILD2 VARCHAR2(30) ,
    CHILD3 VARCHAR2(30) ,
    MEASURE_COL NUMBER NOT NULL);
    Data in Fact Table:-
    insert into HCP_PC_FACT values('Compliant',0,'All','Eligible','Compliant', 100);
    insert into HCP_PC_FACT values('Non-Compliant',0,'All','Eligible','Non-Compliant', 200);
    insert into HCP_PC_FACT values('Eligible',1,'All','Eligible',null, 300);
    insert into HCP_PC_FACT values('Ineligible',1,'All','Ineligible',null, 400);
    insert into HCP_PC_FACT values('All',3,'All',null,null, 500);
    I am not sure how to create level, level attr, dim attr for such dim.
    All CWM2 validation API shows that my all dims, cubes are valid but when I try to create presentation thru JDev it hangs after selecting Parent-Child Measure.
    Any complete working exapmle will be helpful.
    P.S. One more query I have can we have one solved and one un-solved dim in the same cube/measure?
    regds
    Prakash

  • Reg: Fact table and Dimension table in Data Warehousing -

    Hi Experts,
    I'm not exactly getting the difference between the criteria which decide how to create a Fact table and Dimension table.
    This link http://stackoverflow.com/questions/9362854/database-fact-table-and-dimension-table states :
    Fact table contains data that can be aggregate.
    Measures are aggregated data expressions (e. Sum of costs, Count of calls, ...)
    Dimension contains data that is use to generate groups and filters.
    This's fine but how does one decide which columns to consider for Fact table and which columns for Dimension table?
    Any help is much appreciated.
    Pardon me if this's not the correct place for this question. My first question in the new forum.
    Thanks and Regards,
    Ranit Biswas

    ranitB wrote:
    But my main doubt was - what is the criteria to differentiate between columns for Fact tables and Dimension tables? How can one decide upon the design?
    Columns of a fact table will often be 'scalar' attributes of the 'fact' data item. A dimension table will often be 'compound' attributes of a 'fact'.
    Consider employee information. The EMPLOYEE table can be a fact table. It might have scalar attribute columns such as: DATE_HIRED, STATUS, EMPLOYEE_ID, and so on.
    Other related information that can't be specified as a single attribute value would often be stored in a 'dimension' table: ADDRESS, PHONE_NUMBER.
    Each address requires several columns to define it: ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY. And an employee might have several addresses: WORK_ADDRESS, HOME_ADDRESS. That address info would be stored in a 'dimension' table and only the primary key value of the address record would be stored in the EMPLOYEE 'fact' table.
    Same with PHONE_NUMBER. Several columns are required to define a phone number and each employee might have several of them. The dimension tables are used to help 'normalize' the data in the employee 'fact' table.
    And that EMPLOYEE table might also be a DIMENSION table for other FACT tables. A DEVELOPER table might have an EMPLOYEE_ID column with a value that points to a 'dimension' row in the EMPLOYEE dimension table.

  • How to handle different Unit of measures in ALV reports? Quantity/Price

    Anyone knows how to handle different unit of measures for quantity or price in hierarchy ALV reports?

    hi,
    use the below fields:
    Link to measurement unit
    •qfieldname (measurement unit field name)
    only relevant for quantity columns with unit link.
    Name of the internal output table field containing the measurement unit associated with the quantity field FIELDCAT-FIELDNAME.
    The field in FIELDCAT-QFIELDNAME must have its own field catalog entry.
    •qtabname (internal measurement unit field output table)
    value set: SPACE, output table field name
    Name of the internal output table containing the FIELDCAT-QFIELDNAME field.
    regards,
    madhumitha

  • Trying to use 2 different Dimension tables and make a hierarchy on some columns which are split into these dimensions .. how do I do that

    Trying to use 2 different Dimension tables and make a hierarchy on some columns which are split into these dimensions .. how do I do that

    If you need to make a hierarchy in an Attribute view you need to have all relevant fields/columns in the same Dimension table..

  • How to join  fields from different internal tables and display into one int

    hai i have one doubt...
    how to join  fields from different internal tables and display into one internal table..
    if anybody know the ans for this qus tell me......

    hii
    you can read data as per condition and then can join in one internal table using READ and APPEND statement..refer to following code.
    SELECT bwkey                         " Valuation Area
             bukrs                         " Company Code
        FROM t001k
        INTO TABLE i_t001k
       WHERE bukrs IN s_bukrs.
      IF sy-subrc EQ 0.
        SELECT bwkey                       " Valuation Area
               werks                       " Plant
          FROM t001w
          INTO TABLE i_t001w
           FOR ALL ENTRIES IN i_t001k
         WHERE bwkey = i_t001k-bwkey
           AND werks IN s_werks.
        IF sy-subrc EQ 0.
          LOOP AT i_output INTO wa_output.
            READ TABLE i_t001w INTO wa_t001w WITH KEY werks = wa_output-werks.
            READ TABLE i_t001k INTO wa_t001k WITH KEY bwkey = wa_t001w-bwkey.
            wa_output-bukrs = wa_t001k-bukrs.
            MODIFY i_output FROM wa_output.
            CLEAR wa_output.
          ENDLOOP.                         " LOOP AT i_output
        ENDIF.                             " IF sy-subrc EQ 0
    regards
    twinkal

  • Are fact tables and cubes same in OWB?

    Dear all
    A simple question. How can I create a star schema (that is, with a fact table and dimensions) using OWB?
    OWB has options to create cubes, but as per my understanding a cube is not a fact table.
    Cube contains pre-computed data where as fact table contains normal data with references to dimensions.
    Please correct me if I am wrong.
    thanks in advance

    These are just different levels of abstraction.
    "Cube" is the highest level of abstraction referring to the overall package of data.
    "Star schema" is how cubes are modelled showing the relationships from a fact entity to the dimension entities.
    Relational and OLAP are different methods of physical implementation.
    In OWB, to promote sharing of dimensions across cubes to avoid inconsistency the idea is you define and build the dimensions independently. Then you define the "cubes" as measures and references to the dimensions. When you build the "cube" you pass in business identifiers from the source data which OWB will use to link the measures to the applicable dimension data. Due to the wonders of inner joins anyone reading the "cube" will only see dimension data related to the data in that cube!
    Using OWB you do not need to be concerned with the physical implementation when you use the dimension and cube operators as those operators know what to do.

  • How to change the fact table in backend query

    Hi
    I have a criteria where f1 is the fact table comming in backend query, how can I change/modify so that if i select same criterian it should come different fact table f2.
    Please suggest.

    Hi Hussain,
    I have a measure 'po amount' which is comming from two fact tables cost_f and line_f from physical layer. I have a implict fact column in presentation layer on a column(internal-row count) from cost_f table.
    Now, when I take only 'po amount ' in criteria, in the backend query it should have cost_f table, but i am seeing line_f table.
    The reason I am checking in this direction is.
    I have criteria with 4 columns and measure column 'po amount' and run the result it is fecting from line_f table.
    The same 4 columns and measure column 'po amount' and one new column 'cost center' is added to the critera the fact table changes to cost_f table.
    In both the cases the result should result from cost_f table, not sure why line_f is comming in backend query.
    Please suggest.

  • Multiple fact tables and dimensions

    I have two fact tables actual sales and planned sales and 8 dimension tables, using a star schema. I want to query on the two fact tables with two dimensions, product and time. When I create the report in discoverer i bring in the sales from actuals and then the product_desc and month_desc. Then I bring in the measure from the second fact table and a join window pops up asking which join to use. If I choose the join to the time dimension then I get no data for the second fact table and correct data for the first fact table. If I choose the product dimension then I get correct data for the first fact table and grossly incorrect data for the second fact table.
    How can I stop this from happening?
    Nick

    Nick,
    I hope you solved your reporting issue and can share the solution with me. I am encountering the same problem. I have used Oracle Warehouse Builder 10Gr2 to design and deploy a pretty simple ROLAP data mart. We are using Discoverer Plus for OLAP as our reporting tool. We have 5 dimension tables using a star schema and have 3 fact tables, when I create the worksheet I bring in our sales measure from our sales item table and then Store_Name from my Stores Dimension and then week-ending from my time dimension, everything looks good at the stage. Then I bring in a measure from our advertising cost table and a join window pops up asking which join to use, if I choose either the Store or the Time dimension I get correct data for the first fact table (sales) and grossly incorrect data for the ad cost from the second fact table (advertsing costs)...... any help would be appreciated
    monalisa

  • Join multiple fact tables and dimensions and use all tables in report issue

    Hi,
    I have a report requirements and need to use multiple fact tables and unconformed dimensions as described below
    Fact table: F1,F2,F3
    Dimensions tables: D1.....D9
    F1:(joined to) D1,D2,D3,D4
    F2::(joined to)D1,D2,D5,D6
    F3::(joined to)D1,D2,D7,D8
    D7::(joined to)D9,D8 (dimension D7 joined to two other dimensions D9 and D8
    I'm trying to use columns from almost all the fact and dimension tables but getting "Unable to navigate requested expression. Please fix the metadata consistency warnings."
    Repository is consistent and no errors and warnings.
    How can I configure the repository to develop reports using all fact tables and dimensions?
    Appreciate for your help.
    Thanks
    Jay.
    Edited by: Jay on Feb 9, 2012 4:14 PM

    So you want me to convert snowflake schema to star. does it solve my problem? individual star queries are working find but when I query multiple stars together getting inconsistency errors. I removed content tables dim level totals for unconformed dimensions in logical fact LTS and set level for measures at total level for unconformed dimensions. it is still in progress and need to test.
    Thanks
    Jay.

  • How to design a fact table to keep track of active dimensions?

    I would like to design a classic OLAP facts table using a star scheme. The SQL model of the facts table should be independent of any concrete RDBMS technology and portable between different systems.
    The problem is this: users should be able to select subsets of the facts based on conjunctive queries on the dimension values defined for the facts. However, the program that provides the interface for doing this to the user should only present those dimensions where anything is still selectable at all. For example, if a user selected year 2001 and for dimension contract code there is only a single value for all records in the fact table for that year, this dimension should not be shown to the user any more. This should be solved in a generic way. So for n dimensions in total, if the current set of facts is based on constraints from j dimensions, I want to know for which of the remaining n-j dimensions there is still something to select from and only show those.
    The obvious way is to make a count(*) query on the distinct foreign keys of each of the dimensions on the fact table, using the same where clause. That means that one would need (n-j) such queries on the whole facts table and that sounds like an awful waste of resources given that the original query for selecting the facts could have done it internally "on the fly".
    How can this be achieved in the most performant way? Is there a "classical" way of how to approach this problem? Is there tool support for doing this efficiently?
    Any help or pointers to where one could find out more about this would be greatly apreciated - thank you!

    >
    Did you get the counts for each value of each dimension by doing a separate query with the current "WHERE" clause on each dimension?
    >
    My method doesn't apply to your use case. I wrote a Java class to create my own bit-mapped indexes on CSV files. So each attribute value was a one million bit binary raw.
    I don't know, and don't want to know, what your particular requirements are. But I can show you a basic process that will work for large numbers of rows. Get a simple process working and then explore to see if it will meet your particular needs. Not going to answer questions here about anything but about my example code
    1. Assume a single fact table with one primary key column and multiple single-value attribute columns.
    2. The table is not subject to DML operations AT ALL - truncate and load if you want apply changes. Meaning it will be useful for research purposes on archived data.
    3. The purpose of the table is to select the fact table ROWIDs for records of interest. So the only value selected is a result set of ROWIDs that can then be used to get any of the normal FACt table data and other linked data as needed.
    Create the table - insert some records, create a bitmap index on each dimension column and collect the statistics
    ALTER TABLE SCOTT.STAR_FACT
    DROP PRIMARY KEY CASCADE;
    DROP TABLE SCOTT.STAR_FACT CASCADE CONSTRAINTS;
    create table star_fact (
        fact_key varchar2(30) DEFAULT 'N/A' not null,
        age      varchar2(30) DEFAULT 'N/A' not null,
        beer    varchar2(30) DEFAULT 'N/A' not null,
        marital_status varchar2(30) DEFAULT 'N/A' not null,
        softdrink varchar2(30) DEFAULT 'N/A' not null,
        state    varchar2(30) DEFAULT 'N/A' not null,
        summer_sport varchar2(30) DEFAULT 'N/A' not null,
        constraint star_fact_pk PRIMARY KEY (fact_key)
    INSERT INTO STAR_FACT (FACT_KEY) SELECT ROWNUM FROM ALL_OBJECTS;
    create bitmap index age_bitmap on star_fact (age);
    create bitmap index beer_bitmap on star_fact (beer);
    create bitmap index marital_status_bitmap on star_fact (marital_status);
    create bitmap index softdrink_bitmap on star_fact (softdrink);
    create bitmap index state_bitmap on star_fact (state);
    create bitmap index summer_sport_bitmap on star_fact (summer_sport);
    exec DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'STAR_FACT', NULL, CASCADE => TRUE);Now if you run the 'complex' query for the example from my first reply you will get
    SQL> set serveroutput on
    SQL> set autotrace on explain
    SQL> select rowid from star_fact where
      2   (state = 'CA') or (state = 'CO')
      3  and (age = 'young') and (marital_status = 'divorced')
      4  and (((summer_sport = 'baseball') and (softdrink = 'pepsi'))
      5  or ((summer_sport = 'golf') and (beer = 'coors')));
    no rows selected
    Execution Plan
    Plan hash value: 1934160231
    | Id  | Operation                      | Name                  | Rows  | Bytes |
    |   0 | SELECT STATEMENT               |                       |     1 |    30 |
    |   1 |  BITMAP CONVERSION TO ROWIDS   |                       |     1 |    30 |
    |   2 |   BITMAP OR                    |                       |       |       |
    |*  3 |    BITMAP INDEX SINGLE VALUE   | STATE_BITMAP          |       |       |
    |   4 |    BITMAP AND                  |                       |       |       |
    |*  5 |     BITMAP INDEX SINGLE VALUE  | AGE_BITMAP            |       |       |
    |*  6 |     BITMAP INDEX SINGLE VALUE  | MARITAL_STATUS_BITMAP |       |       |
    |*  7 |     BITMAP INDEX SINGLE VALUE  | STATE_BITMAP          |       |       |
    |   8 |     BITMAP OR                  |                       |       |       |
    |   9 |      BITMAP AND                |                       |       |       |
    |* 10 |       BITMAP INDEX SINGLE VALUE| SOFTDRINK_BITMAP      |       |       |
    |* 11 |       BITMAP INDEX SINGLE VALUE| SUMMER_SPORT_BITMAP   |       |       |
    |  12 |      BITMAP AND                |                       |       |       |
    |* 13 |       BITMAP INDEX SINGLE VALUE| BEER_BITMAP           |       |       |
    |* 14 |       BITMAP INDEX SINGLE VALUE| SUMMER_SPORT_BITMAP   |       |       |
    Predicate Information (identified by operation id):
       3 - access("STATE"='CA')
       5 - access("AGE"='young')
       6 - access("MARITAL_STATUS"='divorced')
       7 - access("STATE"='CO')
      10 - access("SOFTDRINK"='pepsi')
      11 - access("SUMMER_SPORT"='baseball')
      13 - access("BEER"='coors')
      14 - access("SUMMER_SPORT"='golf')
    SQL>As you can see Oracle is combining bitmap indexes on columns in a single table to implement the same AND/OR complex conditions I showed earlier. It doesn't need any other table to do this.
    In 11g you can create virtual columns and then index them.
    so if you find that the condition 'young' and 'divorced' is used frequently you could create a VIRTUAL 'young_divorced' column and create an index.
    alter table star_fact add (young_divorced AS (case
       when (age = 'young' and marital_status = 'divorced') then 'TRUE' else 'N/A' end) VIRTUAL);
    create bitmap index young_divorced_ndx on star_fact (young_divorced);
    exec DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'STAR_FACT', NULL, CASCADE => TRUE);Now you can query using the name of the virtual column
    SQL> select rowid from star_fact where young_divorced = 'TRUE'
      2  and  (state = 'CA') or (state = 'CO')
      3  /
    no rows selected
    Execution Plan
    Plan hash value: 2656088680
    | Id  | Operation                    | Name               | Rows  | Bytes | Cost
    |   0 | SELECT STATEMENT             |                    |     1 |    28 |
    |   1 |  BITMAP CONVERSION TO ROWIDS |                    |       |       |
    |   2 |   BITMAP OR                  |                    |       |       |
    |*  3 |    BITMAP INDEX SINGLE VALUE | STATE_BITMAP       |       |       |
    |   4 |    BITMAP AND                |                    |       |       |
    |*  5 |     BITMAP INDEX SINGLE VALUE| STATE_BITMAP       |       |       |
    |*  6 |     BITMAP INDEX SINGLE VALUE| YOUNG_DIVORCED_NDX |       |       |
    Predicate Information (identified by operation id):
       3 - access("STATE"='CO')
       5 - access("STATE"='CA')
       6 - access("YOUNG_DIVORCED"='TRUE')
    SQL>
    ----------------------------------------------------------------Notice that at line #6 the new index was used. The VIRTUAL column itselfl doesn't create data for the fact table; the definition only exists in the data dictionary.
    The YOUNG_DIVORCE_NDX is real and does consume space. The tradeoff is additional space for the index but you make the query easier because you don't have to recreate the complex condition every time.
    Oracle can work with the complex condition and combine the indexes so this really only helps the query writer. Your UI should be able to hide the query construction from the user so I would avoid the use of VIRTUAL columns and an additional index until you demonstrate you really need it.
    If you provide users with their own RESULT table to store custom query results you could just store the query name and the set of primary keys from the result set. I used ROWIDs in the example but don't use rowid for a real application - use a primary key value that won't change.
    So your UI would let users construct complext dimension queries for 'young_sportsters' and get a result set of primary keys for that. They could save the label 'young_sportsters' and the primary keys in their own work table. Then you can let them run queries that use the primary keys to query data from your active data warehouse to get any other data it contains.
    >
    Did you get the counts for each value of each dimension by doing a separate query with the current "WHERE" clause on each dimension?
    >
    For an Oracle implementation you need to do a count select for each dimension. I haven't tried it but you might be able to do multiple dimensions in a singe query. One query would look like this>
    -- get the dimension counts
    SQL> select beer, count(*) from star_fact group by beer;
    BEER                             COUNT(*)
    N/A                                 56977
    Execution Plan
    Plan hash value: 1692670403
    | Id  | Operation                | Name        | Rows  | Bytes | Cost (%CPU)| Ti
    |   0 | SELECT STATEMENT         |             |     1 |    12 |     3   (0)| 00
    |   1 |  SORT GROUP BY NOSORT    |             |     1 |    12 |     3   (0)| 00
    |   2 |   BITMAP CONVERSION COUNT|             | 56977 |   667K|     3   (0)| 00
    |   3 |    BITMAP INDEX FULL SCAN| BEER_BITMAP |       |       |            |
    SQL>Notice that Oracle uses only the index to gather the data.

  • Same dimension in two different fact tables

    Hi,
    I have one same dimension in two different fact tables. I would like to know how BI server choose the fact table when I do a request in this dimension.
    I know that is always using the same fact table, but I would like to know why choose this table and not the other.
    Thanks

    Sorry,
    But it doesn't seem to me.
    I reorded the tables in the BMM layer and it continues to use the same table, regardless this table is in last.
    After, I droped that table in the BMM layer and it continued to use the same.
    Thanks for your reply

  • OBIEE-can we link two dimension tables belonging to different fact tables?

    Hi ,
    I have just started with OBIEE concepts....need your views on this issue:
    Fact 1 -> Dim 1, Dim2,Dim3 and so on..
    Fact 2 -> Dim a, Dim b,Dimc and so on...
    If I link Dim1 and Dim a with a valid key ,would that distort the star schemas to slowflake in BMM layer?
    Thanks in advance!
    Neha

    I don't see this that would make it snowflake more like what I think as conforming dimensions. You need to make sure the grain of the measures is at what level , the they are same grain then you should be good however if they are different then you would start seeing null values.
    Fact Measures use the same, conformed dimensions like Dim1 and Dim a if you trying to generate from multiple facts, the BI server was able to automatically stitch them together into a single result set. If they came from the same fact table that's easy as its only one single table, but if you are pulling from different fact tables, the conformed dimensions would allow them to be stitched into the same report
    Conformance means that these sources can be mapped to a common structure – the same levels – and also the same data members.
    Mark if helps.
    Thanks,
    SVS

Maybe you are looking for