Choosing a Fact Table - HELP all you smart people

I have two fact tables (F1 and F2) and three dimensions (D1, D2 and D3)
Each fact table relates to all 3 dimensions.
I create an Answers request that produces a report with three columns
D1.year D2.name F1.number_of_equipments*D3.duration
The BI server could answer this request all using F1 using a single query - but it doesn't - and so gets the 'wrong' answer)
Instead it decides to run two queries using both Fact tables
a) get D1.year, D2.name and D3.duration using F2
b) get D1.year, D2.name and F1.number_of_equipments
c) stitch the two together in the BI Server (using the common Dimensions of D1 and D2)
How do I force/encourage the server go to F1 only?
If I add D3.col3 directly into the request (rather than using it as part of a formula) then Answers writes a single query- but this workaround is difficult to explain to end-users.
Currently on 10.1.3.2 OBIEE and 10.2.0.3 Oracle DB. Have set PERF_PREFER_INTERNAL_STITCH_JOIN to true (to workaround a different problem)

To choose a fact table, OBIEE server :
- check first if only one fact table belongs to the good aggregate content (logical table source property> tab content)
- if it can found two fact tables for the same level of content, it take the sort order of the sources in the logical table property (logical table > tab source, you can modify the sort order)
Cheers
Nico

Similar Messages

MSI Mega PC 651 HELP ( ALL YOU TECHIES)

I have this barebone and want to know that what the CN7 is for. It is just by the AGP slot. I need to know what this is for and if it is important and if there is any way to avoid like connecting it because it wont power on the pc if i dont connect it

disconnect the front lcd display from the motherboard, leave the CN7 connector plugged in otherwise you won't hear any sound at all from on board sound
look towards the front of the motherboard, near where the lcd display connects and the hifi module sticks up from the mobo, you'll see a standard front panel connector pin header (HDD LED, PWR SW, RESET SW etc) that is not used. you should be able to connect some sort of power switch to the PWR SW pins and the PC should power on that way. and because the lcd display is not connected, the front buttons won't work
i think that might be your answer

How do I use Derived Table to dynamically choose fact table

How do I use the Derived Table functionality to dynamically choose a fact table?
I am using BO XI R2 querying against Genesys Datamart kept in Oracle 10g. The datamart contains aggregated fact tables at different levels (no_agg, hour, day, week, etc...) I would like to build my universe so that if the end user chooses a parameter to view reports at daily granularity, then the daily fact table is used; choose hourly granularity, then hourly fact table is used, etc....
I tried using dynamic SQL in Oracle Syntax, but Business Obljects Universe didn't like that type of coding.
The tables look something like this:
O_LOB1_NO_AGG o
inner join V_LOB1_NO_AGG v on o.object_id = v.object_id
inner join T_LOB1_NO_AGG t on v.timekey = t.timekey
Likewise, in the 'hour', 'day', 'week', etc... fact tables, the Primary Key to Foreign Key names and relationships are the same. And the columns in each O_, V_, T_ fact table is the same, or very similar (just aggregated at different levels of time).
I was thinking of going a different route and using aggregate aware; but there are many Lines of Business (20+) and multiple time dimensions (7) and I believe aggregate aware would require me to place all relevant tables in the Universe as separate objects, which would create a large Universe with multiple table objects, and not be maintenance-friendly. I also was going to dynamically choose Line of Business (LOB) in the derived tables, based on the end user choosing a parameter for LOB, but that is out-of-scope for my current question. But that information sort of points you down the train of thought I am travelling. Thanks for any help you can provide!

You can create a derived table containing a union like the following:
select a,b,c from DailyFacts where (@prompt('View'....) = 'Daily' and (<rest of your where conditions here if necessary>)
union
(select a,b,c from MonthlyFacts where (@prompt('View'....) = 'Monthly' and (<rest of your where conditions here if necessary>))
union
(select a,b,c from YearlyFacts where (@prompt('View'....) = 'Yearly' and (<rest of your where conditions here if necessary>))
I assume that you are familiar with the @prompt syntax
Regards,
Stratos

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

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

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

Fact table usage is not appropriate

Hi All,
I am new to OBIEE 11g, we have 4 fact tables(F1, F2, F3, F4) that shares common 5 Dimensions(D1, D2, D3, D4, D5) and they are joined as below
F1-D1, F1-D2, F1-D3, F1-D4, F1-D5
and similarly all other facts(F2, F3, F4) are joined as above
problem is when we run the report with prompts, let say we created two choice list prompts(P1, P2), P1 with D1.Col1 column and filtering prompt values based on D1.Col12 to populate choice list, find SQL below
SELECT "D1"."Col1" FROM "Sales SA" WHERE "D1"."Col2"='North Zone'
based on the above prompt P1 we are restricting the choice list values of prompt P2 by setting Limit values by as P1, when we select a value from prompt P1 and click on P2 prompt it is showing blank i.e. results is NULL.
What I have noticed is, it is joining F4 fact table to get the data, checked the logical and physical queries of P2 prompt
Logical Query :
SELECT "D2"."COL1" saw_0 FROM "Sales AS" WHERE "D1"."COL2" = 'North Zone' ORDER BY saw_0
Physical Query :
select distinct T560319.CO1 as c1
from
D1 T560319 / Dim_D1 */ ,*
D2 T560407 / Dim_D2 */ ,*
F4 T562764 / Fact_F4 */*
where ( T560319.COL1 = T562764.COL1 and T560407.COL3 = T562764.COL2 and T560407.COL2 = 'North Zone')
order by c1
actually it should join the F3 fact table to populate the values of P2 choice list, but is joining F4 fact table
not sure where the problem is, can somebody help in resolving this problem.
Thanks,
Sumanth

Try by setting implesit fact table. You need to choose any fact table column or measure
Subject area-> properties
I'm assuming you have one logical fact table with 4 Logical Table sources

Two Filter on Two dimensions without constraining the fact table

Hi All,
does anybody know how to avoid the fact constraint when creating a report with two filters on different dimensions?
I have a big fact table with more than 10 Million rows. In the starmodel the is the dimension customer and products. I create a filter on the customer atrribute "Status" and choose the value "Active". Now I add the column "Product Type" from the dimension "Product" to the filter section. When I want to choose a value OBIEE executes a select statement within the fact table. So I have to wait very long to select a value. Is there any way to say OBIEE only to select the dimension table without joining the fact table?
Thank you very much in Advance.
Regards,
Stefan

Hi Stefan,
Generally queries on the dimensions (across dimesions also) always go through a fact. In case, you would like the queries not be through fact table, but just the dimension tables right away, you can set up a separate subject area for them.
You can create a separate subject area based on a dummy fact table to get these prompt values.
Please refer to http://gerardnico.com/wiki/dat/obiee/presentation_service/obiee_parameter_prompt_subject_area for more details on this setup.
Hope this helps.
Thank you,
Dhar

Indexes on a fact table

Hi All,
We are trying to build a data warehouse. The data marts would be accessed by cognos reporting layer. In the data marts we have around 9 dimension tables and 1 fact table. For each month we will have around 21-25 million records in the fact table. Out of 9 dimensions there dim1 and dim2 have 21 million and 10 million records respectively. The rest 7 dimensions are very small like less than 10k records.
In cognos reports they are trying to join the some dimension tables and the fact table to populate some reports. they are taking around 5-6 min.
I have around 8 B-Tree indexes on this fact table with all possible combination of columns. I believe that these many indexes is not improving the performance. So I decided to create a aggregated table with measures. But in cognos there are some reports which give detailed information from the fact table and that are taking around 8 min.
please advice as to what type indexes can be created on fact tables.
I read that we can create bit map indexes based on join conditions but the documentation says that it can include columns only from dimension tables and not fact tables. Should the indexed columns be keys in dimensional tables?
I have observed that the fact table is around 1.5gb. But each index is around 1.9 -2gb. I was kind of surprised when I saw that figure. Does it imply that index scan and table lookup would take more time than the full table scan? And hence it is not using the indexes.
Any help is greatly appreciated.
Thanks
Hari

What sort of queries are you running? Do you have an example (with a query plan)?
Are indexes even useful? Or are you accessing too much data to make indexes worthwhile?
Are you licensed to use partitioning? If so, are your fact tables partitioned? Are the queries doing partition pruning?
Are you using parallelism? If so, is parallel query actually being invoked?
If creating aggregate tables is a potentially useful strategy, you would want to use materialized views with query rewrite.
Justin

How to query on multiple fact tables ?

Hello all,
I know this is a recurring subject around here. I have read various topics and tried many thing but I couldn't reach my goal :
I want to query a BMM with 6 fact tables that all have common dimensions.
For instance, I have Invoices facts, Stocks facts, and a common SpareParts dimension.I am currently using a prewiew of my target BMM, which contains only these 2 fact tables and this single dimension. They are joined both at physical and logical level.
I'd like to build a report showing for a given spare part both stock and invoice information, but Answers replies it can't link Stocks with Invoices (even when I use the spare part dimension in the report).
* I can't afford to put both fact data in a single table as I'm most likely to report on the 4 other fact tables the same way.
* I can't either alias my dimension table, as I'd like :
- to avoid having 6 spare part dimensions for my 6 fact table (imagine the user's face in front of that)
- to have the filter on a spare part filtering on both tables at once (as I talk about the same spare part on both sides)
Unless you tell me I can create an alias and then say somewhere it's actually the same dimension...
* A colleague tried to alias the dimension and then build a 1-1 join between the dimension and its alias, but it didn't work.
* I have tried to build a hierarchy for the spare parts with all the fact data at the lowest level, but it didn't do. I guess hierarchies are not intended to be used that way.
* I have tried the bridge table to link the two fact tables but i get a circular path. Furthermore, as the fact tables then turn to dimensions, I'm pretty sure my aggregates won't work... I guess bridge tables are not intended to be used that way.
* I have tried singing, dancing, jumping and bouncing around my desktop but all I got was rain.
Can anybody catch me before I jump across the window ? I wouldn't like to get wet...
Many thanks in advance.
Ced.

Hi,
unfortunately, this purpose-built datamart was built within the company RPD. It has been deleted since then. These are the two reasons why I can't post it.
My advice is to take the time to read the help about how to build logical tables in the Administrator tool.
Here's a quick walkthrough:
- create your logical tables and join them in the business model diagram
- create dimensions (hierarchies) for all your dimension tables with at least a total level and a detail level. Thins can be done automatically by right-clicking the dimension table and selecting "Create Dimension"
- in the dimension tables, select the source table (in the source subfolder of the dimension table) and edit its properties : in the properties dialog box, select the content tab and in front of the dimension name, select the lowest (or apropriate) logical level
- in some complex BM (logical levels), it might also be necessary to apply similar settings to the fact table: This time, when you edit a fact table source, you will see the list of all dimensions available in the contents tab. There, for each dimension your fact table is related to, you will select the apropriate dimension level. if there isn't any join between you fact table and a given dimension, leave the logical level blank.
I hope this helps.
Ced.

OBIEE Query not hitting the other fact table

Hi All,
I am trying to create report based on two fact column and one dimension. Dimension is connected with these two facts table. When i create report using one column from dimension and one column from respective facts so i get two scenerio...
For example let say..
D1 is dimension and F1 and F2 are two fact tables.
First i used a column which have aggregation rule from one fact and one column from other fact which also have aggregate column.
That is report like...
D1.c1,Agg(F1.c2),Agg(F2.c3)
When i run the report I get the data from dimension and only from first fact table. When i check the query, Query contain only one fact table and it doesnt hit the other one.
Now in second scenerio i used one column from dimension, one column from first fact which have aggregation rule and one column from second fact which doesnt have any aggregation rule.
like...
D1.c1,Agg(F1.c2),F2.c3
When i run the report i got the error. It says
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14026] Unable to navigate requested expression: F1 -C2 . Please fix the metadata consistency warnings. (HY000).
But there is no warning in RPD.
I am amazed that it is not taking both the fact columns even the dimension is confirmed dimension and have joined with both the fact tables.
As i am just started to learn OBIEE, So i am find it bit difficult that how OBIEE select the tables and formed physical query.
Waiting for your help.
Regards
Suhail

Aadi-Wasi,
Thumb rule, OBIEE BMM layer must contain a simple star schema.
Did your BMM layer suffice the above condition? If hope, Not.
My prediction of your BMM layer structure contains 3 logical tables, i.e. dimension & 2 logical facts...which is not a simple star.
Thus to make it a simple star collapse 2 logical fact tables into 1 logical fact table. As you mentioned dimension is linked to both facts, collapsing 2 logical fact tables into 1 logical fact table will provide the result for your query1.
regarding your second error:
All aggregations must be contained within Fact tables with few exceptions.
Let us know If I did resolve your issue
mark posts promptly...
J
-bifacts
http://www.obinotes.com

F and E Fact Tables

Hi,
What is the difference between F fact table and E fact table?
When we create an Infocube which fact table is generated?
Thanks,
Soujanya

Hi ,
Difference between 'F' fact table & an 'E' Fact table
A cube has 2 fact tables - E and F. When the requests in the cube are not compressed the data exists in the F fact table and when the requests are compressed the data lies in the E fact table.
When the requests are compressed all the request ids are lost (set to NULL) and you would not be able to select/delete the data by request id. The data in the E fact table is compressed and occupies lesser space than F fact table.
When you load a data target, say a cube, the data is stored in the F fact table. If the cube is compressed, the data in the F fact table is transferred to the E fact table.
The F-table uses b-tree indexes the E-Table uses bitmap indexes. Index, Primary Index (The primary index is created automatically when the table is created in the database.). Secondary Index (usually abap tables), Bitmap Index(Bitmap indexes are created by default on each dimension column of a fact table), and B-Tree Index
Bex access the records from F-table or E- Table of InfoCube
Bex access both F and E fact tables. If data exists in both tables, it picks from both.
If the cube is not compressed it takes from F table, if fully compressed it takes from E table, partial compression - both F and E.
Roll-up adds the copy of records from F or E table to the aggregate tables. The records are not moved from F or E.
Also check the below SDN thread.
What is the difference between Fact tables F & E?
Hope the above info is helpful.
Cheers
VA
Edited by: Vishwa Anand on Aug 31, 2010 12:58 PM

Fact table is getting flooded

while loading 0FIAR_C03 its been observed that fact table is getting n times records
eg:
Transfered request: 969
Added Request: 29482
Data modeling as follow:
0FI_AR_4 -> 0FIAR_O03 -> 0FIAR_C03
till ods its fine but after that ......
when I checked fact table I found time dim_id is having multiple values because of that we are getting same set of fact data again and again for same dim_ids
when I checked update rule of cube then I observed 0CALDAY 0CALMONTH and 0CALYEAR are mapped with 0FISCPER using time distribution
so my question here is what is the function of time distribution ???
is that related to my issue???
Edited by: Alok Kashyap on Mar 4, 2009 9:28 AM

Hi Alok,
To answer some questions:
(A) Time Distribution Usage: Review "Time Update" Rule Type on SAP Help Portal (Data ware housing) NW04s version.
Main Point = " All the key figures that can be added are split into correspondingly smaller units of time"
"Time Update:
When performing a time update, automatic time conversion and time distribution are available.
Direct Update: the system automatically performs a time conversion.
Time Conversion:
You can update source time characteristics to target time characteristics using automatic time conversion. This function is not available for DataStore objects, since time characteristics are treated as normal data fields.
Time Distribution:
You can update time characteristics with time distribution. All the key figures that can be added are split into correspondingly smaller units of time. If the source contains a time characteristic (such as 0CALMONTH) that is not as precise as a time characteristic of the target (such as 0CALWEEK), you can combine these characteristics with one another in the rule. The system then performs time distribution in the transformation.
For example, you break down the calendar month 07.2001 into the weeks 26.2001, 27.2001, 28.2001, 29.2001, 30.2001 and 31.2001. Each key figure that can be added receives 1/31 of the original value for week 26.2001, 7/31 for each of weeks 27, 28, 29, and 30, and exactly 2/31 of it for week 31."
(B) Yes, it (time distribution) is "indirectly" adding extra rows into your fact table since " All the key figures that can be added are split into correspondingly smaller units of time" so you are getting more numerous distinct values of different DIM_ID values.
(C) Whether Time Distribution is Causing Extra Rows into the Fact table:
The 0BCT* Std Content of 0FIAR_C03 only contains 0Fiscper (Fiscal Year/Period) and of course 0Fiscvarnt (Fiscal year variant) time characteristics in the cube data model...The underlying infosource 0FI_AR_4 also has only 0Fiscper time characteristic.
So suspect someone at your site has tinkered with the 0BCT* 0FIAR_C03 datamodel to introduce more time characteristics...Please refer to the documentation or project deployment notes at your site since there may have been specific project requirements to do so. The project deliverables and the suspect person may be more the root cause...
Hope this helps.
Thanks and Regards,
Lee

Create a fact table from two Dim Tables - is it possible in powerpivot?

I have two comma delimited flat files.
1 - Customer Details (customerCode, Name, Address etc)
2 - Order Details(OrderNumber, OrderLineNumber, CustomerCode etc)
The two link by CustomerCode. I can bring both into powerpivot and link them directly, so cna deliver a report quickly. This model will grow however, with product dimension, store dimension and a few others.
So, i want to design it correctly from the outset, having a DimCustomer & a DimOrderDetail, that both link via a FactTable. I cant figure out how to create a factTable using both Dimensions using only powerPivot & dax. Is it possible?

Shaping the data before it gets to PowerPivot using Power Query is the easier option:
http://office.microsoft.com/en-us/excel-help/introduction-to-microsoft-power-query-for-excel-HA104003940.aspx
http://www.microsoft.com/en-us/download/details.aspx?id=39379
Ideally, with Power Pivot, the best model is a star schema where you have a single fact table and all the dimensions are linked directly to the fact table and not to one another. This isn't always possible in real world modeling but it is definitely the
easiest to deal with when writing measures and designing pivots. It also generally gives the best performance.

E abnd F fact tables

I understand that there are 2 fact tables in cube. can u please explain when "E" is created and afterwards whats the role of "F". where the subsequent data goes after transfer to "E". means new data.
regards
rajesh

Hi,
F is the standard fac table of the cube .Here goes all data if you load it by request.
E is the compressed fact table. Here you will get only data if you "compress" your cube. You can do it manually in the cube administration. You will find a tab named Compress. Here you can choose which data you want to compress, either all or just until the last x requests. It'S the same for aggregates they also have F and E fact table. But usually you compress data in aggregates, so will find aggregates data in E table then F table. If you compress the cube your data will be copied from F to E table (except those request that you don't want to compress). So F table gets smaller and E table holds the data.
Some extra info: If you have partitioned your cube, the "partitioned" data will be only in E table, so you have to compress your bcube to use partitioning!
Regards,
Juergen

Logical level for logical fact table sources

it is clear that for fact aggregates, we should use the Content tab of the Logical Table Source dialog to assign the correct logical level to each dimension.
question is : is it mandatory to assign even for non-aggregates fact tables the logical level for each dimension (which normally should be set to the most detailed level of each dimension) ? is it any known issue if "logical levels"in content tab are not set ?
the reason I'm asking this is a strange bug I have (I'm not going to discuss it here) and then only workaround seems to be NOT setting the logical levels (on content tab) for logical fact table sources.
thank you !

If levels are not set: By default levels are considered as lowest level
It should not matter if you set or not
Generally we set for facts explicitly when we are using Aggregate tables.
Your current issue might be a case by case; I would suggest to check implicit fact, any table mapped to the source to force a join etc
Mark if helps
Let me know how it helps
Edited by: Srini VEERAVALLI on Feb 5, 2013 8:33 AM
Any updates on this?+_
Edited by: Srini VEERAVALLI on Feb 14, 2013 9:09 AM

Is it ok? if we have 42 million records in a single fact table!!

Hello,
We have three outstanding fact tables, and we need to add one more fact type, and we were thinking whether we can do two different fact tables, or can we put the values in one of the same fact table which is similar, but the records are upto 42 million if we add ,so my question is having a single fact table with all records, or breaking it down, to two different ones!!!Thnx!!

I am not sure what is an "outstanding fact" or an "fact type". A 42m fact table doesn't necessarily indicate you are doing something wrong although it does sound as odd. I would expect most facts to be small as they should have aggregated measures to speed up report. In some cases you may want to drill down to the detailed transaction level in which case you may find these large facts. But care should be taken not to allow users to query on this fact without user the "transaction ID" which obviously should be indexed and should guarantee that queries will be quick.
Guessing from your post (as it is not clear not descriptive enough) it would seem to imply that you are adding a new dimension to your fact and that will cause the fact to increase it's row count to 42m. That probably means that you are changing the granularity of the fact. That may or may not be correct, depending on your model.

Choosing a Fact Table - HELP all you smart people

Similar Messages

Maybe you are looking for