Dimension Count

The best means of keeping data growth under control is to consider factors early in the design phase that will impact data scale, especially in a post allocated state. The number of dimensions used in the application is the first scalability consideration.

Be cautious about adding more dimensions to the data without a solid reason. Data growth in Oracle Hyperion Profitability and Cost Management is mostly impacted by the number of splits of data into smaller and smaller values. Before adding new dimensions, verify that a new physical dimension is required. First time Profitability and Cost Management designers commonly adopt all of the dimensions present in the source data simply because they are there and might, someday, be needed.

Consider if the dimension is required for either reporting final results or differentiating data in order to support an allocation process . If neither of these are true, you should strongly consider eliminating the dimension.

If the additional dimension is really an alternate expression of an existing dimension, consider using an alternate hierarchy or attribute dimension instead. This will provide the means for reporting on the desired categories without increasing data size.

While limiting dimensions is strongly advised, adding a dimension for future growth is a good idea. As long as the dimension is only using a single "nomember" selection in all model artifacts, the "spare" dimension will have little impact on performance.