Compression E-Table vs F-Table

Compression E-Table vs F-Table

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.
 

Does anybody know what the compression factor is between the F-table and the E-table?

I.e. when you move 100 rows from the F-table, how many rows will be added to the E-table?

There is no conversion factor. All the request id's are deleted when you compress the Cube and the records are aggregated based on the remaining dim id's.

Ex- suppose there is only one customer with C100 is doing Transactions & in 100 requests there are 100 records.
Then when you eliminate the request all records are aggregated to 1 record.

If there are 100 customers and you enterd each customer data in each request. Then when you do compression there will be 100 records still because the customer no. Varies.
 

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.
 

If Accessing from E- table is true, do we have to move the records from F table to E table in-order to make the records available for reporting?

Data is automatically moved from F to E fact table when you compress the data in the cube. You can do this in the cube manage->collapse tab.

E table will have data once you do compression, and compression is not mandatory for all the cases. try using aggregates for reports.
 

When we do roll-up in InfoCube maintenance, records are moved to aggregates? or moved from F table to E table?

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.

I guess what the question was how we can compress a data inside a cube, I assume that's usually done through by deleting the Request ID column value. 
This can be done through Manage - > Compress Tab.

---------------------------------------------------------------------

How to Compress InfoCube Data

Go to RSA1
Under Modeling --> Choose InfoProvider --> InfoArea and then --> Select your InfoCube

Right Click on your infocube --> from context menu --> choose Manage

Once you are in manager data Targets screen:
Find out the request numbers – decide till what request id you want to compress

Go to Collapse tab – under compress --> choose request ID and click Release

The selected request ID and anything below will be compressed.

What is happening behind the scene is  “After the compression, the F fact table contains no more data. 
Instead, the compressed data now appear in the E fact table.”

Infocube Compression

I was dealing with the tab "compression" while managing the infocube, was able to compress the infocube and send in the E- table but was unable to find the concrete answer on the following isssues:

1. What is the exact scenario when we use compression?

2. What actually happens in the practical scenario when we do compression?

3. What are the advantages of compressing a infocube?

4. What are the disadvantages of compressing a infocube?

1. Compression creates a new cube that has consolidated and summed duplicate information.

2. When you compress, BW does a group by on dimensions and a sum on measures... this eliminates redundant information.

3. Compressed infocubes require less storage space and are faster for retrieval of information.

4. Once a cube is compressed, you cannot alter the information in it. This can be a big problem if there is an error in some of the data that has been compressed.

I understand the advantage to compressed the infocube is the performance.  But I have a doubt.  If I compressed one or more request ID of my infocube the data it will continue to appear in my reports (Analyzer)?

The data will always be there in the Infocube. The only thing that would be missing is the request id's.. you can take a look in to your packet dimension and see that it would be empty after you compress.

Compression yeap its for performance. But before doing this compression you should keep in mind one thing very carefully.

1) If your cube is loading data with custom defined deltas you should check whether delta is happening properly or not, procedure is compress some req and schedule the delta.

2) If your system having outbounds from cube and this happening with request ids then you need to follow some other procedure because request ids wont be available after compression.

These two things are very important when you go for compression.