Relating facts with different grains

I'm having an issue designing a cube/star schema where I need to relate 2 fact tables that are at a different grain.
I currently have a star with 1 fact table (Insurance Premium) and 3 dimensions (Date, Account, Policy). The fact table has 1 row for each policy within each account for every quarter (quarterly snapshot). The measure is Premium.
We need to enhance this star with a new fact table that stores Lost Accounts for each quarter. The difference with this data is that we only get it at the Account Level. So the Fact table will have 1 row for each lost account per quarter. The
measure is Lost Premium.
I created the Lost Business Fact table which relates to the same Date and Account dimension as the Insurance Premium Fact table. In the cube, i created a new measure group for the Lost Premium fact table and related it to the same Date and Account
dimensions.
the 2 issues that I am having are:
1. In the Policy Dimension table, there is a field called AccountBroker, which stores the Broker for the account. So if the account has 5 policies, this table will have 5 rows and the AccountBroker field will be the same for each row. The
end users want to be able to use this field (AccountBroker) in the Lost Premium Fact table so that they can slice and dice the Lost Premium by Account Broker. The issue is that I'm not sure how to relate the Lost Premium Fact to the Policy Dimension
since the Lost Premium Fact is at Account level and the Policy Dimension is at Policy Level.
2. The other issue is that when we receive the Lost Business File for each quarter, the account may not be present in the Premium Fact because it was lost. So for example, for Q1 2014, account 1234 was lost and we receive a record in the Lost
Business File with Account 1234 as being lost and it gets inserted into the Lost Premium Fact. However, when we get the file that loads the Insurance Premium Fact for Q1 2014, this account is not present because it was lost in that quarter, so there
is no way to link the records. My first thought was to maybe take the records from the previous quarter (Q4 2012) and insert those records for Q1 2014 into the Insurance Premium Fact with 0 premium so that they exist and then there will be a match, but
not sure if there is a better design.
any ideas would be appreciated.
thanks
Scott

For me,
DEPT_FACT is not a fact. It's a dimension table because you have a one-to-many relationship and you have a measure in the dimension table (it's an aggregated measure).
And EMP_FACT is also not a fact because you don't have any measure on it.
But if we say that EMP_FACT is a fact. DEPT_FACT is an aggregated table from EMP_FACT.
I will :
* create a logical dimension for the employee with three levels (all, departement and detail)
* create a logical fact table with :
- one logical column for the revenue in the level all departement
- one logical column for the employee
and two physical source :
* DEPT_FACT with the departement level
* EMP_FACT with the level to detail
Success
Nico

Similar Messages

Joining Facts with Different Grains

Hello
We have a requirement where we have two facts with different grains
DEPT_FACT - Contains (Dept_Id, Dept_Name, Revenue)
EMP_FACT - Contains (Emp_Id, Dept_Name, Is_Current_Employee)
Here is some sample data
DEPT_FACT
========
1 Sales_Dept 100,000
2 Manufacturing_Dept 200,000
EMP_FACT
========
100 Sales_Dept Y
200 Sales_Dept Y
300 Sales_Dept N
400 Manufacturing_Dept N
500 Manufacturing_Dept Y
600 Manufacturing_Dept N
Our requirement is to create an OBIEE report that shows the *"Revenue/ Number of current employees in department BY Department"*
The above example must show
Sales_Dept => $50,000 (100,000 / 2 current employees)
Sales_Dept => $200,000 (200,000 / 1 current employee)
Any suggestions on how this can be done ?

For me,
DEPT_FACT is not a fact. It's a dimension table because you have a one-to-many relationship and you have a measure in the dimension table (it's an aggregated measure).
And EMP_FACT is also not a fact because you don't have any measure on it.
But if we say that EMP_FACT is a fact. DEPT_FACT is an aggregated table from EMP_FACT.
I will :
* create a logical dimension for the employee with three levels (all, departement and detail)
* create a logical fact table with :
- one logical column for the revenue in the level all departement
- one logical column for the employee
and two physical source :
* DEPT_FACT with the departement level
* EMP_FACT with the level to detail
Success
Nico

Joining Facts With Different Grains to NonConfirming Dimensions - Mystery

Hi ,
Taxonomy Used is - CD stands for Confirmed Dimension && NCD stands for Non Confirmed Dimension.
I have 3 Dimensions (CD1,NCD2,NCD3) and 2 facts (F1 & F2).
==> Fact F1 can be joined to only CD1 and NCD2 dimensions. Grain of Fact F1 is same as CD1 i.e., Nbr of records matches 1 to 1 between CD1 and F1F2
==> Fact F2 can be joined to only CD1 and NCD3 dimensions. Grain of Fact F2 is CD1 & NCD3. There could be multiple records for same value of CD1 within Fact F2, and similarly there could be multiple records for same value of NCD3. But there will always be just 1 and only 1 record for combination of CD1 and NCD3.
Report Requirements:-
1) Get few Metrics from F2 and few from F1 while applying a filter on NCD2. so below columns are needed :-
Dimension Column from NCD2 || Metric from Fact1 || Metric from Fact2
So need to understand how to enforce the relationship between Fact F2 and Dimension NCD2
2) Get few Metrics from F2 and few from F1 while applying a filter on NCD2 and also Display NCD3. so below columns are needed :-
Dimension Column from NCD2 || Dimension Column from NCD3 ||Metric from Fact1 || Metric from Fact2
==> In above case it is perfectly acceptable if Metric from Fact 1 repeats again as Fact1 is at higher Grain as compare to Fact2.
Edited by: user10799880 on Apr 15, 2013 9:37 PM

Hi,
refer to this
http://108obiee.blogspot.com/2009/08/joining-two-fact-tables-with-different.html
mark helps
thanks

2 facts with different dimensions in 1 logical table

hello,
im trying to accomplish the set up as described per blog:
http://108obiee.blogspot.com/2009/08/joining-two-fact-tables-with-different.html
i.e. i have 2 facts, F1: D1 ; F2: D1,D2,D3;
i followed the instructions and all seem to be working fine;
however: when i put the total on the report in Answers: D1,D2, F1, F2 then the measures from F1 that are repeated every row for D2 are being added , like regular sum on the column; this is not correct;
the only correct result i can get if manually i change the Aggregation Rule to :Server Complex Aggregate on all F1 measures;
id like to ask if this is a bug of this OBI version? 10.1.3.2
i wish not to instruct my users to change the aggregation rule; id like to have the set up via rpd such, that they dont have to manipulate the aggregation rules;
did anyone got the above working with correct totals without changing the aggregation rule?
if so, id appreciate any tips on how to achieve that
thanks
rgds

Basically, you need to :
* create your physical schema with the relationship
* drag and drop your Forecast Facts measure in the same logical table than your sales fact
* define your Forecast measure as level based measure (logical column/levels/properties) with the grain of the forecast table
Documentation
http://download.oracle.com/docs/cd/E12103_01/books/admintool/admintool_BusModSetup12.html
And you have an example in OBE series with quota in excel sheet :
http://www.oracle.com/technology/obe/obe_bi/bi_ee_1013/bi_admin/biadmin.html#t8
Success
Nico

Join fact tables with different grain without upsetting measures?

Say I am a business analyst at a university, and I have two analytical cubes available to me: an Enrollment Cube and an Admissions Cube. The Enrollment Cube has a grain of Student and Semester, whereas the Admission Cube has a grain of Student, Application and Semester (a potential student can have more than one application in a semester). Is there any way for the OLAP developer that makes these cubes to make it so that I can use both cubes' fact tables without messing up their corresponding measures, such that I can create such analyses as the following:
County
Semester
Acceptance Rate (Admission Fact)
Retention Rate (Enrollment Fact)
County A
1
30%
88%
2
60%
87%
3
42%
84%
County B
1
90%
100%

One suggestion is to create a view that joins the 2 fact tables and then create a cube with measures mapped to the view for analysis purposes. However, this would be using the measures of the new cube for the analysis.

Relating facts to different levels of a dimention

Dear All,
I need to relate a fact to optionally different levels of a hierarchy in a dimension
that's sales plan may be put on the level of a salesman or a distributor or a channel and so on ...
I think that it could be implemented by adding a dummy record in a each level that represent the parent .. but i don't konw how to add this dummy record in owb ...
can you help ..
Regards,
Shaimaa

Hi Shaimaa,
this is actually a very difficult business question. Technically, it's straightforward.
The easy part is to create one fact table per dimension level where you have a plan. So, you would have a SalesPersonPlanFact, a SalesManagerPlanFact, and so on. That will work technically . . .
But it won't really work. :-(
The reason is that the way these plans are created. Typically, the Boss and his guys work out a master plan. Then it gets broken into bits, and each department does their own sub-plan. All the way down, until it gets to individual sales plans. And at every step of the way, the plan gets tweaked, modified, 'special cases' put in.
The result is that they never add up. How you resolve that is a business issue, not a technical one.
Me? What I do is tell people that they won't add up, and then say that it doesn't matter anyway. The reason I give is that the purpose of the plan is to measure actual sales performance against plan, and that we can do. Sales take place at the most atomic level for which there is a plan, and these we can match and consolidate plan against actuals. The consolidated results are then MVed and thus present a high-performance single picture of 'the truth'.
Realistically, you're building a second-level snapshot (could be aggregated, could be periodic, could be both), and that's your reporting structure.
I suspect you may need to go and have a re-think about your value chain, and do much communication with your sponsors so that they understand what's achievable and of real worth to the business. After all, your business as a data warehouse architect is to ensure you're publishing the right data.
Cheers,
Donna

How to Link two Facts with Different Time Granularity (Year, Quarter) to a Single Time Dimension

Hello All,
I have the below scenario where i have Two Facts Fact Quarterly and Fact Yearly but one Time Dimension which has Quarter grain.
So my question is how do i Establish relationship from Fact Yearly to Time Dimension??
Ex:

Hi naveej,
According to your description, you want to know how to build the relationship with time dimension and fact tables. Right?
Based on your screenshot, it's better to have only one fact table for sales and build the relationship with time dimension. To determine quarterly or yearly data only depends on how you slice the time dimension. However, I notice that the Revenue for year
is different from the aggregated Profit for quarters. If the Revenue and Profit are different measure, you need to have two fact tables. And you should build the relationship (Regular) between TimeDim and FactYearly on YYYY attribute.
Reference:
Defining a Fact Relationship
Best Regards,
Simon Hou
TechNet Community Support

Combining relation facts with dimensions from an Essbase cube

Hi!
I am having trouble combining relational measures (from EBS) with dimensions from an Essbase cube. The dimensions that we want to use for reporting (drilling etc) are in an Essbase cube and the facts are in EBS.
I have managed to import both the EBS tables and the cube into OBIEE (11.1.15) and I have created a business model on the cube. For the cube I converted the accounts dimension to a value based dimension, other than that it was basically just drag and drop.
In this business model I created a new logical table with an LTS consisting of three tables from the relational database.
The relational data has an account key that conforms to the member key of the accounts dimension in the Essbase cube. So in the accounts dimension (in the BMM layer) I mapped the relational column to correct column (that is already mapped to the cube) - this column now has two sources; the relational table and the cube. This account key is also available in the LTS of my fact table.
The content levels for the LTS in the fact table have all been set to detail level for the accounts dimension.
So far I am able to report on the data from the fact table (only relational data) and I can combine this report with account key from the account dimension (because this column is mapped to the relational source as well as the cube). But if expand the report with a column (from the accounts dimension) that is mapped only to the cube (the alias column that contains the description of the accounts key), I get an error (NQSError 14025 - see below).
Seeing as how I have modeled that the facts are connected to the dimension through the common accounts key, I cannot understand why OBIEE doesn't seem to understand which other columns - from the same dimension - to fetch.
If this had been in a relational database I could have done this very easily with SQL; something along the lines of select * from relational_fact, dim_accounts where relational_fact.account_key=dim_accounts.account_key.
Error message:
[nQSError: 14025] No fact table exists at the requested level of detail
Edit:
Regards
Mogens
Edited by: user13050224 on Jun 19, 2012 6:40 AM

Avneet gave you the beginnings of one way, but left out that a couple of things. First, you would want to do the export of level zero only. Second, the export needs to be in column format and third, you need to make sure the load rule you use is set to be additive otherwise the last row will overwrite the previouse values.
A couple of other wats I can think of doing this
Create a replicated partition that maps the 3 non used dimensiosn to null (Pick the member at the top of the dimension in your mapping area)
Create a report script to extract the data putting the three dimensions in the page so they don't show up.
Use the custom defined function jexport in a calc script to get what you want

Two Related APPs with different session?

Hi all!
I have two apps (in a different workspace) linked by a tab. And whenever i switch between them, apex assigns a new session id.
The url given by me to the tab includes the &SESSION.
Is there any way to maintain the session??
Thanks!!!

No, see cookies and sessions
Scott

Joining two fact tables with different dimensions into single logical table

Hi Gurus,
I try to accomplish in Oracle Business Intelligence 11.1.1.3.0:
F1 (D1, D2 and D3)
F2 (D1 and D2 and D4)
And we want to build a report F1 F2 D1 D2 D3 D4 to have data for:
F1 that match only for D1-D2-D3
and data for
F2 that match only D1-D2-D4
all that in one row, so D3 and D4 are not common dimensions.
I can only do:
F3 (D1, D2)
F4 (D1, D2 and D4)
And report
F3 F4 D1,D2,D4 (all that in one row, and only D4 is not a common dimension)
Here is the very good example how to accomplish the scenario 1
http://108obiee.blogspot.com/2009/08/joining-two-fact-tables-with-different.html
But looks like it does not work in 11.1.1.3.0
I get
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 14025] No fact table exists at the requested level of detail: [,,Clients,,Day,ROI,,,,EW_Names,,,,,,,,,,,,,,,,,]. (HY000)
I am sure I set up everything correctly as advised in the blog but it works with only one not a common dimension
Is it a bug in 11.1.1.3.0 or something?
Thanks,
Kate

Thanks for all your replies.
Actually, I've tried the solutions you guys mentioned. Generally speaking, the result should be displayed. However, my scenario is a little bit tricky.
table Y's figures are not the aggregation of table X for D dimension. Instead, table Y's figures include not only D dimension total, but also others (others do not mean A, B, C dimension). For example, table Y stores all food's figure, while table X stores only drink's figure. D dimension is only about drink's detail. In my scenario, other foods' figure is not provided.
So, even if I set D dimension to all/total for table X, table X's result is still not the same as table Y.
Indeed, table Y does not have a column key to join to D dimension's key. So, if I select D dimension and table Y's measures at the same time in BI Answer, result returns no data. Hence, I can't compare table X and table Y's results with selection of D dimension.
Is there any solution to solve this problem?
Edited by: TomChan on Jun 3, 2009 9:36 AM

Two Fact tables with Different set of Dimension Tables

Here is my scenario:
I got two fact tables: X and Y (actually, they are the same tables, but with different level of data)
and four dimension tables: A, B, C, D
X joins relationship to all dimensions (A, B, C, D).
Y joins relationship to only A, B, C, but no D.
When I select dimension A, B and C together with fact tables X and Y in BI Answer, result is displayed and compared.
However, if I select dimension D together with fact tables X and Y, only data from fact table X is displayed. There is no result displayed for fact table Y. I know that this is because fact table Y does not join to dimension D.
If the above relationship unchanged, how can I display both X and Y's result in BI Answer when dimension D is selected?

Thanks for all your replies.
Actually, I've tried the solutions you guys mentioned. Generally speaking, the result should be displayed. However, my scenario is a little bit tricky.
table Y's figures are not the aggregation of table X for D dimension. Instead, table Y's figures include not only D dimension total, but also others (others do not mean A, B, C dimension). For example, table Y stores all food's figure, while table X stores only drink's figure. D dimension is only about drink's detail. In my scenario, other foods' figure is not provided.
So, even if I set D dimension to all/total for table X, table X's result is still not the same as table Y.
Indeed, table Y does not have a column key to join to D dimension's key. So, if I select D dimension and table Y's measures at the same time in BI Answer, result returns no data. Hence, I can't compare table X and table Y's results with selection of D dimension.
Is there any solution to solve this problem?
Edited by: TomChan on Jun 3, 2009 9:36 AM

How do I download a received e-mail into a program "directory file" and open it later by a related program with a different name.

Each week day afternoon I receive an e-mail bulletin and previously, using AOL, I downloaded it into a directory file located as a part of computer programs and then read it later with a related program with a slightly different name. Now when I try to do this using Mozella Firefox I don't see a way to download the e-mail bulletin into the directory program file and open it with another program related to the directory program. Firefox only shown the file name to read the download with but doesn't give me an option to download it to the program directory file. Please give me some detailed instructions.

Hello Explorer.ph
If safari recognizes it as a PDF then when you open it, you should see something in the right corner below the search box that says open in "" and another with "open in another app". If not try tapping the middle of the screen once tomake it appear. You may need to download iBooks, which is free from the AppStore ,to have an app to download it to.
I hope this helps.
Imaestro

Fact table with different granularity

I have a fact table , the measure with different granualrity , for example, there are a fact table named project, and in the project , there are some columns measure like project value, Opportunity value, (one opporuntity have many project). so I have to sum the project value and Opportuntity value
by month, how to sum opportuntity value? (I want to sum the value distinct Opportuntity ). anyone have suggetion. thanks in advance.

The purist answer is that you should NEVER have a fact table with multiple levels of granularity - it's asking for trouble. Better solution is to split off a new fact table at the proper level of granularity. Having said that, I've worked with BI Apps before so I understand the pain you're going through. In the long run though we found it better to add new fact tables and track the data at the proper levels. Less confusing (long run) than trying to kludge round data to fit in a square fact table.
Thx,
Scott

Mix source data with different granularity into the same fact table?

I have two transaction tables "Incident (157 columns)" and "Unit (70 Colums)". For every "Incident" that happens there could be one or more records in the "Unit" table.
As part of my data mart design, I have merged both the tables into a single Fact "Incident Fact (227 Columns)" and inserted the records from both the tables with a join condition between them [incident.IN_NUM = Unit.IN_NUM].
Is this correct, is my question? or am I mixing source data with different granularity in the same fact table. Appreciate your help.
Best Regards
Bees

Bees,
Are the measures from 'Incident' , repeated for a given incident where it has more than one record in the Unit table ? If so, then the sum(indicent.measure) will give an incorrect result, no ?
What requirement is there to physically merge the tables together outside of OBIEE? With OBIEE you could have one logical 'fact' table to present to report users, which sourced from seperate Incidents and Units tables and would stop the incorrect aggregations occuring. A common modelling piece in the same way would be Order Headers and Order Lines, quite common in OBIEE to have a logical 'Orders' fact which contained both Order header measures and Order line measures, this translates to your Incidents -> Units relationship.
To do what I've mentioned, is relatively straight forward, you need a 'Dim - Incident' with two levels, Incident and Unit, mapp the unique identifiers in as the level keys and then use these levels to set the content levels correctly in your 2 logical tables sources for logical 'Fact' , ie Incidents LTS at incident level, Units LTS as units level.
Hope this helps, let us know if you get stuck.
Cheers
Alastair

2 Measures referencing 1 Dim but on different grains withe second measure having a 2 key collumns

Hi, I need help please - I am stuck
I know how to add 2 measures on different grain but Meas1 joins on DimItem on lowest level but the Meas2
joins the DimItem on higher level combination of 2 collumns (key)
DimItem (level: itemcode -> class -> pack)
Meas1 (grain Itemcode) reference DimItem (itemcode)
Meas2 (grain class + pack) reference DimItem ????
I thought of creating a compositekey(class+pack) on both DimItem & Meas2 with Dim Compositekey type = regular (tried reference)
it just does not work, I want to when selecting class/pack both Measures return results
Please any help, im stuck and need to move forward

Hi,
Thanks for posting the CREATE TABLE and INSERT statements.
Don't forget to post the results you want given that sample data.
There's no problem outer-joining a table to 2 other tables when you use ANSI join syntax, like this:
SELECT    b.col6
,         a.col5
FROM             tablea a
JOIN             tableb b ON   b.col1 = a.col1
                            AND b.col2 = a.col2
                            AND b.col3 = a.col3
LEFT OUTER JOIN tablec c ON   c.col4 = a.col4
                            AND c.col6 = b.col6
ORDER BY b.col6
,         a.col5
Of course, there's no reason to include tablec at all if you're not going to use any of the data in it.
I recommend ANSI notation for all joins, especially outer joins.

Relating facts with different grains

Similar Messages

Maybe you are looking for