Chapter 2

Question 1

Data Modeling Process

Answer 1

1. Create the necessary InfoObjects (characteristics and key figures)
2. Create the entrance layer with DSOs
3. Create data targets
4. Create data sources (source systems and DataSources)
5. Create extractors
6. Create transfer rules
7. Use process chains to schedule data load processes
8. Create analyses

Question 2

Semantic Layer

Answer 2

This semantic layer allows you to join different data sources and to create shared definitions. It forms a middleware layer for reporting

Question 3

Data Warehousing Workbench

Answer 3

1. Modeling
2. Administration
3. Transport Connection
4. Documents
5. BI Content
6. Translation of BW Objects
7. Metadata Repository

Question 4

Characteristic types

Answer 4

1. Characteristics with texts
2. Characteristics with master data (attributes)
3. Characteristics with time dependency (master data and/or texts)
4. Characteristics with hierarchies
5. Characteristics without texts/master data

Question 5

Characteristics with Texts

Answer 5

Characteristics with texts are surely the most frequent instance of InfoObjects. This type is used whenever there is descriptive text in addition to a key value. The plant key and corresponding text are shown as an example (see Table 2.2).

Question 6

Characteristics with Master Data (Attributes)

Answer 6

The most important element for data modeling is the characteristics (InfoObjects)
 with attributes (other referencing characteristics). These additional attributes are
 called master data for the characteristic.

Customer Class
Characteristic with text that explains the key and makes it language-dependent
City
Characteristic without text, which saves a value that is not explained further
Country
Characteristic with text that explains the key and makes it language-dependent

Question 7

Characteristics with Time Dependency (Master Data and/or Texts)

Answer 7

This type of characteristic represents a peculiarity within the group of characteristics described above. It is often necessary to allow certain attributes for a characteristic
to change over time. For example, a customer can belong to different customer classifications over the course of several years. If you need to map these changes in the analyses, it’s often necessary to save these changes in the InfoObject.
Therefore, each attribute provides an option of setting it time-dependently
for the InfoObject. When this option is active, all combinations of characteristic
and attribute are assigned time stamps for Valid from and Valid to.

Question 8

Characteristics with Hierarchies

Answer 8

The most frequently used method is creating hierarchies
directly for the respective InfoObjects. SAP provides several example hierarchies of
InfoObjects: You can use the cost centers and organization hierarchy from SAP ERP,
for example.

Question 9

Characteristics without Texts/Master Data

Answer 9

This is a special kind of characteristic. Only texts or key values for an InfoObject are loaded, for example, but the keys are not translated or elaborated in any more detail. They are usually used to model city and street names. The special InfoObjects

Calendar day and Calendar year do not require supporting texts either.

Question 10

Key Figures

Answer 10

used whenever numbers are given a specific correlation and will be used for calculation in some way later. Key figures can be created either with or without units. A key figure such as number, for example, which counts the
number of records, is created without a unit. In contrast, weights and revenues are usually assigned units. Revenues always have a currency unit as specification.
Weights and other key figures need units so they can be set in relation.

Therefore, the most important factor when modeling key figures is to define the units correctly.

Question 11

DataStore Objects

Answer 11

While InfoObjects represent the central modeling elements in the BW system, the DataStore objects (DSOs) are the main level in EDW.

These DSOs not only save the data in the form of transparent tables but also calculate necessary items, such as deltas between the old and new datasets. It’s possible, for example, for a DSO to calculate current stock levels. To do so, the respective stock changes are written to a DSO and the new stock levels are calculated there. These figures can then be updated in InfoObjects (to see a minimum stock notification, for example) or in InfoCubes for reporting.

Question 12

DSO Types

Answer 12

1. Standard DSOs
2. Write-optimized DSOs
3. DSOs for direct writing
4. Semantic DSOs

Question 13

Standard DSOs

Answer 13

They consist of three logical units:

• New data
• Active data
• Delta

The new data collects all new data from the respective source system at the request level. When this data is transferred to the active data, it is merged. If the stock of a stock material has dropped from 250 pieces to 150, for example, the value 250 is overwritten with 150 in the active data. At the same time, a delta record is generated that contains -100 pieces. This record can then be updated in the respective data targets. We therefore recommend using the standard DSO as the inbound data store for all data sources in EDW.

Question 14

Write-optimized DSOs

Answer 14

A write-optimized DSO is a standard DSO that only consists of one table: the active data. As a result, all data is still aggregated there, and a special key combination
is used to ensure that data is overwritten. This DSO is used whenever the data from the data source is already delivered in a logical, sensible form. Data from this DSO can also be updated in the data targets using deltas.

Question 15

DSOs for direct writing

Answer 15

This DSO is not filled with transfer rules using a data flow, but instead with ABAP programs. As a result, it can be used as a data target for Integrated Planning or for results from the Analysis Process Designer (APD). It can also be used for custom applications, because it can be called through various defined BAPIs.

Question 16

Semantic DSOs

Answer 16

This new type of DSO is another special form of the standard DSO. The difference is that the data that would usually be stored in a DSO can be partitioned.

This partitioning is performed based on defined characteristics; we recommend using the time. The BW system then creates a DSO with its own data flow for each logical partition and controls the filling in the respective transfer rules automatically.

Question 17

InfoProviders

Answer 17

InfoProviders and the data targets in the BW system serve to provide data to end users in a prepared reporting format.

It’s necessary to separate the data retention and reporting levels clearly. Therefore, the InfoProviders are always subject to change when the reporting requirements change.

Question 18

InfoCubes

Answer 18

An Info- Cube is a physical data store that saves the data in what is called an extended star schema (see Figure 2.9). In this schema, there is a central table, the fact table, which houses the key figures. This fact table then refers to the dimension tables, where the characteristics for the later evaluations are stored.

Always create InfoCubes specifically for your current reporting requirements. If you want to store data for potential reporting requirements in the future, store the data in a DSO, not in the cube. When new requirements arise, create additional cubes that meet these new requirements or change the existing cubes.

Question 19

MultiProviders

Answer 19

MultiProviders are a flexible tool in BW for aggregating data that lies in different InfoCubes. A join is defined for the different providers and key figures can be analyzed jointly.

A good example of a MultiProvider is a case where you want to evaluate planned and actual values together to create a cost accounting. The actual values are usually in one InfoCube, while the planned values are in another. You can now link these two data buckets by defining the characteristics for the join. The characteristics used in the two InfoCubes are usually identical: In this case, for example, both have the cost center, the cost element, and the same time characteristics such as Fiscal Year and Fiscal Year/Period. As a result, these two key figures can
now be analyzed jointly.

Question 20

VirtualProviders

Answer 20

VirtualProviders are providers that load data directly from the assigned source system without saving them in BW. The data is led through the defined processes and then transferred to the OLAP processor, which formats the data for the report.

VirtualProviders can load data into BW in the following ways:

1. Using a data transfer process (DTP)
2. Using a BAPI
3. Using a function module

Question 21

HybridProviders

Answer 21

HybridProviders are a hybrid form of DSO and InfoCube. Data that is new in the DSO is displayed immediately, even if the update in the InfoCube is not finished yet. As a result, reports based on new data
in BW can be run much more quickly, without having to wait for the data load to finalize.

The dvantage of HybridProviders over VirtualProviders is that the data is stored permanently in BW and is updated in the respective InfoCube in just a few
minutes or hours. Therefore, the request for the source system is only needed once. In contrast, the VirtualProvider has to request the data repeatedly because the data is not persistent in BW. When a HybridProvider is created, a DSO and an InfoCube are always created together with the corresponding data flow.

Question 22

InfoSet

Answer 22

Similar to MultiProviders, InfoSets group together data from different data sources. In contrast to MultiProviders, however, InfoSets do not have unions, but instead have true joins. The resulting dataset is always the multiplied set of hits for each data source.

InfoSets are particularly useful when additional master data has to be analyzed, in addition to data from the InfoProviders. A standard example is the “slow-moving item” scenario in warehouse stocks. In this case, an InfoSet is made for a DSO or an InfoCube for sales figures, and the Material InfoObject is created. You can now evaluate which materials have not been sold.

Question 23

Aggregates

Answer 23

The concept behind aggregates is very simple: A new, reduced InfoProvider is defined in the Data Warehousing Workbench, based on the original InfoProvider.

This reduced object contains only the specific characteristics needed for the respective BW query or query group. The aggregates are filled completely automatically whenever new data is loaded into the InfoCube. Meanwhile, end users don’t have to worry about whether they create a report using an aggregate or directly with the InfoCube.