Describing the SAP data modeling solutions

If we have a closer look at the hierarchical structure of an SAP solution, we will usually see three layers that have a specific purpose.

Data modeling can be implemented in any of the three layers. SAP solutions are mostly implemented in the lower two layers.

We also need to consider the type of environment in which our SAP data modeling solution is hosted. This could be on-premise, public cloud, private cloud, or hybrid. Let's explore what these mean in simple terms.

SAP data modeling solutions are either on-premise, public cloud, private cloud or a combination of these.

Some of SAP's data modeling solutions are provided as part of an existing SAP software product. For example, SAP HANA calculation view modeling tools are available when you use a SAP HANA database. If you already work with software products that include data modeling tools, it is likely that you will first consider the modeling tools provided before looking at the dedicated, standalone solutions, such as SAP Datasphere.

Let's now briefly introduce each of the SAP data modeling solutions.

SAP HANA is an in-memory database that powers many SAP solutions. But SAP HANA it is more than just a database. SAP HANA is a digital platform that includes not just a database, but also very sophisticated data modeling tools.

The deployment options for SAP HANA are on-premise, private cloud, and public cloud. SAP HANA was first introduced as an on-premise solution. Later, SAP HANA Cloud was offered to appeal to customers who would like access to all the features without committing resources to installing and running SAP HANA.

SAP HANA combines transactional and analytical applications in the same database.

Data modeling in SAP HANA is implemented at the lowest level of our hierarchical layer architecture, which is the database layer. We could say that for SAP HANA there are actually two layers within the database layer: the tables at the bottom, and the data modeling layer on top of the tables. When the data model is called by an application, data is read from the tables and processed in the data models. It all happens inside the database resulting in excellent performance.

The skills needed for data modeling in SAP HANA on-premise are the same for SAP HANA Cloud. This means that teams can work across the deployments.

Data modeling in SAP HANA uses the virtual data modeling approach which means that data is not stored at the data modeling level. The main modeling object in SAP HANA is a graphical object called calculation view. Calculation views are built on top of the database tables. The calculation view supports all key features for data modeling such as filtering, unions, joins, calculations, and aggregations. Using custom SQL code you can also integrate advanced data modeling capabilities such as spatial, text, graph and predictive analytics.

Graphical calculations are created using a graphical editor. SQL code can be added to calculation views when complex data processing is required.

The calculation view can be easily consumed by SAP solutions such as SAP Analytics Cloud, SAP BW/4HANA, or SAP BI tools (e.g., SAP Analysis for Microsoft Office, SAP Crystal Reports). It can also be used by non-SAP tools.

A popular use case for SAP HANA calculation views modeling is to support the development of data marts. A data mart can be described as a subset of a data warehouse. A data mart provides only the data for a specific line of business and is usually focused on a specific set of business performance metrics. It is often owned and managed by a line of business rather than by the IT department.

SAP BW/4HANA is a pre-packaged, on-premise data warehouse solution. SAP BW/4HANA was introduced more than 25 years ago so it has a very large customer base.

The main reasons for implementing a data warehouse solution such as SAP BW/4HANA are to perform data analysis, store historical data, cleanse data and integrate data from many sources using a data loading schedule. SAP BW/4HANA is available both on-premises and as a private cloud deployment. The database for SAP BW/4HANA is SAP HANA. This means that in addition to modelling in the BW/4HANA layer, you can also model in the SAP HANA layer and even combine the models to develop super models!

In SAP BW/4HANA, data modeling is implemented at the application level of our hierarchical layer architecture.

SAP BW/4HANA contains a large number of different modeling objects to support many different modeling scenarios. These are called InfoProviders.

The actual data modeling work is carried out using highly developed graphical tools, called the SAP BW Modeling tools (BWMT). ABAP coding can be used to develop complex customizations to the standard data models. SAP BW/4HANA is a data warehouse solution that supports strategic analytics scenarios with a focus on historical data. These use cases need a persistent data modeling approach, which means the data is captured by SAP BW/4HANA and stored in its SAP HANA database. There are delta mechanisms that capture all changes to the data over time so that the data modeler can look into the past.

SAP S/4HANA is an enterprise resource planning (ERP) solution that supports transactional business processes across all lines of business. SAP S/4HANA runs on the SAP HANA in-memory database and is available as a on-premise deployment, a cloud deployment (public and private), or a combination of both.

You might be wondering why we are introducing an ERP solution in a data modeling Learning Journey. The reason is because SAP S/4HANA includes a component with the name embedded analytics. Embedded analytics is a toolset that includes a ready-made virtual data model with tools to make adjustments, and ready-to-use SAP Fiori apps.

All of the data modeling solutions introduced in this Learning Journey are able to combine data from any sources, SAP and non-SAP. SAP S/4HANA embedded analytics is different. The only data that is processed comes from the tables of SAP S/4HANA.

A key feature of SAP S/4HANA is that transactions and analytics are combined on a single, in-memory platform (database). This means that only one copy of the data is used for both transactional processing and analytics. Analytics runs on the live, transactional tables. Data modeling in SAP S/4HANA is part of a tool kit called embedded analytics.

Embedded analytics provides two components: a comprehensive virtual data model that exposes all the important tables of SAP S/4HANA, and many analytical SAP Fiori apps which enable real-time reporting on top of the data model.

As with SAP BW/4HANA, data modeling in SAP S/4HANA embedded analytics take place in the application layer. However, it is important to distinguish between the virtual data model and the provided SAP Fiori apps. The virtual data model consists of ABAP CDS views that are located in the application layer, whereby the analytical SAP Fiori apps are components of the front end layer.

SAP Analytics Cloud brings together business intelligence, augmented analytics, predictive analytics, and enterprise planning in a single system. With this wide feature scope, SAP Analytics Cloud is often the only analytics solution needed to cover all requirements of an organization. SAP Analytics Cloud is not really a data modeling solution but is more focused on analytics. However, SAP Analytics Cloud is included in this Learning Journey because it offers some basic modeling capabilities. For some customers, this might be sufficient.

SAP Analytics Cloud runs on an SAP HANA Cloud database and both solutions are separated by cloud tenants. In simple terms, they share the same infrastructure and resources.

Based on the connection type, there are two approaches to model data in SAP Analytics Cloud:

1. With live data connections, you can create data models that consume data from on-premise or cloud data sources. You can build stories (visualizations) based on those models and perform online analysis. With live data connections, the data is sourced outside of SAP Analytics Cloud. This feature means that SAP Analytics Cloud can be used in scenarios where data cannot be stored in the cloud for security reasons.

2. With import connections, data is imported (copied) to SAP Analytics Cloud. Further changes made to the source data do not affect the already imported data. Customers need to decide which connection type to set up, according to their own needs.

One of the motivations for using the data modeling tools in SAP Analytics Cloud is the tight integration between the data models and the visualization (story). This makes is easy for a business users to jump between the data model and the visualization without switching tools.

SAP Datasphere is a public cloud data warehouse-as-a-service.

SAP's strategy is to develop a very comprehensive data warehouse capability in the cloud. Many organization who are using SAP Datasphere are, or were once, running SAP BW/4HANA. SAP provides tools to migrate SAP BW/4HANA modeling content to SAP Datasphere.

As with SAP Analytics Cloud, SAP Datasphere runs on the SAP HANA Cloud database. The architectural set up is similar: one infrastructure, different tenants.

The core motivation for SAP Datasphere is to provide business users with a self-service, easy-to-understand data modeling environment that does not require deep knowledge of data modeling. Rather, the intention is to provide a new modeling domain that "speaks" a business-related language and sits on top of the complex data modeling layer created either in SAP Datasphere itself or in another data modelling solution such as SAP HANA or SAP BW/4HANA.

SAP Datasphere has two data modeling layers targeting two different user groups.

• The data layer is where experienced data modelers create their models with a technical approach using the Data Builder tool. The Data Builder therefore contains all the objects and techniques required to do this. Work can be done using either a graphical tool or even a script-based tool.

• The business layer is for business users who create their models using a more semantic approach with the Business Builder tool. This allows business users to work independently from data modelers, while still being able to collaborate and share data with them. The artifacts used here are directly linked to the underlying data layer.

The collaboration between these two roles changes fundamentally. Data modelers can focus on the provisioning of the data, or on complex logic implementation while the business users can optimize the business models.

The SAP BusinessObjects BI Semantic Layer, which is also known as a Universe, is a data model that is created using a graphical tool with the name Information Design Tool.

A Universe combines data from any source, SAP and non-SAP, to provide a semantically rich relational and OLAP data models that hide the complexities of the underlying database tables, to provide a list of meaningful business terms that are familiar to a business user. Universes are created by experienced data modelers, who usually have SQL skills.

Once a Universe is created it can be queried by any compatible analytic tool. The most common tool that is used with a Universe is SAP BusinessObjects Web Intelligence, but the entire SAP BusinessObjects Suite of analytic tools is able to consume a Universe. This means that common, enterprise-wide data models can be created and reused by multiple business units.

A Universe is hosted on a secure, central platform known as the BusinessObjects Enterprise. Analytic tools connect to the platform to consume the data that is generated when a query runs on the Universe. The Universe is an on-premise data model.

Universes have been around for a long time. As a data modeler, it is likely that you will bump into them sooner or later so it is helpful to develop some basic knowledge. They are still used by a large number of SAP customers, many of whom were originally Business Objects customers, before SAP acquired Business Objects in 2007. In a world that is increasingly moving to the cloud, Universes are being replaced with other SAP solutions with better cloud support.

Launch the demo to review the deployment options for each of the data modeling solutions.