In AS2K (with default settings), when you build dimensions and cubes, the designer automatically counts rows for levels and fact tables. This is not always good for aggregation design, which is where those counts get used. For one thing, you often create a cube with a small set of data and don’t think to change the counts when you move to production. As a consequence, the production database may be way under-aggregated. For another thing, row counts are a great way to influence the aggregation algorithm without having to manually create aggregations: Overstating the fact table rows can result in more aggregations than you otherwise would have gotten. Understating the level member count can result in more aggregations that include that level. (I like the sense of power that comes from lying to Analysis Services.) But if you don’t notice the counts, you’re unlikely to exploit them.
In Yukon, row counts are explicitly displayed as the first step of designing aggregations—which is nice, because that’s where they have an effect. And the property is called “Estimated Count”, which encourages you to put it what you want the number to be, rather than being tied to what the number actually happens to be at the moment. This is good. But it does take away some the sense of getting away with something…
- Reed