Einführung in die Datenmodellierung im Data Builder

IT driven users with the DW Modeler role can import data from connections and other sources, and use flows to replicate, extract, transform and load data.

SAP Datasphere offers multiple modeling capabilities that address different user groups – from business analysts with deep business understanding to tech-savvy developers and power users.

• In a typical end-to-end scenario, the SAP Datasphere Data Layer contains the basic modeling of the underlying data sources and tables. The related set of tools is available in the SAP Datasphere Data Builder. Here, developers and modelers use tables, views, and intelligent lookups to combine, cleanse, and prepare data. You can expose views directly to SAP Analytics Cloud and other analytics clients.
• On top, you can create an Analytic Model. It is intended to be a top-level model that combines, renames, refines, and enriches the underlying artifacts with further calculations and semantic information before exposing lightweight, tightly-focused objects. SAP Analytics Cloud and other analytic clients can consume these objects.
• Some customers have already defined more complex SAP Datasphere Business Layer models instead of Analytic Models to map existing data builder models to new models with business-related terms. The SAP Datasphere Business Builder provides the related set of tools. The Business Builder artifacts can still be created or maintained, but are no longer recommended. Instead, SAP recommends to replace them with Analytic Models or SAC models.

The data builder is the central entry point for creating models. You will learn more details about these object types in the following sections.

You should follow a modular modeling approach. The idea is that master data for each business entity is modeled only once and re-used (associated) in several transaction data contexts. This increases data quality and ensures reusability. The property Semantic Usage reflects the object type of the business data model.

Depending on the semantic usage chosen, you can then define appropriate semantic types for specific columns, such as currency code, date, year, text, language, amount with currency, or quantity with unit. This has an effect in reports, for example, the total amount is not displayed if different currencies are involved. The following options for semantic usage are common:

• Use Fact to generally indicate that your entity contains transactional data. It must have at least one measure defined.
• Use Dimension to indicate that your entity contains master data attributes that are used to analyze and categorize measures defined in other entities. A Dimension must have a key defined.
• Use Hierarchy to indicate that your entity contains parent-child relationships for members in a dimension.
• Use Text to indicate that your entity contains strings with language identifiers to translate text attributes. It must have a key defined that contains exactly one column of semantic type language and a non-key column of semantic type text .

You can associate texts or dimensions for facts, or texts or hierarchies for dimensions. An association acts like a join that is only executed when columns of the dimension or text are demanded in the analysis.