Modeling: Is Fact Table partitioning that important?

Question

I read of how much partitioning a fact table can speed a query.  On an upcoming project with specifications for only 4 InfoCubes, how can we take advantage in partitioning to fact tables to speed up queries?
Can this be factored into the design now or, we should wait till queries on Cube begins to perform poorly?
Thanks.

Answer 1

Spend some time reviewing the links others have provided and serach SDN.
As mentioned, there are two types of partitioning generally talked about with SAP BW, logical and physical partitioning.
<u><b>Logical partitioning</b></u> - instead of having all your data in a single cube, you might break into separate cubes, with each cube holding aspecific year's data, e.g. you could have 5 sales cubes, one for each year 2001 thru 2005.
You would then create a Multi-Provider that allowed you to query all of them together.
A query that needs data from all 5 years would then automatically (you can control this) be split into 5 separate queries, one against each cube, <b>running at the same time</b>.  The system automatically merges the results from the 5 queries into a single result set.
So it's easy to see when this could be a benefit. If your queries however are primarily run just for a single year, then you don't receive the benefit of the parallel processing.  In non-Oracle DBs, splitting the data like this may still be a benefit by reducing the amount of rows in the fact table that must be read, but does not provide as much value to an Oracle DB since Infocube queries are using a Star_Transformation.
<u><b>Physical Partitioning</b></u> - I believe only Oracle and Informix currently support Range partitioning.  This is a separately licensed option in Oracle. 
Physical partitioning allows you to split an Infocube into smaller pieces. The pieces, or partitions, can only be created by 0FISCPER or 0CALMONTH  for an InfoCube (ODSs can be partitioned, but require a DBAs involvement).  The DB can then take advantage of this partitioning by "pruning" partitions during a query, e.g. a query only needs data form June 2005
The DB is smart enough to restrict the indices and data it will read to the June 2005 partition. This assumes your query restricts/filters on the partitioning characteristic.  It can apply this pruning to a range of partitions as well, e.g. 0FISCPER 001/2005 thru 003/2005 would only look at the 3 partitions.
It is <u><b>NOT</b></u>smart enough, however, to figure out that if your restrict to 0FISC<u>YEAR</u> = 2005, that it should only read 000/2005 thru 016/2005 since 0FISCYEAR is NOT the partitioning characteristic.
An InfoCube MUST be empty in order to physically partition it.  At this time, there is no way to add additional partitions thru AWB, so you want to make sure that you create partitions out into the future for at least a of couple of years.
If the base cube is partitioned, any aggregates that contain the partitioning characteristic (0CALMONTH or 0FISCPER) will automatically be partitioned.
In summary, you need to figure out if you want to use physical or logical partitioning on the cube(s), or both, as they are not mutually exclusive.
So you would need to know how the data will be queried, and the volume of data.  It would make little sense to partition cubes that will not be very large.