It isn't so much a matter of the number of fact tables as it is the usage. If users need to see Measure A and Measure B in the same report, it should be transparent to them whether or not the measures are in the same measure group (MG), in different MGs in the same cube, or in different cubes.

In AS2000 you had to use different cubes if the dimensions were different. In 2005 I like a single cube as long as most of the dimensions are the same, assuming users will need to analyze the measures together at least some times. So here's how I often look at it:

• I build a single cube for my measures, regardless of the number of fact tables/MGs, as long as the dimensions are mostly similar and users need to perform analysis on measures in different MGs. Note that I could put the measures in different cubes and use the CubeLookUp function but it's slow compared to having a single cube with separate MGs.
• I build separate cubes if the users don't ever need to perform analysis across measures but the dimensions are relatively the same.
• I build separate cubes if the cube needs writeback capabilities or is a mining cube.

How the user interacts with this depends a lot on the tools you choose to give them. If they're using an ad hoc tool like ProClarity or Excel then seeing a huge list of measures can be daunting. Giving them a more structured tool such as PPS or SSRS eliminates that problem