SAP Analytics Cloud is an end-to-end cloud solution that brings together business intelligence, augmented analytics, predictive analytics, and enterprise planning in a single system. It is a solution aimed at business users for self-service analytics.
SAP Analytics Cloud enables connectivity to on-premise and cloud-based data sources at the same time. Data modeling with SAP Analytics Cloud can be generally done by using two approaches: Modeling based on imported data, and modeling based on live data.
Importing data means that you copy the source data to SAP Analytics Cloud. After the import, there are then two versions of the data: one in the original source system, and one in your SAP Analytics Cloud. All data from your data source is uploaded (replicated) to SAP Analytics Cloud in-memory HANA Database.
Note
Importing data is sometimes called replication.
With the import functionality, you decouple the status of the source data from the imported data. This is beneficial if you want to avoid changes that are made in the source system affecting your imported data. You can automate the import process and schedule updates on regular basis.
With SAP Analytics Cloud, there are data modeling features that are relevant only to imported models.
Data transformation: Data used in SAP Analytics Cloud models for stories may need to be modified for reporting and analysis purposes. For example, data from a source system that is imported into a model may have multiple columns for employee names - first name and last name. But you may need only one column that combines both first and last names. In the prepare data step, you can perform easy wrangling, do quality checks and perform complex transformations.
Complex model-based calculations: As with every sophisticated data modeling solution, it is important to have the option to extend your data model. In SAP Analytics Cloud models, new values will be implemented through the Formula functionality which allows you to create new measures, which fulfill the reporting requirements. Imagine, you have two measures: sales price and discount in percent. Based on their multiplication you can create a simple formula to generate a new measure to calculate the discounted price. If you look for sophisticated calculations that are part of your model, you have to use models based on imported data. We will cover the different model types in more detail later.
Let`s continue with data modeling using live data:
With SAP Analytics Cloud, you can create models from data sources on-premise or Cloud, build stories based on those models, and perform online analysis without data replication. This means that none of the actual business data is stored in SAP Analytics Cloud but remains in the original source system. This approach is called Live Access and allows SAP Analytics Cloud to be used in scenarios where data cannot be moved into the cloud for security or privacy reasons, or there is just no need to burden the overall storage capacity through additional copies of your data.
Data is "live", meaning that when a user opens a story that sits on top of the live access data, changes made to the data in the source system are immediately reflected. Another characteristic of a live data model is the reuse of data modeling objects that are defined in the source systems. For example, you can consume SAP BW/4HANA or SAP HANA data modeling components with SAP Analytics Cloud.
Let us now explore the data modeling world of SAP Analytics Cloud and familiarize ourselves with its core objects.
Even though we are focusing on data modeling capabilities we have already mentioned several times an object that is not part of data modeling in the strict sense: the story. SAP Analytics Cloud has two main components. Models and Stories. Let us first briefly differentiate between them before moving forward.
Models are where you do all your data modeling in preparation for the analysis. Data modeling in SAP Analytics Cloud includes data transformation, defining your measures and dimensions, enhancing your data by establishing hierarchies, setting units and currencies, and adding formulas.
The next logical step after a data model is created is to build a story on top of it. Stories are used right on top of the models and visualize your data with charts and graphs.
Why do we even mention the story if it is not a data modeling object? The story is the most popular object in SAP Analytics Cloud and a very powerful component. It can not only visualize, but also extend our data models while using Live Access. For example, story-based calculations can even compensate to some extent for a lack of data modeling functionality. Because the story and the data model creation take place in the same environment, it is easy to switch back and forth between the two.
Before we can dig deeper into the different model types we should consider something that applies to any data modeling environment: the difference between measures and dimensions. The reason for this is that data uses common business terminology. For example, if you run a clothing retailer business, your data might include quantities of clothing sold, prices of the clothing items, customer names, or order dates. Each different type provides the data modeler with different possibilities of data manipulation such as aggregation, sorting or filtering and the business user with different ways of navigation such as drill-down. Measures hold numeric values and typically represent quantities that give meaning to your data. In our retail example, it might be the quantity of clothes sold and the price per item. Measures can be used for further calculations. Dimensions on the other hand represent categories that provide perspective on your data such as customer name or order date. Before you can pick the right model, you must first decide which of your data source columns will be represented as dimensions and which as measures. Typically, you group related dimensions together, for example you create the customer group with the customer name and location.
Note
When creating your first model, you can decide between two model types: planning models and analytic models. As we focus on data modeling, we will cover the analytic model only.
Let`s explore the different model types:
Account-based models: For historical reasons there are two types of account-based models: Classic account model and New model. It is recommended to use the New model for reasons such as a more flexible structure, improved calculations or enhanced currency features. We will stick to this recommendation and focus on the New Model only. Accounts-based models have a single measure with multiple accounts. Measures are the structures in your model that hold numeric values. Model values are stored in a single default measure, and you use the account structure to add calculations, specify units, set up an account hierarchy, and set aggregation types for all the data. For example, financial data is broken down by general ledger account (i.e., discounts and gross sales), which is used to describe the values in the measure column (i.e., signed data), which represents transactional data.
Measure-based models: If you want to create a measure-based model, you start with a New model. The New model exposes measures as single entities and lets you add and configure multiple measures with aggregation and units to fit your data. It has accounts but it can have multiple measures which is used to match most financial data models. In addition, new models support model-specific calculated and converted measures.
Analytic models: Analytic models can be based on Live Access and the import approach. Even though a live data model allows to configure the accessed data to a certain degree, you need to use the import model if your data modeling scenario requires more than just a direct provisioning of data. Such requirements might be a necessary transformation of the imported data, a physical combination of data from different source systems, or performance issues that can be tracked back to the source system. The fact that the data is not being provided in real-time may not be a serious disadvantage as updating your data once a day could be more than enough for your specific scenario. Moreover, through the schedule settings you can automatize scheduling jobs to keep your data up to date to some degree without manual work.
Note
To keep things simple, we won`t get more into detail of the account and measure-based models. If you want to learn how to differentiate them, follow the SAP Analytics Cloud learning journey.
Datasets: A dataset can be seen as a model in a broader sense but with some key differences. Other than in the analytic model, it is not necessary to create a model that forms the target for your imported data. It is a simple collection of data, usually presented in a table. Like a model, you can use a dataset as the basis for your story. A dataset is recommended for scenarios when you want to create a story quickly and do not want to get into structure definition, during data processing. Datasets are being supported mainly by the import approach. For data modeling purposes, you can use two different types of datasets. The embedded dataset can use a flat file (e. g., Excel) or another data source object (BW Query) as source and saves the imported data within one story. The data imported through a standalone dataset is being stored in SAP Analytics Cloud and can be used between different stories.
The variety of the different models and the two connectivity options, don`t always make it easy to keep the overview and to choose the right path. Let`s illustrate some of the options in a sequence to enlighten the possible paths.
Launch the video to explore this topic.
Launch the video to explore the next topic.