Outlining Modeling Concepts

Using the Data Builder, you can define the following objects:

• Table: Local tables for persistence and remote tables for virtual access.

• Graphical view: Intuitive GUI for powerful and easy-to-use modeling for master data and transactional data artifacts.

• SQL view: Powerful SQL editor for models based on SQL or SQL Script.

• Entity relationship model: Import, visualize, edit, and deploy multiple data entities to better manage your modeling concept.

• Analytic model: Define multi-dimensional models to provide the data foundation for analytical purposes (including predefined measures, hierarchies, filters, variables and associations).

• Data flow: Load data from sources to SAP Datasphere with transformation logic.

• Replication flow: Copy multiple data assets from the same source to the same target in a fast and easy way when complex projections are not required.

• Transformation flow: Load data from one or more source tables, apply transformations (such as a join), and output the result in a local table).

• Intelligent lookup: Tool to support look ups to merge data from different entities when manual joins are not sufficient.

• Task chain: Group multiple tasks and run them manually once, or periodically through a schedule.

• Data access control: Set up row level security authorization.

When defining tables and views, a semantic usage is specified. The following types of semantic usage exist:

• Relational dataset: Contains columns with no specific analytical purpose.

• Fact: To indicate that your entity contains one or more measures that can be analyzed.

• Dimension (standard): To indicate that your entity contains attributes that are used to analyze and categorize measures defined in other entities.

• Dimension (fiscal time): To model your fiscal time periods with dedicated semantics, validations and settings.

• Text: To indicate that your entity contains strings with language identifiers to translate text attributes.

• Hierarchy: Contains attributes defining a parent-child hierarchy.

• Hierarchy with directory: Contains one or more parent-child hierarchies.

• Analytical dataset (deprecated): Is deprecated and it's recommended that you use the semantic usage fact instead.

  Note

  You can find more information about the deprecation of the analytical dataset here:

  Analytical Datasets (Deprecated)

In a typical end-to-end scenario, data acquisition is the starting point using federation, replication and transformation functions.

From that point, developers and modelers create views using local tables, remote tables and intelligent lookups to combine, cleanse, and prepare data.

On top of views, you can create analytic models. It is intended to be a top-level model that combines, renames, refines, and enriches the underlying artifacts with further calculations and semantic information. SAP Analytics Cloud and other analytic clients can consume these objects.

As a modeling approach, you can define a data warehousing concept in SAP Datasphere involving different layers:

1. Inbound layer: The foundational data ingestion layer that serves as the entry point for data from various source systems, providing direct 1:1 mapping from source systems with minimal transformation.

2. Harmonization layer: Objects on top of the inbound layer with a strong focus on re-usability, data standardization, semantic enrichment, and creating reusable views on top of the inbound layer with common business terminology and unified data structures.

   • in this layer, the individual data sets get harmonized in terms of standardized semantics from different systems, for example, RBUKRS from SAP ECC and 0COMP_CODE in SAP BW.
   • The harmonization layer is often portrayed explicitly as the preparation layer for the objects in the propagation layer.
   • Use projections (column selection, column renaming, only SUM) to harmonize field names from different systems (for example, RBUKRS from SAP ECC and 0COMP_CODE in SAP BW) and to apply static technical filters.
   • Use data access controls to restrict users from accessing all data.

3. Propagation layer: Objects on top of the inbound or harmonized layer, which provide semantic and value standardization of data from various sources, offering data in a highly harmonized form for further distribution and multiple use.

   • In this layer the individual data sets get combined with joins and unions, data is aggregated if required and dynamic filters are applied.
   • Master data objects and their semantics are modeled in this layer including text and hierarchy associations.
   • Data in this layer is consistent, complete and generally free of redundancy (except for performance reasons or complicated modeling tasks).
   • The propagation layer can also be used for persistent views to serve the persistent architected data marts and is a basis for the reporting layer.

4. Reporting layer: Typically objects (analytic models) that are accessed by reporting tools such as SAP Analytics Cloud.

   • This is where master data joins or associations will be applied. Also exception aggregation, restricted and calculated columns are modeled here.
   • Use data access controls for further restrictions related to reporting on data sets.