Diferent Grain Fact Table

Hi, I have two fact table, a budget fact table and an adjust fact table... the budget fact table is related to a year dimension and the adjust fact table is related to a date dimension..
So I have something like this:
Budget table
Year Concept Amount
2008 A $200
2008 B $100
2008 C $300
Adjust table
Year Day Concept Amount
2008 02-01-2008 A $50
2008 02-03-2008 A $-30
2008 02-05-2008 A $80
In my report I want to get this:
Filters:
Year = 2008
Date between 02-01-2008 and 02-03-2008
Table:
Year Concept Budget Amount Adjust Amount Total Amount
2008 A $200 $20 $220
2008 B $100 $100
2008 C $300 $300
As you can see the Budget data is annual so even when I apply a filter over the Adjust fact table date I want to preserve all the budget data because, (from a bussines point of view) even when I apply a filter over de Adjust data the budget exist...
Currently I have this two star schema modeling in my bussines model and I getting just the firt record because OBIEE is taking the adjust fact query as more restrictive than the other...
Any Idea?

Hi I would suggest two logical fact tables and a conformed time dimension with appropriate hierarchy levels (Total->Year->Month->Day) or similar.
Set the content levels appropriately on each of the logical fact table sources (LTS) , ie. Day for the adjust facts, Year for the budget facts.
When you start a report at Year, you can aggregate the numbers up, when you drill past year, the budget will dissapear as its only relevant at Year Level, to prevent this you can disable drilling on the answers report on the year column.
To Keep the Yearly budget expressed against daily adjust facts, you can create specific level based Budget measures that wil persist in the report once you drill past year.
Hope this helps.

Similar Messages

Dimension and Fact table have the same grain

Hi All,
How can we join a dimension and a fact table if they have the same grain ? In my case it is a contract number.
Thanks

Your Impression is right, In terms of Dimensional Modeling. You have to consider this when you are designing your warehouse tables.
But now if you already have these tables in database, OBIEE does not care how many rows a table have, it just need to know what is fact and what is Dimension and it will generate sql queries based on join conditions.

One DIMENSION, Two FACT Tables - One WEEKLY grain, one DAILY grain

All the OBIEE gurus, thanks for checking out this post.
Background: We have a common DIMENSION referencing two FACT tables having different granularity.
DIM = Customer Dim
FACT = Forecasting (Weekly granularity)
FACT = Sales (Daily granularity)
There is a need to report from the Customer Dimension table AND access the Forecasting FACT (weekly grain) & Sales FACT (daily grain).
Example of query is listed below:
Give me customer = 'ABC' and the forecast and sales for a specific time period.
What will be the best way to handle something like this? I have seen examples of handing multi-fact table access in OBIEE but the granularity of both the FACT tables is different (weekly vs. daily).
Any help with an example is greatly appreciated.
Thanks,
Sunshine

Hi.
This one:
Joining different level aggregation measures together into a single logical fact table
http://108obiee.blogspot.com/2009/07/joining-different-level-aggregation.html
Regards
Goran
http://108obiee.blogspot.com

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.

How to implement fact tables with finest level of detail (fine-grained)?

Hi,
Maybe this is basic knowledge what I'm asking here... I don't know, well, here it goes:
I need to know the way carry my transactional data to a fact table, but keeping the finest level of detail possible (namely, the transactions). I implemented my cubes with MOLAP option for storage (those were the specs that I had to follow) so I can't add a unique constraint to those structures.
I only seem to be able to load aggregated, precomputed data. If I wanted to load the transactions (after the data has been transformed and clenased) where should I do it?
I tried to implement a version of the fact tables as ROLAP but got nowhere (I couldn't add a unique constraint or index on that column either).
I would really, really appreciate your help.
Best Regards,
osvaldo.
[osantos]

Hi Veeravalli,
Thanks for your reply :)
Let me explain the problem in more detail. I have one Date dimension(Date_Code,Month_Code,Quarter_Code,Half_Year_Code,Year_Code). Here Date_Code is the PK.
In F1---->Date (Using Month_Code key)
F2-------->Date (Using Date_Code Key)
Level based hierarchy is there starting from Year to Date.Each level has PK defined and chronological key selected.
F1 has level set to Month and F2 has level set to Day.
Now if i am using ago() function on measure of F2 (having day level data) then it's working fine but if i am using ago() function on measure of F1...I am getting an error at Presentation service: Date_code must be projected for time-series functions.
So the whole issue is with time-series functions. As per my research...I think for time series the tables in the physical model containing the time dimension cannot join to other data sources, except at the most detailed level but here i am joining with F1(using Month_Code which is not the most detailed level).
So kindly let me know how to achieve this in rpd?

How to join Dimensions and Fact Tables in OBIEE

Hi All,
I need to create report which need to get the information from two fact tables and 7 dimensions. The granularity is not same in both the fact tables. One fact table is having common keys between all the dimension tables and second fact table have only two dimension keys but with different names. My requirement is to create the report by taking the measures from both the fact tables.
I have created joins between the second fact table and two dimension tables in physical and BMM layer and also set the highest level for all other dimension tables in the LTS of second fact table. when am creating report by taking the measures from both the fact tables, data is not getting for the measure which taken from the second fact table. Please advice me how to get the data for the measure which taken from the second fact table.
Thanks in Advancec !!

You have to use the level-base measure capabilities.
http://gerardnico.com/wiki/dat/obiee/bi_server/design/fact_table/level_based_measure_calculations
For all measures of the second fact table with the lowest grain (with two dimension keys), set for all dimension where you don't have any key the logical level to the "All" or "Total".
And UNSET the highest level of the LTS for the second fact table.
Success
Nico

"Select" Physical table as LTS for a Fact table

Hi,
I am very new to OBIEE, still in the learning phase.
Scenario 1:
I have a "Select" Physical table which is joined (inner join) to a Fact table in the Physical layer. I have other dimensions joined to this fact table.
In BMM, I created a logical table for the fact table with 2 Logical Table Sources (the fact table & the select physical table). No errors in the consistency check.
When I create an analysis with columns from the fact table and the select table, I don't see any data for the select table column.
Scenario 2:
In this scenario, I created an inner join between "Select" physical table and a Dimension table instead of the Fact table.
In BMM, I created a logical table for the dimension table with 2 Logical Table Sources (the dimension table & the select physical table). No errors in the consistency check.
When I create an analysis with columns from the dimension table and the select table, I see data for all the columns.
What am I missing here? Why is it not working in first scenario?
Any help is greatly appreciated.
Thanks,
SP

Hi,
If I understand your description correctly, then your materialized view skips some dimensions (infrequent ones). However, when you reference these skipped dimensions in filters, the queries are hitting the materialized view and failing as these values do not exist. In this case, you could resolve it as follows
1. Create dimensional hierarchies for all dimensions.
2. In the fact table's logical sources set the content tabs properly. (Yes, I think this is it).
When you skipped some dimensions, the grain of the new fact source (the materialized view in this case) is changed. For example:
Say a fact is available with the keys for Product, Customer, Promotion dimensions. The grain for this is Product * Customer * Promotion
Say another fact is available with the keys for Product, Customer. The grain for this is Product * Customer (In fact, I would say it is Product * Customer * Promotion Total).
So in the second case, the grain of the table is changed. So setting appropriate content levels for these sources would automatically switch the sources.
So, I request you to try these settings and let me know if it works.
Thank you,
Dhar

Issue with Multiple LTS for a fact table and filters

Hello,
I am facing an issue with obiee 10g.
In my model, I have a huge FACT table F1 (partitioned and indexed). The average response time for the queries, which targeted it, was ~30-60 seconds, which was not really convincing our end user.
So, we decided to create a materialized view, which removes some dimensions that are not used by default, but might be used if the end user adds some filters. I added the Materialized view in the Physical Layer and in the corresponding Logical Table Source.
I then tried to see if it works, but I was a bit surprised by the result. Indeed,
-> If the report does not reference a truncated dimension, it targets the materialized view. -> Perfect
-> If the report does reference a truncated dimension in the columns, it targets the Fact Table. -> Perfect
-> If the report does reference a truncated dimension in the Filters, it targets the materialized view. For this reason, the filter is never resolved and no join on the dimension table is applied, whereas it exists in logical SQL generated. -> Ko.
A suggestion could be to add the filters into the columns, but I am not satisfied by this response because it will never use the materialized view in that case.
An other suggestion could be to use query rewrite, but I 'd like to have the full control on the generation of the queries.
Does someone know if the filters are not evaluated to determine which LTS to use? How can I force this evaluation?
Regards,

Hi,
If I understand your description correctly, then your materialized view skips some dimensions (infrequent ones). However, when you reference these skipped dimensions in filters, the queries are hitting the materialized view and failing as these values do not exist. In this case, you could resolve it as follows
1. Create dimensional hierarchies for all dimensions.
2. In the fact table's logical sources set the content tabs properly. (Yes, I think this is it).
When you skipped some dimensions, the grain of the new fact source (the materialized view in this case) is changed. For example:
Say a fact is available with the keys for Product, Customer, Promotion dimensions. The grain for this is Product * Customer * Promotion
Say another fact is available with the keys for Product, Customer. The grain for this is Product * Customer (In fact, I would say it is Product * Customer * Promotion Total).
So in the second case, the grain of the table is changed. So setting appropriate content levels for these sources would automatically switch the sources.
So, I request you to try these settings and let me know if it works.
Thank you,
Dhar

Fact table showing incorrect quantity measure

Hi,
I have a scenario where i have a fact table with multiple rows and two quantity fields. My source system holds sales by "package" which can contain any number of components. The grain of my invoice table is component level. See
structure below:
PACKAGE1
- Component1 - each package contains 2 of these
- Component2 - each package contains 1 of these
So if i am reporting a sale of PACKAGE1, for a quantity of 2 - component1 had a total sales quantity of 4 and component2 has a total sales quantity of 2. However the package was only sold 2 of, but because of the sum aggregation, i see a total quantity
sold for PACKAGE1 of 6, but it should only show 2 at that level. I have looked at semi-additive measures but am unsure of how this would work in this scenario, or which option would work best for me here.
My fact table has 2 rows, each of which reference the component as one dimension and the package as another dimension.
As a workaround, I have created a calculation to divide the quantity by the number of package components (so it would show a 1 for each of the component lines in my fact table), but then the sales quantities of the components reported are incorrect.
What is the best approach for this?
Thanks in advance,
Dom

Hi Dominic,
Thank you for your question.
I am trying to involve someone more familiar with this topic for a further look at this issue. Sometime delay might be expected from the job transferring. Your patience is greatly appreciated.
Thank you for your understanding and support.
Thanks,
Simon Hou
TechNet Community Support

Join fact table with higher dimension level

how do i join fact tables with higher dimension levels with discoverer?
fact with detail at level C
measure X
dimension with
D->C->B->A
E->C
level
A B C
1------1------1
2------2------1
3------2------1
join between fact X and dimension level C
X=3*C because of sum(X) in discoverer and 3xC in dimension
is there a way to get correct values for X without creating a dimension like
D->C
E->

another way of asking this is whether you can create a summary table in Discoverer at a higher level than a dimension's fundamental grain. In other words - the summary examples in the documentation all describe leaving out one or more of your dimensions... they are either left in or completely taken out. But, some of the most effective summarization occurs when you summarize daily data to a monthly level. Assuming that I have a sales table (at a daily level, and a key value sales_date), and a table date_dim (primary key sales_date), I would like to create a summary sales_month_summary where the sales are grouped on month_year (which is a field in the sales_date table).
How is this done? I suspect that we can't use the date_dim table with the summary (due to the problems noted by the poster above). Do we have to create another table "month_dim"? Do we have to fold all of the desired date attributes (month, quarter, year) into the summary? Obviously we'd like to re-use all of the pertinent already existing date items (quarter, month, year, etc.), not recreate them over again, which would result in essentially two sets of items in the EUL. [One used for this month summary, and another used for the detail.]
I searched the forum - someone asked this same question back in 2000 - there was no answer provided.
The only other thought I have is to "snowflake" the date_dim into two tables and two folders, one at a date level, another at the month level. Then the detail tables can connect to date_dim (which is linked to month_dim), while the summary data can connect directly to month_dim.

Update data automatically in fact table in Data Warehouse

Hi,
I'm working on the creation of a data warehouse that include different data source like SQL Server performance (more than one), Active Directory users, Server performance (more than one), Exchange server mailboxes. The problem is that performance data change
frequently (like CPU and Memory), so my question is how to update data in fact table every 5 seconds automatically with SSIS.
Thank you for any advice

I'm assuming you have already figured out how to capture the data e.g. Powershell, extended events, MDW etc. and just need to know what dimensions or fact tables do you need.
You need to decide how often you are going to capture this data and based on that you will have dimensions with appropriate grain. Don't try to cram everything in the same fact table if it not of the same granularity. Also, separate process usually
have separate fact tables.
In addition to the Date dimension, you will need a Time dimension with a grain of 1 second (or maybe 5 seconds if that is when you get your data) then run the SSIS every 5 seconds to capture and append that data in the fact table.
- Aalamjeet Rangi | (Blog)

Two FACT Tables, Some Common and Non-Common Dimensions

Hello all, a question i am sure you have faced in the past but still wanted to get your feedback.
I have a few FACT tables and some dimensions that are shared (common dimensions). Rest of the dimensions are related to one or the other FACT tables.
What is the best way to present a view where users can pull information from both the FACT tables?
I am successful in pulling the shared (common) dimensions across BOTH FACT tables having the same grain but this view breaks down when i pull information from one Dimension that has not much to do with the other FACT.
What is the best way to present this? Should this be broken in three subject areas?
Subject Area 1 --> Some Dims --> FACT Table A
Subject Area 2 --> Some Dims --> FACT Table B
AND
Subject Area 3 --> ***Only Common Dims*** --> FACT Table A & FACT Table B?
Your feedback is always appreciated.
Regards,
Edited by: user10679130 on Oct 12, 2009 3:27 PM

Please check the forum first for similar threads/questions.
Joining two fact tables with different dimensions into single logical table
http://108obiee.blogspot.com/2009/08/joining-two-fact-tables-with-different.html
This solution keeps both fact tables in the same subject area in the single logical fact table, with common and not-common dimensions.
Regards
Goran
http://108obiee.blogspot.com

"None of the fact tables are compatible with the query request " error

I've got a situation where I have two facts(Fact_1, Fact_2) and three dimensions(dim_1,dim_2,dim_3) in 1 subject area. I've got dimension hierarchies setup for all the dimension tables.
Dim_1 is one to many to Fact_1
Dim_2 is one to many to Fact_2
Dim_3 is one to many to both Fact_1 and Fact_2
I've set up the content levels for the LTS for the Facts so that they are the lowest grain for dimensions they join to and the grand total grain for dimensions they do not join to.
My rpd is consistent. When I run a report using an attribute from Dim_3 and Dim_1 or Dim_3 and Dim_2, the report comes back fine.
But if I try to run a report using all three Dim tables, I get an error and the message "None of the fact tables are compatible with the query request ".
First of all, is it possible to make a report using all three dimensions?
Second, what's the best way to trouble shoot this error? Why are none of the fact tables compatible? I thought as long as the aggregation levels were set to grand total for non-shared dimensions, Answers would be able to create the report properly.
Any advise would be greatly appreciated.
Thanks!
-Joe

OBIEE is looking for a fact that can link ALL the dimensions together. This is also known as the implicit fact ... you don't have a fact that can relate all the dimensions - you have 2 facts that together they can. Perhaps you need to great a single logical fact that has both LTS for your physical facts and try it that way.
Then you'd have Dim1, Dim 2, Dim3 all being able to join to Fact1 (which is made of physical facts 1 & 2).

How to use 2 Fact Tables

Hello All,
I have two fact tables in my data model but when I'm joining them using confirmed Dimension(Bridge Table) I'm finding error msg. Could you guide me the steps I should follow to implement more than one fact tables.
-Rahul

What error message(s) are you receiving?
Also, are the 2 fact tables at the same grain?

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

Diferent Grain Fact Table

Similar Messages

Maybe you are looking for