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

Similar Messages

3 confirmed Dimensions and 2 fact tables

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

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

E and F Fact Tables

Hi
I recently joined as a Junior BI Consultant after training.
I am going through the SAP material with regards to Data Modelling
Could you please spare some of your valuable to time and shed some light on
Info Cube consists of a Fact Table surronded Dimension tables (Extended Star Schema).
Fact Table is classified as two types
/BI0/F -- Fact Table(Before Compression)
/BI0/E -- Fact Table(After Compression)
Correct me if I was wrong
By default Data will be saved in F Fact Table,If we compress the requests in Info Cube the data is moved from F to E fact Table
Can you please explain me the advantage of accessing data from E fact Table over F Fact Table
Thanks in Advance

Hi ,
In F table data is stored request wise...which is not the case with E table
Refer:-
Re: F & E tables
If you access from E-table you would avoid the aggregation of data as data is already aggregated and hence this puts less load on OLAP engine ..please note that when I say u avoid aggregation this does not mean that by using E table aggregation goes out of picture...the thing is that basic aggregation ( as explained in the above thread ) is avoided...
Hope it helps
Mann

Summary and Detail Fact Tables in one Universe ...

We have a classic star Schema with a snapshot( summary table by month) and a detail activity table on Daily activity. What is best way to design a Universe to accomodate this requirement.
1. Seperate Universe for summary Table
This removes the functionality of Drill down, and Drill down can be only available through links in Webi Reports.
2. One Universe for both Summary and Fact, and write logic for aggregate awareness. It will complicate the universe since we have close to 100 odd mesasures.
Thanks

Hi Devendra,
Use aggregate awareness irrespective of the "complicated" matter.

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

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!

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.

Multiple 'logical joins' between a fact table and one dimension table

It appears that one cannot create multiple ‘logical joins’ between a fact table and one dimension table in OBIEE using the Oracle BI Administration Tool. For example, considering a Business Model with a dimension table TIMES and a fact table FACT containing START_TIME and END_TIME, we would like to create separate logical joins from FACT to TIMES for the START_TIMEs and END_TIMEs? Obviously, the underlying foreign keys can be created, but as far as I can tell the Oracle BI Administration Tool doesn’t support this. The workaround would be to replicate the TIMES table, but that’s ugly.
I seek an alternative approach.

Try this. Create an two aliases for the TIMES dimension (Start & End) in the Physical Layer and then remove foreign key to the "Parent" Times dimension. Create the Foreign Key in the Physical Layer to the new aliases and then create the complex joins in the BMM Layer to the new aliases as well. This will allow you to present both dates within the same table in the Presentation Layer. Not the most elegant solution but it works.

Conformed dimension and query multiple fact tables

Hello,
Please if someone can guide me on this requirement.
Requirement - I have a conformed dimension D1 and two fact tables F1 and F2. Both fact tables have many columns so I cannot merge
the two fact tables into one logical table. Currently both these fact tables have logical tables F1 and F2 respectively.
As per design the conformed dimension is a simple logical table in the rpd and not a dimension.
Can someone guide me how should i proceed so that i'll be able to fetch information from both the fact tables?
Edited by: 930542 on Apr 26, 2012 12:28 PM

Hi,
Currently the dimension table is taken as a simple logical table in rpd as it does not have have any levels or hierarchy.
Its a flat dimension. Can you guide me how can I implement a flat dimension in OBIEE? Because this dimension is taken as simple logical table
I am not able to set appropriate level for fac tables. This dimension does not appear in the list of dimensions.

One to One relationship between Dimensions and Fact Tables

Hi,
Not a real Discoverer question, but seeing as there is such a huge pool of talent here, I thought I'd ask anyway...
Is the concept of having a one to one join between a Dimension and a Fact Table an Acceptable Thing (tm). I'm not talking about a degenerate dimension, as the Dimension would hold additional attributes.
It's something I'm trying to get my head around and would appreciate any viewpoints.
Thanks,
Andy

Hi Andy,
There is of course no distinction in SQL between 1-1 and 1-n joins, but in your database design you would avoid denormalizing data into a dimension table if it was only ever used once.
From a Discoverer perspective setting the join to 1-1 controls how aggregate queries are constructed. Normally, if you have a master-detail 1-n relationship and you aggregate items in both tables then you will get an incorrect result for the master table because the number of rows are multipled by the n detail records. Similarily if you have 2 detail tables in the query and you aggregate items in a detail table you will get incorrect results. Discoverer recognises these situations and raises an error.
Setting the join as 1-1 tells Discoverer that it will get the correct results in these situations and therefore no error is raised. So it is perfectly acceptable to set the joins as 1-1 as long as you know the implications.
Hope that helps,
Rod West

Modelling Time Dimension with Fact Table containing Start Date and End Date

Hi Gurus,
I have a time dimension with Year till Date. I have a fact table which consists of Start Date, End Date, Person ID, Department ID.
How do i design Time dimension with fact table the below scenario
In the dashboard i have start Month and End month as prompts.
In the report i need to display Count(Person ID) > Start Date and < End Date along the trend.
For instance, i have selected Jan-2009 as start date and Apr-2009 as End Date, then i need to display Count(Person ID) of Jan-2009, Feb2009, Mar-2009 andApr-2009.
I Can not connect Time dimension with only Start Date or only with End Date to get the trend along the months.
Please advice on the issue which i am having.

Hi,
Thanks for the response, Infact i tried using Complex join in physical layer. I have considered Time table joined with Fact table, and used >= and took and alias of the Time table and joined fact table using <=. When coming to BMM, i am not knowing how do i design this as if i merge the both the time dimensiona and its alias into single table, values will not be correct and if i make them as seperate columns. i can not show the trend as both are different columns.
Can you please let know where i am going wrong.
Thanks

What is FACT table and FLAT table?

Hello,
         Kindly tell me what is mean by FACT table and FLAT table and how it is use in the BI system ?also tell me can i see these table in the system ?if yes then please tell me the procedure to see the content of the FACT and FLAT table.   And also tell me about the SID table and how to see it.

Cube consists of Fact tables and Dimension tables.
The structure of these tables are "Flat".
Cube consists of two factables... 'F' - Fact table and 'E' - Fact table.
The naming convention will be..
/BIC/F<..Cube name..>   for F Fact table
/BIC/E<..Cube name..>   for E Fact table
Eg: for cube "EMPLOYEE" the names are..
/BIC/FEMPLOYEE
/BIC/EEMPLOYEE
The dimention tables have naming convention..
/BIC/D....
You can check these tables in SE11 or you can use the transaction LISTSCHEMA and then provide the Cube name.
SID's tables are used to link the master data with the dimention tables.

Common diemsions and more then one fact table join problem

Hi,
I have 5 common dimension and 3 fact table which in the same subject area. When I want to display results from more then one fact table sending database then query more then one and I think BI server join this two different result on OBI server. But I think if obi server sending database query for exp. WITH SAWITH0 .... the results get effective.
+++002002:2ea0000:2ea000f:----2009/03/14 10:12:59
-------------------- SQL Request:
SET VARIABLE QUERY_SRC_CD='Report';SELECT "- Common Dimensions"."Year Month" saw_0, "- Subs. Tariff"."Subscriber Current Tariff Type" saw_1, "- Common Measures".Arpu saw_2, "- Common Measures"."Gross Margin" saw_3, "- Call Out"."Callout Dur" saw_4, "- Case".Case_Info_Num saw_5 FROM "CUSTOMER PROFILING" WHERE ("- Common Dimensions"."Year Month" = 200901) AND ("- Subs. Tariff"."Subscriber Current Tariff Type" = 'PREPAID') ORDER BY saw_0, saw_1
+++002002:2ea0000:2ea000f:----2009/03/14 10:12:59
-------------------- General Query Info:
Repository: Star, Subject Area: CUSTOMER PROFILING REV, Presentation: CUSTOMER PROFILING
+++002002:2ea0000:2ea000f:----2009/03/14 10:13:00
-------------------- Sending query to database named CENTRAVEA (id: <<471777>>):
select T223282.DIM_TIME_MONTH_ID as c1,
T221204.DIM_SUBS_CURRENT_TARIFF_TYPE as c2,
avg(T223490.FACT_CP_ARPU) as c3,
sum(T223490.FACT_CP_GROSS_MARGIN) as c4,
sum(T223490.FACT_CP_CO_DUR) as c5
from
DM.DIM_SUBSCRIBER T221204 /* A_DIM_SUBSCRIBER */ ,
DM.DIM_TIME_MONTH T223282 /* A_DIM_TIME_MONTH */ ,
DM.FACT_CUST_PROFILING_PART3 T223490 /* A_FACT_CUST_PROFILING_PART3 */
where ( T221204.DIM_SUBS_ID = T223490.DIM_SUBS_ID and T221204.DIM_SUBS_CURRENT_TARIFF_TYPE = 'PREPAID' and T223282.DIM_TIME_MONTH_ID = T223490.DIM_TIME_MONTH_ID and T223282.DIM_TIME_MONTH_ID = 200901 and T223490.DIM_TIME_MONTH_ID = 200901 )
group by T221204.DIM_SUBS_CURRENT_TARIFF_TYPE, T223282.DIM_TIME_MONTH_ID
order by c1, c2
+++002002:2ea0000:2ea000f:----2009/03/14 10:13:00
-------------------- Sending query to database named CENTRAVEA (id: <<471881>>):
select T223282.DIM_TIME_MONTH_ID as c1,
T221204.DIM_SUBS_CURRENT_TARIFF_TYPE as c2,
sum(T223294.FACT_CP_CASE_INFO_NO) as c3
from
DM.DIM_SUBSCRIBER T221204 /* A_DIM_SUBSCRIBER */ ,
DM.DIM_TIME_MONTH T223282 /* A_DIM_TIME_MONTH */ ,
DM.FACT_CUST_PROFILING_PART1 T223294 /* A_FACT_CUST_PROFILING_PART1 */
where ( T221204.DIM_SUBS_ID = T223294.DIM_SUBS_ID and T221204.DIM_SUBS_CURRENT_TARIFF_TYPE = 'PREPAID' and T223282.DIM_TIME_MONTH_ID = T223294.DIM_TIME_MONTH_ID and T223282.DIM_TIME_MONTH_ID = 200901 and T223294.DIM_TIME_MONTH_ID = 200901 )
group by T221204.DIM_SUBS_CURRENT_TARIFF_TYPE, T223282.DIM_TIME_MONTH_ID
order by c1, c2
I have another subject area and which defined like this subject area contain two dimension and 5 fact table. If I want to display results on this subject area I can see best sql for my database
My problem is why this two different subject areas create different queries. I think following query is the best for database.
Thanks for your help
+++002002:2ea0000:2ea0015:----2009/03/14 10:30:06
-------------------- SQL Request:
SET VARIABLE QUERY_SRC_CD='Report';SELECT "Dim - Segments"."Marketing Segment" saw_0, "Fact - Campaign Response"."Fact Campaign Award Amount" saw_1, "Fact - Customer Interaction"."Issue Response Cost" saw_2 FROM "AVEA ALL" ORDER BY saw_0
+++002002:2ea0000:2ea0015:----2009/03/14 10:30:06
-------------------- General Query Info:
Repository: Star, Subject Area: AVEA ALL, Presentation: AVEA ALL
+++002002:2ea0000:2ea0015:----2009/03/14 10:30:06
-------------------- Sending query to database named AVEA ALL (id: <<474694>>):
WITH
SAWITH0 AS (select sum(T51461.FACT_CMPGN_AWARD_AMOUNT) as c1,
T49384.DIM_MARKETING_SGMNT_DESC as c2
from
DM.DIM_MARKETING_SEGMENT T49384 /* DIM_BI_MARKETING_SEGMENT */ ,
DM.FACT_CMPGN_RESPONSE T51461 /* FACT_BI_CMPGN_RESPONSE */
where ( T49384.DIM_MARKETING_SGMNT_ID = T51461.DIM_MARKETING_SGMNT_ID )
group by T49384.DIM_MARKETING_SGMNT_DESC),
SAWITH1 AS (select sum(T51503.FACT_CUST_INT_ISSUE_RES_COST) as c1,
T49384.DIM_MARKETING_SGMNT_DESC as c2
from
DM.DIM_MARKETING_SEGMENT T49384 /* DIM_BI_MARKETING_SEGMENT */ ,
DM.FACT_CUST_INTERACTN T51503 /* FACT_BI_CUST_INTERACTN */
where ( T49384.DIM_MARKETING_SGMNT_ID = T51503.DIM_MARKETING_SGMNT_ID )
group by T49384.DIM_MARKETING_SGMNT_DESC)
select distinct case when SAWITH0.c2 is not null then SAWITH0.c2 when SAWITH1.c2 is not null then SAWITH1.c2 end as c1,
SAWITH0.c1 as c2,
SAWITH1.c1 as c3
from
SAWITH0 full outer join SAWITH1 On SAWITH0.c2 = SAWITH1.c2
order by c1

I find solution on Oracle® Business Intelligence Suite Enterprise Edition Release Notes.
If you use a version of Oracle Database 10g Release 2 prior to 10.2.0.3, then you might encounter an issue with a Full Outer Join that causes severe database performance issues and appears to hang the database when the Oracle BI Server sends to the database SQL queries that include WITH clauses.
To work around this issue when using Oracle Database 10g Release 1 or 2, upgrade to Oracle Database 10g Release 2 Patch Set 2 (for 10.2.0.3). For performance reasons, this is the preferred workaround.
To work around this issue without installing Patch Set 2, modify the Database Features table using the Administration Tool. This configuration prevents the Oracle BI Server from sending SQL constructs that expose the issue in an unpatched Oracle Database 10g.
To modify the Database Features table:
In the Administration Tool, open the properties of the Physical Database metadata object.
Navigate to the Features tab.
Ensure the values for the PERF_PREFER_MINIMAL_WITH_USAGE and PERF_PREFER_INTERNAL_STITCH_JOIN entries are selected, that is, set to True.

Best way to combine multiple fact tables in single mart

Hi, quick question that I think I know the answer to, just wanted to bounce it off everyone here to make sure I'm on the right track.
I have a HR datamart that contains several different fact tables. Some of the facts are additive across time (i.e. compensation - people get paid on different days, when I look at a month I want to see the total of all pay dates within that month). The other type of fact is more "status over a set of time" - i.e. a record saying that I'm employed in job X with a salary of Y from a given start date to a given end date.
For the "status over time" type facts, if I choose January 2009 (month level) in the time dimension, what I'd really like to see is the fact records that were in place "as of" the last day of the month - i.e. all records where the start date is on or before 1/1/2009, and whose end date is on or after 1/1/2009. Note that my time dimension does go down to the day level (so you could look at a person "as of" the middle of the month, etc. if you're browsing on a day-by-day basis)
I've set up the join between the time dimension and the fact table as a complex join in the physical layer, with a clause like "DIM_DATE.DATE >= FACT.START_DATE AND DIM_DATE.DATE <= FACT.END_DATE". This seems to work perfectly at the day level - I have no problems at all finding the proper records for a person as of any given day.
However, I'm not quite sure how to proceed at the month level. My initial thought is:
a) create a new LTS for the fact table at the month level
b) in the new LTS, add the join to the time dimension
c) in the new LTS, add a where clause similar to LAST_DAY_IND = 'Y' (true for the last day of each month).
Is this the proper way to do this?
Thanks in advance!
Scott

Hi Scott,
I think you're on the right track but I don't think you need the last part. Let me generalize the situation to the following tables
DAILY_FACT (
DAILY_FACT_KEY NUMBER, -- PRIMARY KEY
START_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION FOR START DATE
END_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION FOR END DATE
DAILY_VALUE NUMBER); -- FACT MEASURE
MONTHLY_FACT(
MONTHLY_FACT_KEY NUMBER, -- PRIMARY KEY
MONTH_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION, POPULATED WITH THE KEY TO THE LAST DAY OF THE MONTH
MONTHLY_VALUE NUMBER); -- FACT MEASURE at MONTH LEVEL. DATE_KEY is at END of MONTH
DIM_DATE(
DATE_KEY NUMBER,
DATE_VALUE DATE,
DATE_MONTH VARCHAR2(20),
DATE_YEAR NUMBER(4));
DIM_DATE_END (ALIAS OF DIM_DATE for END_DATE_KEY join)
Step 1)
Make the following three joins in the physical layer:
a. DAILY_FACT.START_DATE_KEY = DIM_DATE.DATE_KEY
b. DAILY_FACT.END_DATE_KEY = DIM_DATE_END.DATE_KEY
C. MONTHLY_FACT.DATE_KEY = DIM_DATE.DATE_KEY
Note: The MONTHLY_FACT DATE_KEY is joined to the same instance of the date dimension as the START_DATE_KEY of the DAILY_FACT table. This is because these are the dates you want to make sure are in the same month.
Step 2)
Create a business model and drag DIM_DATE, DAILY_FACT and DIM_DATE_END into it.
Step 3)
Drag the physical table MONTHLY_FACT into the logical table source of the logical table DAILY_FACT.
Step 4)
Set DAILY_VALUE and MONTHLY_VALUE to be aggregates with a "SUM" aggregation function
Step 5)
Drag all required reporting columns to the Presentation layer.
Step 6)
Create your report using the two different measures from the different fact tables.
Step 7)
Filter the report by the Month that joined to the Start Date/Monthly Date (not the one that joined to the end date).
Step 8)
You're done.
The act of combining the two facts into one logical table allows you to report on them at the same time. The strategy of joining the START_DATE_KEY and the MONTH_DATE_KEY allows you to make sure that the daily measure start date will be in the same month as the monthly fact table.
Hope that helps!
-Joe
Edited by: Joe Bertram on Jan 5, 2010 6:29 PM

Mapping the Fact table to different levels of a dimension

Hi,
I have a fact table which stores the data for 4 levels of the dimensions. The aggregation method was taken care by PL/SQL and the fact table will have the data for all the 4 levels. When im trying to map all the levels to a column in the fact table using the OEM, it is generating the F KEY constraints referncing the columns mapped for the various levels of the dimension.
The problem is that im using a denormalised table for maintaing the values of the dimension. So the columns mapped for the levels(Except for the lowest) can't have the unique key defined on it. The cube is not getting created because of the error in creating the F KEY.
Can u please suggest how to map this fact table.
Thnks,
Manohar Vanama

I am not exactly clear on your schema but I believe you are trying to map tables which are not strict star or snowflake. This means that you cannot use CWM1 (and OEM), unless you change the structure of the tables. You might be able to map the tables with CWM2. The document below will assist you:
Oracle9i OLAP User's Guide
Chapter 4. Designing Your Database for OLAP
Chapter 5. Creating OLAP Catalog Metadata

F and E Fact Tables

Similar Messages

Maybe you are looking for