Model Blending

The following sections provide sample use-cases and explanations of how Model Blending is used to seamlessly integrate relational data points into an analytic model using Dynamic Member Calculations that leverage the relational blending API functions of the finance engine.

A common challenge in analytic modeling is how to build a sustainable model when the definition of metadata and data becomes blurred.  The two use cases below provide examples of this modeling challenge. 

Use Case 1

In many cases, analytic modelers are faced with the challenge of building a model containing Dimension Members that are unknown at design time or forced to build a Dimension containing Members that will be constantly changing.  Without relational blending, analytic modelers are forced to build models full of unknown members (TBD1, TBD2, etc.) with the hopes that users of the system do not need values beyond these placeholder members.  (This data is transactional and not a good candidate for an analytic model, Workforce Planning is a good example of this problem)

This is a one-to-many issue so Drill-Back and Application Blending work well if the summary Cube is the primary focus of analysis and transactions are only used for supporting details.  Model blending can provide a benefit as well, but keep in mind that model blending must relate an analytic cell POV to a relational row or summarized row (one-to-one).  For Model Blending to be useful in these circumstances, the relational data must be returned in an aggregate format (avg, min, max, sum, count) in order to reduce the one-to-many relationship to a one-to-one Relationship.

Use Case 2

Analytic models that depend on Dimensions with Members that are constantly changing.  Consider business problem where the analytic model is based on a fixed number of members (facility with rooms and beds).  This is easy from a modeling perspective; however, the user requirement is to build a model that is aware of the current occupant of the bed.  The logical metadata definition is room/bed, but the business problem requires the “occupant” to be defined as a Member for the model to be meaningful.  If occupant is used as a Member in the model, it is almost guaranteed that the analytic model will eventually become unsustainable due to the changing nature of the room/bed/occupant Dimension.  The administrator of this model now has the burden of constantly changing and rebuilding the model to reflect the current occupant data. 

This is a one-to-one issue, so Model Blending fits well and provides a tremendous amount of value.  Detailed and changing information can be continuously loaded and updated as attribute information in the OneStream Staging tables, Custom Relational Tables and the Model Blending API can be used to dynamically incorporate this information into analytic model through dynamic member formulas.

Model Blending Benefits

Relational blending is similar to the OneStream Staging engine in that it is a tool to protect the analytic engine.  Analytic modelers are aware that there is a powerful force with which they must contend when they are trying to create a well-designed, well-performing and maintainable model.  That powerful force is Factorial Combination Math.  Analytic modelers understand that numbers of possible cells in a model (combinations) is determined by the number of Members in each Dimension multiplied by each other (1,000 Accounts x 100 Cost Centers x 10,000 Employees x 20 Regions = 20 billion combinations).  This phenomenon means that analytic modelers are in a constant battle.  They are trying to capture the data points required to understand the business process being modeled and model performance challenges created by the computational physics of factorial combination math.  In summary, it is easy to create an analytic model with a massive number of potential cells and as a result, end up with a poor performing model.

Relational blending can help keep the size of an analytic model to a manageable level by allowing leaf level members to be kept in the relational table and only keeping summarize/static Members in the analytic model definition (Dimension Members).  Relational blending is not a cure-all, but it is an important tool for building maintainable well performing analytic models when a model has some dependencies on detailed information that cannot be clearly defined as metadata or data.  In other words, the information is useful in the model, but it is so detailed or changes so much that it is difficult to incorporate into a rational metadata structure.