Mapping dimension table to fact table in admin tool 10g

Hi
I have a criteria when it is run uses fact 1 as fact table and gives result, and when I add new column to this criteria an extra dimension(dim1) gets added to query backend and fact 1 changes to fact2.
The problem I am facing over here is both should result same amount for records. but due to new column from dim1 and new fact table fact2the amount varies and inaccruate results have come.
When I have checked the sources for Fact in logical layer i can find these facts(fact1,fact2) where fact 1 is not mapped with dim 1 and fact 2 is mapped with dim1.
Will mapping dim1 to fact1 will solve my problem.. And what would be the steps to add/map dim1 to fact1.
Please suggest.

I just checked back the setting and here are the changed details again.
I have a criteria where when it is run, the backend query is formed with f1 fact table.
And for the same criteria when I add a column c1, the backedn query is formed with f2 fact table and f1 is no more here and one new dimension d1 consisting c1 is getting added.
In both the cases results are different..the expected thing is same results.
Note:
d1 is connected to f2 checked in physical diagram
d1 is not connected to f1 checked in physical diagram.
when I checked the connection between three table in physical diagram. Only d1 and f2 are connected and f1 is not connected to either of table. How to go about this issue.
Please suggest.

Similar Messages

  • Number of Entries in Dimension Tables and Fact Tables

    Hi all,
    is there an easy way to check
    - the number of entries in the dimension tables
    - the number of entries in the fact table?
    Thanks  a lot
    Alex

    Hi Alex,
    If u want to see the content of Dimension table and Fact table for a infocube then just right click on a particular info cube then select manage . Select coneten tab there , form there u can either select Fact table to see the fact table conten or Infocube content to see the Dimensiontable content.
    Regards..

  • 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

  • 3 confirmed Dimensions and 2 fact tables

    Hi experts,
    how can we connect 3 confirmed Dimensions and 2 fact tables without loops and traps please give me a solution

    Hi,
    Dimensions Tables : Dimension tables are typically small, ranging from a few to several thousand rows. Occasionally dimensions can grow fairly large, however. For example, a large credit card company could have a customer dimension with millions of rows. Dimension table structure is typically very lean, for example customer dimension could look like following:
        Customer_key
        Customer_full_name
        Customer_city
        Customer_state
        Customer_country
    Fact Tables :a fact table consists of the measurements, metrics or facts of a business process. It is often located at the centre of a star schema or a snowflake schema, surrounded by dimension tables.
    Fact tables contain keys to dimension tables as well as measurable facts that data analysts would want to examine. For example, a store selling automotive parts might have a fact table recording a sale of each item. The fact table of an educational entity could track credit hours awarded to students. A bakery could have a fact table that records manufacturing of various baked goods.
    Context Versus Alias Overview :
    http://www.dagira.com/2009/07/22/context-versus-alias-overview/
    How to create context :
    http://www.bidw.org/business-objects/universe-design/understanding-context-and-its-use-in-business-objects-universe/
    You can also look on the eFashion universe for more information.
    Thanks,
    Amit

  • How many line item dimensions can a fact table have?

    Hi,
    How many line item dimensions can a fact table have? Is it tht Max of 16 dimensions(13+3) .Does the 16 dimensions include line items dimensions as well .
    Pls reply.
    Thanks
    Praveen

    It includes all dimensios, including line item dimensions.
    If you have line item dimension, pl note you cant assign any other characteristic to that dimension.
    Ravi Thothadri

  • Problem using same dimension in 2 Fact tables

    Hi,
    I am facing this strange problem with the out-of-box BMM metadata mapping :
    The "Dim_W_GL_ACCOUNT_D" is joined to "Fact_W_GL_OTHER_F" and "Fact_W_GL_BALANCE_F" facts. Both these fact tables have a inner join to "Dim_W_GL_ACCOUNT_D". The change I have made in th BMM is - I added 2 new logical dimensions DimA and DimB and joined these to the above 2 fact tables.
    The O-O-Box "GL Account Balance" Report works fine which has 3 logical columns (GL Account Number, Financial Statement Item, GL Account Category) from the "Dim_W_GL_ACCOUNT_D" and 1 Fact column "Closing Amount" which points to the "Fact_W_GL_BALANCE_F"."BALANCE_GLOBAL1_AMT" fact.
    When I add 1 logical column each from my 2 new Dims I created, the report output shows the Fact column "Closing Amount" as $0.0. Upon investigating the log, the query shows it is using the "Fact_W_GL_OTHER_F" instead of "Fact_W_GL_BALANCE_F" fact which has the "Closing Amount" column. I am not sure how. When I drop the logical column "GL Account Number" and keep my 2 new logical columns in the request, the "Closing Amount" is shown correctly. I also saw there is a Dim Hierarchy for "GL Accounts" --- the "GL Account Number" is on a lower level than the "Financial Statement Item" and "GL Account Category" columns from the same logical dimension table which are 1 level higher.
    How do I make the request pull data at the "GL Account Number" level and still have the query fetch data from "Fact_W_GL_BALANCE_F"."BALANCE_GLOBAL1_AMT" (Closing Amount) with my 2 new logical columns included?
    Any help is appreciated. Thanks a bunch.

    The dimensions I added are aliases of their respective W_XXX_D tables and I have the content levels set for the LTS of my Dims (DimA and DimB) at the detail level. One thing I am not able to figure out is why is it going after "W_GL_OTHER_F /* Fact_W_GL_OTHER_F */" when it should go to W_GL_BALANCE_F and W_GL_BALANCE_A.
    The "GL Account Number" is sourced from the W_GL_ACCOUNT_D table and the other columns "Fin Statement Item" (FIN_STMT_ITEM_CODE) and "GL Account Category" (GL_ACCOUNT_CAT_CODE) are sourced from that same table too. But these 2 cols are on a higher level of hierarchy than the "GL Account Number" in the "GL Accounts" Dim-Hierarchy. But, as soon as I remove the "GL Account Number" logical column from the report the closing amounts show fine although the "Fin Statement Item" and "GL Account Category" cols from the W_GL_ACCOUNT_D table remain. Then the query does not show the W_GL_OTHER_F table in the log. Is there something I need to do to this dim-hierarchy?

  • Regarding  Dimension Table and Fact table

    Hello,
    I am having basic doubts regarding the star schema.
    Let me explain first regarding  star schema.
    Fact table containes Key fiigures and Dim IDs,Ok,
    These DIm ids will be connected to my dimension tables.The Dimension table contains Characterstics and these Dim ids ,Ok.
      Then My basic doubt
    1.How does DIm id will be linked to SID tables
    2.If I have not maintained any master data or text or Heirachies then SID tables will it be generated or not?
    3.If it is generated I think there is use of This SID now..as we have not  maintained Master data.
    4.I am haing 18 characterstic which are no way related to each other in that scnerio how does Dimensions have to identified.?or we need to inclued whole chracterstics in one dimensions or we need to create seprate dimesnions for each of them..?(max is 13 dimensions)
    5.If Dimension table contains dim ids and characterstics then where does the  values for characterstics will be stored...?
    ( for ex..sales rep is characterstics for this we will be giving values some names where does these values will be stored..)

    hi Vasu,
    e.g we have infocube with 
    - dimension 'location' -> characteristic 'sales rep', 'country' 
    - dimension 'partner'.
    fact table
    dim-id('sales person') dim-id('partner') revenue
    1001                   9001              500
    1002                   9002              300
    1003                   9004              200
    dimenstion table 'location'
    dim-id  sid-id(sales rep) sid-id(country)
    1001    3001              5001
    1002    3004              5004
    1003    3005              5001
    'sales rep' sid table
    sid   sales rep
    3001  abc
    3004  pqr
    3005  xyz
    'country' sid table
    5001      country1
    5004      country2
    so from the link dim-id and sid, we get
    "sales rep report"
    sales-rep   revenue
    abc        500
    pqr        300
    xyz        200
    "country report"
    country    revenue
    country1   700
    country2   300
    hope it's clear.

  • What is correct way to join a start/end date driven dimension to a fact table in data foundation?

    I have a bad universe or a data design issue. 
    Several versions of hierarchies reporting store entities in reporting Fact measures.
    Example of date driven Hierarchy Dimension:   ORG_KEY
                                                                                START_DATE
                                                                                END_DATE
                                                                                STORE_NUMBER
                                                                                ORG_HIERARCHY   
                                                                                CURR_FLG   (Y/N)        
    Fact table  :                                                         ORG_KEY
                                                                                 CALENDAR_KEY
                                                                                 TRANS_DATE
                                                                                 $amount  
    Calendar Dimension:                                            CALENDAR_KEY
                                                                                  DAY_DATE
                                                                                   FY_WEEK          (201452)
                                                                                    FY_PERIOD      (201412)
                                                                                    FY_QUARTER   (201401)
                                                                                     FISCAL_YEAR    (2014)
    Users WISH:
    Wish for store number and org hierarchy to pull as of the last day of each pull without prompt.    The Store(ORG_KEY) as in the fact table; but the ORG_HIERARCHY and other attributes as of the last day they pull.
    Daily (Would be Calendar.Day_Date in Filter) ,
    Week to date (would be Max Calendar.Day_Date for (201452) FY_WEEK  as entered,
    Month to date,
    Year to date, 
    AdHoc queries.  
    My problem is I see how they could manually pull this in Webi.   I have tried everything I know to join to no avail.  I have not gotten @Prompts to work in joins, derived tables, etc.  in the data foundation.  Wonder what is difference between parameter in Data foundation vs. filter in buisness layer.    None of them worked. 
    Please help!   ANY ideas would be appreciated.   .

    {Note that abbrevations in brackets are just for short form further down the answer}
    Join Store Dim (SD) to Transaction Fact (TF) on ORG_KEY=ORG_KEY with 1 to Many cardinality
    Create an alias of Calendar Dim and call it Transaction Date (TD)
    Join TD to TF on TD.CALENDAR_KEY=TF.CALENDAR_KEY with 1 to Many cardinality
    Create a predefined condition in your universe called "Return Yesterday's Transactions" as:
    TD.DAY_DATE = trunc(sysdate-1) <-- That assumes Oracle database; use whatever is correct for yesterday for your RDBMS
    The above predefined condition when added to your data query will return only yesterday's transactions.
    However, if you want to return all the different types of sales, you would need an object for each one. To do that, you'd use a case statement. Again, using Oracle syntax, an example of MTD would be:
    SUM(CASE WHEN trunc(TD.DAY_DATE,'yyyymm') = trunc(sysdate,'yyyymm') THEN TF.amount END)
    If you have any more questions about how this approach would work please shout.
    As an alternative, you could create a time hierarchy and add scope of analysis to your report for it and enable drilling at report level.

  • Dimension Table and Fact Tables

    Hi,
      Is there any way to see the Dimension Table contents and Fact Table Contents.
    For eg:-  I should be able to see the DIM ID and the SID's of a Dimension.

    Well you can see them in SE11, by giving the table name.
    Go to list schema and give the cube name. It will display all the table for that cube. Give the table name in SE11 or SE16 and see the content there.

  • Conformed dimensions across several fact tables

    Hi, not exactly sure how to phrase my question, so I'll just start babbling and maybe it'll come across. In our OBIEE repository (from BI applications "project analytics"), we have dimensions of CONTRACT, CONTRACT LINE, PROJECT, and TASK (CONTRACT and CONTRACT_LINE really come from a single dimension table, but are different rows and so really can be thought of as coming from two different dim tables). TASKs are really children of projects - but they were broken out into a separate dimension in the data model (no idea why....). Also, in our business, a task can be tied to one and only one contract line.
    Now here's the rub - because TASK is a separate dimension from PROJECT, there is really nothing that relates them except through a fact table. This is a real pain, as it has two limitations:
    1) If a "fact" for that combination of PROJECT / TASK hasn't happened yet, then no row in fact table = nothing that says they are related
    2) Even if you do have a fact for everything - now our query is scanning through a fact table of (in our case) 300+ million rows, just to say which task is tied to which project
    I'd like to solve this by creating a very simple "factless fact" which has columns for CONTRACT, CONTRACT LINE, PROJECT, and TASK, and simply inserts the appropriate surrogate IDs (wids) into this. Thus, instead of a 300+ million row fact table, we should be down to only 400,000 or so task / project / line / contract combos.
    Now here's my question: I have a "combined" subject area that includes a project cost, project revenue, project billing, and in theory this new fact table I'm talking about. I'd want to set the new fact table to be the "implicit" fact - so that if someone just asks a questions like "show me contract lines, and which projects and tasks are assigned to it" - it would go to the new, slim, fast fact table.
    But I'm concerned about what happens when someone then throws in a cost amount, revenue amt, etc. onto the query. I'm assuming that OBIEE will be smart enough to understand it should forget the implicit fact, and start using the "real" facts. Or maybe use all of them including the new fact.
    I'm just trying to see if I can anticipate this causing any issues.
    Thx,
    Scott

    You are correct, the implicit fact will only be used when there isn't any other fact measure defined in your query. Unfortunatelly you can only define an implicit fact per SA, we would love to be able to have more flexibility such as defining them per dimension etc. Another way to "force" OBIEE to select from an specific fact is to select a column from it in your Answers query. You don't to see this column in output so you can hide it. Of course this "hack" is not really very user friendly as it makes adhoc query building much more complex.

  • Relationship between Dimension without linking Fact table

    Hi,
    My question is like I have five dimensions connected to a fact table through primary - foreign key(Composite Key) relationship. Will this referential integrity help if I want some information between two dimension which are not linked directly and I am not
    including any measures from fact table .
    Example: Suppose I have customer, Product and Manufacturer Dimensions all linked to a fact table but  not linked to each other directly  but can I get right result when I want to know what are the manufacturer for each product? or list of
    customers using a particular product. Will the referential integrity work ? since they all are related in fact table.
    regards
    Sanjoy ghosh 

    Hi Sanjoy -
    The answer to your questions depends on your dimensional design and exactly what the fact table represents.  Fact tables naturally capture the intersection of the different dimensions.  This is true whether you physically implement a
    PK - FK relationship in the relational db.  
    In your case, since customer is involved, sounds like a sales transaction fact.  If that's true, you can easily join from customer, through the fact, to the product dimension, to get the list of customers that purchased a particular product.
    For the manufacturer for each product, a sales transaction fact will not necessarily answer this question completely.  Particularly in the case of products that have no sales for a given period, and thus, don't have any fact records to join from manufacturer
    across to product.  If you need to solve this question, you have some other options:
    - flatten the Manufacturer directly into the Product dimension as attribute of the product (probably the simplest approach and allows you to remove a key from the fact)
    - embed the Manufacturer key directly in the Product dimension (if you need the Manufacturer dimension separate for use with other events / facts and more detailed dimensionality - i.e., detailed attributes about the Manufacturer that wouldn't need
    to be flattened onto the product)
    - build a factless fact that captures the products offered by a given manufacturer at a given point in time (perhaps representing various products catalogs and associated dates.  This would allow you to capture rich details about each dimension separately
    and use the factless fact to record)
    Let me know if that helps.
    Brent Greenwood, MS, MCITP, CBIP
    // Please mark correct answers and helpful posts //
    http://brentgreenwood.blogspot.com

  • 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

  • Join Master Data table with fact table

    Hello gurus.
    I have a requirement on a characteristic. I have to obtain the description of those values that are not filled with data in the cube, the example looks like this:
    Data in the cube:
    Characteristic 1 |  charactersitic 2 |  value
    AU                           HPDV              200
    TB                           OPPG              500
    TC                           HPDV              900
    TR                           OPMR             400
                                   HPDV              300
                                   OPMR             200
                                   OPPG             100
    Master Data Table:
                                Description
    HPDV    AU       Auditoria  
    OPPG    TB       Servicios Logisticos
    HPDV     TC       Occidente
    OPMR    TR       Oriente
    HPDV     AI        Punta Norte
    OPGS    CV       Escandón
    HPDV    QR       Barquisimeto
    HPDV    MM      Valencia
    HPDV    DT        Barcelona
    I need to display in the query only the description of the characterstic whose data is not in the cube, according to the example the values that are missing in the cube are:
    HPDV     AI        Punta Norte
    OPGS    CV       Escandón
    HPDV    QR       Barquisimeto
    HPDV    MM      Valencia
    HPDV    DT        Barcelona
    How can i achive this ?? 
    Thank you in advance.

    Hi Guillermo,
    I think you are trying to achieve this: To display characteristic values for which no transaction data or only low values exist for the selected period.
    See here for the solution details:
    http://help.sap.com/saphelp_nw04/helpdata/en/3a/d1603d13b5c72ee10000000a114084/content.htm
    Hope this helps...

  • How to update a fact table when a dimension table is reloaded

    We have implemented BI Apps 796. Insertion into W_EMPLOYEE_D table which stores all the employee information had stopped one year back as some company security policy restricted the informatica worklfows to pick up the data. (PER_ALL_PEOPLE_F was a HRMS table and it contained sensitive information line SSN and salary, was inaccessible to the user which informatica uses and the SDE mapping used to return 0 rows).
    Now we have the approval to see those rows and the dimension table is loaded with some 100 new employees who joined in last one year.
    The ROW_WID of W_EMPLOYEE_D is referenced in lot of fact tables and for all those missing employees the WID in the fact table is 0.
    Now that we have all employees, how to make the FACT table point to the correct WID and not store 0. Has anyone faced this problem before?? Writing an update statement will be a tedious task as there are so many fact tables that join to w_employee_d. Also our company uses Sales, Procurement, Finance modules of OB Apps (which constitutes atleast 20 fact tables)
    Any guidance is appreciated. Thanks in advance

    Hello Kostis,
    thank you for your answer. I don't fully understand you. Can you show me short example, please? I create alias table for time dimension on Physical Layer - original table is TimeDayDim and I create aliases TimeDayDim1, TimeDayDim2, TimeDayDim3, TimeDayDim4. Then I create foreign key Fact.Time1 -> TimeDayDim1, Fact.Time2 -> TimeDayDim2, Fact.Time3 -> TimeDayDim3, Fact.Time4 -> TimeDayDim4. And what now? Must I create these table api Bussines Model and create new time dimensions at bussiness model????
    I need in Answers ONE Time dimension. I think I must split my fact table to four tables ... (time1, place1 ...) (time2, place2 ...) (time3 place3...) (time4 place4...) then link those tables to Time dimension (but I dont know where I can split those tables - on Physical Layer or on Bussines Layer).
    I suppose that I will have in Answers one time dimension and four facts tables and I will be able to query them. (for example: Time.Days, Fact1.Place1, Fact3.Speed, Fact4.Count Criteria: Time.Year = 2008)
    Best Regards Vlada

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

Maybe you are looking for