Chapter 2 Flashcards
Data Modeling Process
- Create the necessary InfoObjects (characteristics and key figures)
- Create the entrance layer with DSOs
- Create data targets
- Create data sources (source systems and DataSources)
- Create extractors
- Create transfer rules
- Use process chains to schedule data load processes
- Create analyses
Semantic Layer
This semantic layer allows you to join different data sources and to create shared definitions. It forms a middleware layer for reporting
Data Warehousing Workbench
- Modeling
- Administration
- Transport Connection
- Documents
- BI Content
- Translation of BW Objects
- Metadata Repository
Characteristic types
- Characteristics with texts
- Characteristics with master data (attributes)
- Characteristics with time dependency (master data and/or texts)
- Characteristics with hierarchies
- Characteristics without texts/master data
Characteristics with Texts
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).
Characteristics with Master Data (Attributes)
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
Characteristics with Time Dependency (Master Data and/or Texts)
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.
Characteristics with Hierarchies
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.
Characteristics without Texts/Master Data
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.
Key Figures
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.
DataStore Objects
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.
DSO Types
- Standard DSOs
- Write-optimized DSOs
- DSOs for direct writing
- Semantic DSOs
Standard DSOs
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.
Write-optimized DSOs
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.
DSOs for direct writing
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.
Semantic DSOs
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.
InfoProviders
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.
InfoCubes
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.
MultiProviders
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.
VirtualProviders
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:
- Using a data transfer process (DTP)
- Using a BAPI
- Using a function module
HybridProviders
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.
InfoSet
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.
Aggregates
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.
