Regarding E and F fact tale

[Former Member]

Hi gurus,

I am new to the BW, i am working on the Implementation project. Please let me know when F and E Fact tables come into the picture and is there any difference b/w these two.

Thanks and Regards

SATISH

[Former Member]

Hi Satish,

Also note that the size of the F fact table would be more than the E fact table. Generally the cube is compressed for performance optimization.

Bye

Dinesh

[Former Member]

The F fact table is write optimized while the E fact table is read optimized. When you compress requests in a cube the E fact table comes into effect. Data is stored in partitions based on the defined values...this is normally based on one of the available time characteristics such as calmonth or calyear. In the case of F fact table the partitions are based on request IDs. E fact table data cannot be deleted based on requests as the request ID is dropped while compression.

[Former Member]

Just to clarify Karthik's post - the E fact table by default is NOT partitioned. As long as the InfoCube is empty, you may partition it (See Extras in the menu). E fact table partitioning is only an available option for DBs that support range partitioning - not all do. You have only two options for partitioning the E fact table, 0FISCPER or 0CALMONTH. There is currently no mechanism to add partitions to the E fact table, so you should allocate them out into the future.

Any aggregates that are built on a partitioned E fact table will also be partitioned if they have the partitioning column (0CALMONTH or 0FISCPER) in them.

As mentioned, compression is done to improve query performance. Keep in mind though that once a Request has been compressed, you can not delete it. Most sites typically only compress cubes up until 30 days ago, some more, some less. You compress the data only once you are sure it is correct.

If you search the forum, you'll find several threads on compression that can help anser some of your questions.