Treating measure aggregation values as dimension attribute values for slice and dice

  • At my company a decision has been made to make use of a third party analytical product (consisting of SQL database and SSAS cubes on the back end). One of the internal development tasks is to generate the necessary ETL's to feed data to this beast.

    The required inputs have been provided by the vendor (in consultation with the business needs), broken down for the most part by facts and dimensions.

    Some of the required dimensional attributes are actually measure values aggregated to the granularity of the dimension, and then either stored as that value or transformed via a rank or categorization function to produce a dimensional attribute. As a simple example, imagine that the "customer" dimension had an "activity level" dimension attribute, with allowed values of "low", "medium" or "high", based on the count of transactions they had performed over the previous six months. This would be a SCD type 1 attribute in the dimension.

    This kind of "fact value as dimension attribute" presents some problems to the BI team, because some of the aggregations/measure algorithms are not at all trivial. Indeed, these are clearly the kinds of values you would expect to be *outputs* of an analytical engine, not *inputs*.

    How would you approach this problem? Would you attempt to calculate these analytical outputs via SQL (perhaps made easier with the additional power of windowing functions in 2012). Would you build a cube and then query the cube via MDX as part of the ETL? Would you do something else entirely?

Viewing 0 posts

You must be logged in to reply to this topic. Login to reply