Identifying the Differences Between Model Types

A model is a representation of the business data of an organization or business segment. You can use a model as the basis for your story.

The Modeler is where you can create, maintain, and load data into models.

Analytic models are read-only models. You'd typically use an analytic model for data reporting or if you want to analyze your data, looking for trends and anomalies. They do not have any required dimensions or measures.

Unlike the read-only analytic models, planning models allow write-back to the planning data source. Because designated planners can write data, planning models require Version and Date dimensions to designate what the written data is, and for what time frame.

Planning models are prepared and preconfigured to help you perform business planning tasks such as forecasting or budgeting, and planning users can use a variety of features to update and create new values in the model.

In a typical workflow, the structure of the planning model is created and then Actual data is imported. The Actual data is typically copied to a Plan version and then the data is adjusted to accommodate expected changes in the planning time frame.

Both analytic and planning models can be created using account or standard model configuration.

Version dimension within the model supports the creation of new (empty) versions and the deletion of existing (empty) versions. This helps to improve the administration of data versions for planning and analytics scenarios.

SAP Analytics Cloud offers a number of model configurations regarding account dimensions and measures.

Some model configurations are more flexible than others, and allow you to add additional measures to a model. This is a fundamental extension of the structure used by an account model, and provides more flexibility as well as key benefits for both analytics and planning.

Account models refer to the configuration where the model structure consists of a mandatory account and a default single, unique measure created automatically by the application. Standard models, as opposed to account models, refer to the configuration where the model structure allows for multiple measures and an optional account dimension. The main difference between the different model configurations is how they handle measures.

The standard model offers the best of both worlds. It has multiple measures but can also use an account dimension. In addition, standard models support model-specific calculated and converted measures. In this course, standard models are used for all examples and exercises.

The standard model type exposes measures as single entities and lets you add and configure multiple measures with aggregation and units to fit your data. It provides plenty of flexibility; you can match the structure of an account model by using measures and an account dimension, or you can remove the account dimension when it is not required for your use case.

There are two configurations for standard models:

1. Model with measures and no Account dimension.

   This simpler configuration removes the account properties and formulas. For example, you want to create an analytic model with non-financial data or you have a sales scenario that focuses on a single account.

2. Model with measures and an Account dimension.

   This model configuration has two main structures, which can give more flexibility. For example, you want to be able to add calculations both to accounts and measures in the model.

Model with Measures and no Account Dimension:

Model with Measures and an Account Dimension:

Account models are configured with account dimension and a default single measure. Account models (sometimes referred to as classic models) have a single measure associated with multiple accounts. This model offers less flexibility and capabilities than a model with measures. We strongly recommend using standard models instead.

In an account model, model values are stored in a single default measure, and you use the account dimension's structure to add calculations, specify units, set up an account hierarchy, and set aggregation types for all the data. In the following example, data is broken down by Account (Discounts, Gross Sales, Quantity, and Cost of Sales), which is used to describe the values in the measure column (SignedData.) Those values represent transaction data associated with other dimensions (Product and Date).

If you are unsure of the model configuration that will best suit your data, you can refer to About Model Configurations for specific use-cases.