Dimension fact aggregation question

Hi,
I am new to Oracle OLAP and I noticed something in this tool. It doesn't aggregate the right way.
For example, if there is a customer A in the Customer dimension and customer A has 5 records in the fact with amounts 10,20,30,40,50. When I build the cube, the cube doesn't aggregate the amounts for customer A. It picks one of the amounts. I have to actually aggregate in the view and pass it to the cube.
Is this how it is in Oracle OLAP? or am i missing somehting? Help me on this basic fact/dimension design.
Thanks in advance.

Oracle OLAP assumes that you're loading in source data at the same dimensionality as what the cube is designed at. In your case below, that isn't true. Your cube is dimensioned only by customer, while means each customer should have one and only one record.
Two ways to resolve this - either add another dimension to the cube that lets you break out the 5 records (maybe a time dimension?), or create a view on the fact table that summarizes the data to the lowest level of your cube.
Hope this helps,
Scott

Similar Messages

  • Different Data sources for dimensions & Facts

    Hi
    Here is my scenario. For our POC purpose, we are just trying to access dimensions, & Facts from 2 different data sources.
    Dimensions come from db2 and Fact table comes from a different source.
    My question here is did any one faced issues like this ? I am wondering whether i need to join these tables physically in the phyical layer or should i have to take care of them in the BMM Layer.
    Thanks in advance for any of ur ideas

    As mentioned you will need to join across data bases. One thing you will see when you do this is that OBIEE will do a bulk select across those databases then join and filter logically in its own memory process. If you MUST join across databases at least propagate the common dimensions across both databases; that way at least OBIEE can do a semi-filtered grab of the data from each database before it joins the resultsets in memory.

  • Examples of using OLAP Worksheet to define dimensions & facts

    Hi - Does anybody have examples of how to use the olap worksheet to define dimensions & facts and then load them from database tables and views? The manuals are OK, but I feel like I'm feeling my way blindly and not sure if I'm doing it right. A good set of examples would do wonders to make me more confident that I can do what I want to do.
    Using AWM is out of the question, unfortunately. It simply doesn't do what I want it to do for semi-additive measures (i.e. count distinct).
    Thanks!

    Two minutes make no difference.
    We may say that we gave the response together.
    This forum is not a race area
    Yvan KOENIG (from FRANCE vendredi 15 mai 2009 11:00:18)

  • Import individual dimensions/fact tables or use views!

    Hi,
    Just a quick question to establish if there is a difference between importing a view that has been created based on our dimensional model or should we import the individual tables i.e. dimensions & fact table
    Many thanks,
    Rhys

    Thank you both for your responses.
    I am fairly new to dimensional modelling & DW and was just curious.
    My instinct is to use the dimension & fact tables as opposed to views but I was just wondering what sort of circumstance would benefit by using one approach or the other??
    In our first steps we have modelled a fairly simple process, imported the model and displayed the data on our dashboards and this worked just fine.
    Regards,
    Rhys

  • SSAS aggregation question.

    I have a SSAS cube dimension with hierarchies - Country, State, City, Street.
    I have two measures (Price and Quantity) that need to aggregate independently up to City level only. Product (multiplication) of these two measures at City level should then be aggregated for higher level hierarchies (Country, State).
    How do I do this in MDX?
    Thanks,
    J.

    Hi,
    Here is my question with example:
    Dimension Hierarchy -  Country, State, City, Street.
    Country      State  City     Street      Qty
    US             CA      City1    Street1    10
    US             CA      City1    Street2     5
    US             FL       City3    Street3     8
    US             FL       City4    Street4     4
    Country       State       Plan      Price
    US              CA           A         $100
    US              CA           C         $70
    US              FL            B         $50
    Calculated Measure at Country level = 100*10 + 100*5 + 70*10 + 70*5 + 50*8 + 50*4 = 3150
    This is different from SUM(Price)*SUM(Qty) as it would be - 220*17 = 3740.
    I want 3150 to be my answer at Country level.
    I can JOIN the two table using Country and State fields to get a Cartesian product and that could works. The issue is the fact table becomes too big.

  • Join Between Dimension & Fact Table

    Hi all,
    Here is my scenerio:
    There are two tables, one dimension table and one fact table.
    Normally, they will be joined with a key, says Date_ID.
    However, these two tables do not have the same key.
    Question comes, can I create derived columns in both tables to pretend as key (the value of key assumes the same) and join them together? If yes, which layer (physical or business logic) to do the join? Will data be shown in Answer correctly?
    Thanks.

    Thanks for reply.
    I know that if two tables have the same key, says primary key and foreign key, they can be joined directly.
    However, the tables do not have the same key/column for join.
    Actually, I've tried to create dummy columns in both tables to join together in physical layer. Then use those dummy columns in business model layer to get the value from other columns. Complex join is carried out later in business moel layer. But it seems that it does work.

  • Aggregation Questions

    Hi there
    Got a couple of questions about OWB 10g R2 aggregations.
    #1 When I create a cube with aggregations, I cannot for the life of me determine how the aggregations are actually implemented.
    Are they implemented by separate tables? materialised views?
    So far, when I browse the schema, I can't see any extra database objects created for the purpose of providing aggregates.
    #2 I have seen this problem posted by a number of people, but have not yet seen any answer on how to overcome it.
    When I create a cube, for some measures I would like to "SUM", for others I would like to "AVERAGE" and for columns such as degenerate dimensions (i.e. Transaction_ID) I would like to have no aggregation at all.
    Can anyone tell me how to achieve this using the OWB Cube object???

    Hi
    Answer to the second question:
    In Design Center you have to double click in Project Explorer on the cube you want to examine. Than Data Object Editor is launched. To change the aggregation function of certain measures you have to select Aggregation tab in the low right corner. Than in the Measures panel select the measure that you want change aggregation function for. You can now change aggregation for that measure in panel: Aggregation for measure xxx.
    Regards
    Peter

  • Alternatives to Dimension facts for row counts

    Hi,
    I currently have a data warehouse with 3 fact tables, they are all at an order line granularity.  I want to start looking to add some facts that perform a distinct count of related dimensions (like how many orders, how many customers, etc).
    The method i have used is to create a measure group from the dimension in question (lets say customers) which allows me to use a count measure. 
    While this approach works, i dont like the fact that there will be many measure groups presented in the user application.  What I would like to do is have 1 measure group that contains all the "counts" for the dimensions i want.
    Is that possible?  If so, could somebody point me in the right direction?
    Many thanks in advance,
    Dominic

    My 2 cents:
    Whenever you create a distinct count measure, it creates addiitional measure group with same number of partitions as present in original measure group.
    Here is an article on distinct measure group for tabular and the multidimenional model. This article explains how you can create
    distinct measure group with single partition.
    If this post answers your query, please click "Mark As Answer" or "Vote as Helpful".

  • Bridge or Dimension Table Aggregation

    If you tryed to aggregate fields of a bridge or dimension table, maybe you had a message like "[nQSError: 14026] Unable to navigate requested expression".
    You can't aggregate fields directly on a bridge or dimension table. You need to include the bridge or dimension table on the source of the fact table:
    - On fact table properties, "Sources", select the fact table, and "Edit..." button
    - On "General" click "Add..." and select the bridge or dimension table
    - On "Column Mapping" include the field of the new table to be aggregated
    - Now, on fact table properties, "General", select the new field, double click, and select the aggregation mode (distinct count for example).

    Hello expert,
    Thank you very much for your reply.
    Actually the data model is very simple. There is only one physical table REJECT_FACT. The structure is as follows:
    Reject ID (NUMBER)
    Reject Category (VARCHAR2)
    Reject Code (VARCHAR2)
    Reject Code Desc (VARCHAR2)
    Site Desc (VARCHAR2)
    Site Code (VARCHAR2)
    Region Desc (VARCHAR2)
    Age Group (VARCHAR2)
    Reject Date (DATE)
    The hierarchy required is as follows:
    Reject Category -> Reject Code Desc -> Site Desc -> Region Desc -> Age Group -> Reject Date.
    I want to produce count on each hierachy level.
    How to populate the hierachy structure effectively?
    Thanks......

  • Snapshot Dimension & Fact tables

    We are currently designing a logical multidimensional model from an OLTP tables.Dimension tables have monthly snapshot because some of or all the attributes might change on monthly basis.The same situation for the fact table has monthly snapshot.
    I know that according to Kimball's modeling, the attributes for dimensions should be implemented using mini-dimensions and put combination key as a foreign key in the fact table but this step needs an ETL job to handle mini-dimension and other fact table.However, in our situation and according to scope limitation,there is no time to design separate ETL to handle mini-dimension.
    An example for our records:
    Customer:
    Cust_ID
    Month_ID
    Attr1
    Attr2
    Attr3
    Attr20
    Installments
    Installment_ID
    Cust_ID
    Month_ID
    Attr1
    Attr2
    Attr3
    Attr5
    Measure1
    Measure2
    Measure3
    Measure4
    So, Installments table contains attributes as well as measures so what is the suitable consideration and the suitable OBIEE logical BM design ,should we consider Installments table as fact or should we divide it into dimension and fact tables ?

    Xerox wrote:
    So, Installments table contains attributes as well as measures so what is the suitable consideration and the suitable OBIEE logical BM design ,should we consider Installments table as fact or should we divide it into dimension and fact tables ?You already give the answer yourself: you should create an Installment dimension and a Installment fact table, using the same physical table as logical table source. The logical dimension should only contain the attributes, the logical fact should only contain measures.

  • Value Based Dimension causing Aggrega                         tion problems

    I am new to building cubes in Oracle Olap, and am having trouble with a particular cube. (I hope I get all the terminology accurate enough to describe the problem I am having). Our organization structure is hierarchical. For example, org 0001is at the top of the "tree" and has 5 children: 1000, 2000, 3000, 40000, A000. Each of those 5 orgs have children that rollup to them. The problem is that the org "tree" is uneven. For example, Org 4000 has children that go down 4 more levels where the 3000 org only has children that go to level 3. We have about 1500 total orgs in the company. The dimension table we have shows the org_number and its Parent_org. Thus, I created an org dimension in AWM and then a value_based hierarchy. I can maintain and view the dimension in AWM and it all looks fine. I can then map the org dimension in the cube and maintain it (the cube that is). The problem is that the totals for my measures (actual costs) in the cube are way too high. Any advice as to what the problem is? I have verified that every org is in the table only once and that each org only rolls up to one parent org. I should mention that costs can be incurred by any org in the structure, no matter what level the org is at. Thanks for your help.
    Edited by: rybarrus on Jun 15, 2010 1:56 PM

    Thanks for your reply. That was a helpful suggestion. I found what seems to be the problem,but don't know why it is happening. When I look at a particular leg of the Org in the cube (in AWM) I see the following totals (indented to show parent child relationship):
    ORG--------------------Total
    1000...................602.42
    -------1030............557.48
    --------------1034.....557.48
    -------1060............ 44.94
    --------------1063..... 44.94
    When I Query the fact table I see the following totals:
    1000................... 0.00
    1030................... 159.05
    1034................... 557.48
    1060...................7,800.00
    1063................... 44.94
    To me, it looks like the total amount of the child is REPLACING the total of the parent. For example, the total in the cube for org 1060 should be 7,844.94 (7,800 + 44.94). Any reason why it doesn't sum correctly?
    Also, the total for org 1030 should be 716.53 (557.48 + 159.05).
    If you look back at my first post, I said that the overall total in the cube at the top level is way over the total in the table. That is still the case. This example that I have shown happens to be the opposite. The total I get when I query the fact table is greater than the total in the cube at this level. I hope that is not confusing.
    Edited by: rybarrus on Jun 15, 2010 4:37 PM

  • Cartesian product of three dimensions - fact table is too big

    Hi, I need some advice with OLAP design. I have tables with orders, customers and product types. My problem is that I want to know amount of orders for every combination of customer - date since customer was created - product type. I also need to filter
    days when no order was made and the opposite (by dimension). Also customer have some interval of time when he is considered as a new customer and I need to filter this customers too (again by dimension).
    Now I have got fact table filled with every combination of customer/product type/date and the number of orders with the bit flag - was a new customer. Problem is that I have aprox 100k customers, so this table has bilions of rows. Is there any other possible
    solution? For browsing cube is used Excel where I cannot easily filter by measure/calculation.

    It seems like every customer is a new customer at some point in time. So, you should probably store first order date in the customer table. Depending on the Date (Period) selected , a customer will become new, active or inactive. Also, create measures for
    new customer sales, old customer sales. i.e. First order date + 30 days of the customer is less than last date in the period selected, it is new customer sales.  I would assume that it would be difficult to do it in cube. Did you
    try to solve the problem using SQL queries?
    Good luck. 
    Customer
    First Ord Date
    New customer till
    Cust A
    3/1/2014
    4/1/2014
    New Cust Sales
    Old Cust Sales
    Total Sales (New + old) 
    2014-01
    2014-02
    2014-03
    10
    10
    2014-04
    20
    20
    2014-05

  • Message Aggregator Question

    I have an instance where I need 2 sender file adapters to send XI 2 different files (layouts are different).  XI then needs to combine and map the messages from these two files into a single IDoc for each combined message.  I know in a multi-mapping I can do it either with a BPM or without.  When "aggregating" messages I know I can do it with a BPM.  My question is does anyone know of a blog that exists where someone has accomplished this without the need of a BPM (and if there are any good blogs which cover how to aggregate with a BPM that would be helpful as well).
    Thanks!

    Shaun,
    As you can see here, [Multi-Mappings|http://help.sap.com/saphelp_nw70/helpdata/en/21/6faf35c2d74295a3cb97f6f3ccf43c/content.htm], you can not do the Message-Merge (n:1) mapping w/o BPM.
    Using the BPM, you can refer to the pattern 
    BpmPatternCollectMultiIf - [Collecting and Bundling Messages - Multiple Interfaces|http://help.sap.com/saphelp_nw70/helpdata/en/0e/56373f7853494fe10000000a114084/content.htm]
    I suggest that you schedule your sender adapters at around same time..so that the BPM doesn't have to wait too long to process them. If you can not ensure that, then you can use [Event-Driven Message Processing|http://help.sap.com/saphelp_nw70/helpdata/en/7a/00143f011f4b2ee10000000a114084/content.htm] to wait for both the files to be picked up before they are sent to BPM.
    praveen

  • Dimension Facts

    Please advise on this.
    There are 2 dimension tables with each joined to individual fact tables separately. For example, Dim1 joins to Fact1 and Dim2 joins to Fact2.
    Assumption: Dim1 and Dim2 have 1000 records each. Fact 1 has 10 and Fact 2 has 100 records within it.
    Is it possible to generate a report by merely selecting columns from Dim1 and Dim2 only? If yes, then I am wondering what will be the output in terms of number of records. I imagine there will be a backend query fired in some way to retrieve the data set from both the corresponding dimension tables.

    Hi
    The only way you can do it is to do an "union" of the dim1 members with the dim2 members.
    Exemple :
    Dim1 : has 1000 records representing Customers
    Dim2 : has 1000 records representing Employees
    You can do a report that will display 2000 "people" name.
    First, do you report by displaying the 1000 customers. Do not use any measure, because fact are here useless.
    Then, use the button "combine with similar request" and use the dim2 employee name.
    If, in each fact table, you have a specific measure, you can add them in your combined report.
    Exemple :
    - Fact1 has measure "NB of purchases"
    - Fact2 has measure "NB of sales"
    So, your first report will display "customer name + nb of purchase"
    And will be combined with "employee name + nb of sales"
    It will do a combined report "people name + nb of... something"
    But you won't be able to do a report that will cross the 2 dimensions "dim1 + dim2" because there is no relation between them.

  • I do not 'get' the basic snowflake / dimension / fact thing....

    Hello,
    sorry for total newB question, but if I have a table that is the most detailed level of data, do I have to create a datawarehouse copy of this that summarises it, or can OBIEE do that for me???
    I have read the documents / by example stuff but I am struggling with this most basic thing, even though the more complex areas seem easy.
    So what I am asking is, if I have a table, say 'user_trans' - do I have to write something in OWB or similar to turn this into a number of heavily summarised tables, say - user_trans_by_state, user_trans_by_period OR is there a way with the tool itself that I can take the basic table, import into the physical layer in the inventory and get OBIEE to do these summarisations for me - by generating dimensions??
    So to illlustrate, say user_trans has =>
    amount, user name, period, state
    Do I have to write something in a DW to generate
    sum(amount), user name - for user_trans
    sum(amount), state - for trans_by_state etc
    Or is there a way in the repository to do this, if so can someone please talk me through it in basic terms???
    Thanx

    Try the links detailed on an earlier answer....
    Tutorials of OBIEE?, Oracle By Example OBIEE?
    And on basic principles you are looking at a 1 => Many join in a star structure, the 1 being the centre or base of your star.
    In terms of the rest, install yourself a test area and work through the Oracle By Example stuff - if you do not get the concept maybe it will sink in with the practise....
    hope this helps - and good luck!
    R.

Maybe you are looking for