Identify the Relationship Between Master Data and Transactional Data

As mentioned in Unit 1, Ben and Cathy both have requirements related to flexibility in choosing attributes and hierarchies when analyzing data. Product is a typical example of a common characteristic used in sales and storage scenarios, with attributes like description, product category, and price. Employee is a typical characteristic to be used in organizational hierarchies.

For our case study, we start with the current situation and detailed requirements regarding product data in relation to transactional sales data.

ITelO aims to incorporate product data into sales reports. This data can change periodically in terms of price, text, or category. They desire to consistently display products with the same list price across all reports, allowing for varying sales prices per individual record. They are interested in showing the category and price, based on sales day data for each product. Furthermore, they want to break down and understand their product inventory by category. Finally, they want the product descriptions to be language-specific for different users.

In this unit, you first consider the storage of master data and transactional data, and learn about the advantages of separating master data and transactional data. This concept is used in SAP BW/4HANA and can be used to meet the requirements for ITelO. For ITelO, the focus is on the InfoObjects Product, Business Partner, and Employee.

You learn how master data and transactional data are separately stored in SAP BW/4HANA, but are automatically combined when running a Query. The use of display and navigation attributes of a characteristic shows how master data can be used in analysis. To understand the behavior of display and navigation attributes in this scenario, have a close look at the tables of a master data-bearing characteristic.

SAP BW/4HANA offers different modeling scenarios related to tracking history. You learn about historical truth, current view, and time-dependent view when presenting the category of products.

The use of hierarchies is explained to navigate the entire set of members with more ease (characteristic values are arranged into groups) when analyzing the data. ITelO wants to use a hierarchy for employee master data that is based on the levels Company Code and Organizational Unit. Organizational changes in the company are reflected with a time-dependent hierarchy structure. Let's see which options are offered in SAP BW/4HANA with time-dependent hierarchy structures.

Let's discuss some scenarios related to master data, like the use of transitive attributes, virtual master data and reference characteristics.

Finally, after modeling, it may happen that master data must be updated based on changed requirements. You learn about the considerations when changing master data values or even changing the definition of a characteristic.

Master data refers to slowly changing data that references business objects and their properties as texts (descriptions), attributes (categories, standard values), and hierarchies (levels of aggregation). Master data is shared across the enterprise.

Transactional data describes business processes and operations, usually by status information and key figures (KPIs).

When modeling information, decide where you need the individual value of a transaction, such as: The actual sales price, or the standard value, such as the list price; or both. This means that you must decide whether to take the value from master data or transactional data.

When standard attributes, such as category or price, are changed, master data is adjusted. The transactional data remains unchanged and reflects the historical truth.

When handling the master data, you can choose to store the texts and attributes in extra fields of the transactional data tables, or in separate master data tables.

Storing texts or attributes together with transactional data means that for each record, the corresponding attribute, or text value is inserted.

Here are the advantages of storing master data together with transactional data:

• No additional join is needed to generate the full set of data as desired in the reports.

• The relationship is preserved when the transactional data is stored. This preservation is important if there's no easy way to retrieve this relationship later.

Here are the disadvantages of storing master data with transactional data:

• Redundancy

  If the same product occurs in several records in a transactional data table or different tables, it leads to redundant storage of the same relationship.

• Inconsistency

  It is difficult to correct information, when texts or attributes differ between different tables, or different entries of one table.

• Confusion

  If there are errors in the original values, they are stored in the huge transactional data tables, and it is not clear why the values are different. Correcting errors is difficult, and it's difficult to find all occurrences.

• Bad staging runtime

  If the attribute relationship changes, it has to be changed in every record of the transactional data table. These changes lead to long loading times and, after the change run, only the new version is visible.

• Fixation

  For changing attributes, only one version is visible. For example, if a product was new when the transaction data was loaded, it remains listed as new years later, even if the status has changed in the source system. Texts are fixed as loaded. Texts also appear in one language only. There's no possibility for language-dependent texts, or different versions of master data hierarchies.

It's recommended to store master data and transactional data separately.

Here are the advantages of storing master data with transactional data:

• Referential integrity

  The idea of referential integrity is to eliminate records with no corresponding entries in master data tables after master data lookup.

• Generate new insight

  With master data reporting, you can see how many products of each category you have, or how often the category of a product changed.

• Key Figures in master data tables.

  Key figures can be used as attributes. For example, the price can be modeled as an attribute for a product, so it is possible to perform calculations that use master data values and transactional values. For example, net sales = price x number of pieces sold.

• Historization

  When using time-dependent attributes, you can save historical changes in the master data only once per change. Then, you can store the validity period for each set of attributes in one record.

• Reduce storage space.

  Master data tables store each relationship only once.

• Language support

  With language-dependent texts, the view can be adapted to the logon language.

• Separate loading cycles

  Master data is updated less often than transactional data. If master data relationships change, no reload of transactional data is needed. When loading master data from different sources, the sequence of data loads determines which values are overwritten.

• Corrections

  It is easier to correct and verify master data in a smaller separate master data table. For example, in the master data table, each product identifier occurs only once with text and attributes (category, price). After joining this information to transactional data records, each row for a specific product contains the same text and category.

• Flexibility

  If master data has changed, the reporting user can choose the global key date.

With the SAP BW/4HANA InfoObject concept, for each InfoObject, separate tables are generated for its texts, time-dependent attributes, non time-dependent attributes, and hierarchies. In SAP BW/4HANA, if you define InfoObjects with language-dependent texts, the correct text is automatically chosen for displaying texts in reports.

In SAP BW/4HANA, master data is stored in separate tables. However, when a Query is run, the Analytic Engine in SAP BW/4HANA automatically enriches transactional data with master data. In the preceding figure, the transactional data, revenue per customer, is enriched with the name of the customer (text) and two attributes (country and discount).

When defining master data for an InfoObject, you can distinguish between these two types of attributes:

• Display attributes

  These attributes are used to enrich the master data in a Query, but can’t be selected in the Query like characteristics of the transactional data. For example, no filtering of transactional data based on values of display attributes.

• Navigation attributes

  These master data attributes can be selected in the Query in exactly the same way as the characteristics of the transactional data.