Hema (Kanaka V H Geddam) March 6, 2013

Agenda

What is a DSO? Overview of Types of DSOs Additional Information

What is a DSO?

A DataStore object serves as a storage location for consolidated and cleansed transaction data or master data on a document (atomic) level. A DataStore object contains key fields (such as document number, document item) and data fields that, in addition to key figures, can also contain character fields (such as order status, customer). The data from a DataStore object can be updated with a delta update into InfoCubes (standard) and/or other DataStore objects or master data tables (attributes or texts) in the same system or across different systems. Unlike multidimensional data storage using InfoCubes, the data in DataStore objects is stored in transparent, flat database tables. The system does not create fact tables or dimension tables.

Overview of Types of DSOs

Type of DSO Use

Structure

Data Supply

SID Generation During Activation

Standard DataStore Object

Delta/Change data capture on document level Activation Required Data records with same Key are aggregated Reports and Queries possible

It consists of three transparent, flat tables (activation queue, active data, and change log)

DTP

Yes

Write Optimized DataStore Object

As a temporary storage area for large sets of data As the EDW layer for saving data Fast access No Activation Required Data records with same Key are not aggregated Data is available quickly As a data target for analysis process For external applications and APDs No Activation Required Data records with same Key are not aggregated

It consists of just one table of active data

DTP

No (you can chose to generate during reporting) No (you can chose to generate during reporting)

Direct Update DataStore Object

It consists of just one table of active data

External systems via fill or delete APIs

Additional Information

Transformation rules define the rules that are used to write data to a DataStore object. They are very similar to the transformation rules for InfoCubes. The main difference is the behaviour of data fields in the update. When we update requests into a DataStore object, we have an overwrite option as well as an addition option. In full-update mode, each transaction data DataSource contained in a DataStore object can be updated. In delta-update mode, only DataSources that are flagged as delta-enabled DataStores can be updated. Reconstruction is used to fill a DataStore object with requests that have already been loaded into the BI system or into another DataStore object. This function is only necessary for DataStore objects that obtained their data from InfoPackages. If we choose the main menu path Environment Automatic Request Processing, we can specify that the system automatically sets the quality status of the data to OK after the data has been loaded into the DataStore object. We can also activate and update DataStore data automatically. Data that has the quality status OK is transferred from the activation queue into the table of active data, and the change log is updated. The data is then updated to other InfoProviders.

Additional Information

contd..

The tables of active data are built according to the DataStore object definition. The activation queue and the change log are almost identical in structure: the activation queue has a SID as its key, the package ID and the record number; the change log has the request ID as its key, the package ID, and the record number. In standard DSOs, data can be loaded from several source systems at the same time because a queuing mechanism enables a parallel INSERT. The key allows records to be labeled consistently in the activation queue. The data arrives in the change log from the activation queue and is written to the active data table upon activation. During activation, the requests are sorted according to their logical keys. This ensures that the data is updated to the table of active data in the correct request sequence. In write Optimized DSOs, the loaded data is not aggregated; the history of the data is retained. The record mode responsible for aggregation remains, however, so that the aggregation of data can take place later in standard DataStore objects.

Additional Information

contd..

The system generates a unique technical key for the write-optimized DataStore object. The standard key fields are not necessary with this type of DataStore object. If there are standard key fields anyway, they are called semantic keys. The technical key consists of the Request GUID field (0REQUEST), the Data Package field (0DATAPAKID) and the Data Record Number field (0RECORD). Only new data records are loaded to this key. The DataStore object for direct update differs from the standard DataStore object in terms of how the data is processed. In a standard DataStore object, data is stored in different versions (active, delta, modified), whereas a DataStore object for direct update contains data in a single version. Therefore, data is stored in precisely the same form in which it was written to the DataStore object for direct update by the application. We can only switch between DataStore object types Standard and Direct Update if data does not yet exist in the DataStore object. Since we cannot use the loading process to fill DataStore objects for direct update with BI data (DataSources do not provide the data), DataStore objects are not displayed in the administration or in the monitor. However, we can update the data in DataStore objects for direct update to additional InfoProviders.

Additional Information

contd..

If we switch a standard DataStore object that already has update rules to direct update, the update rules are set to inactive and can no longer be processed.

In the Direct Update DSO, since a change log is not generated, we cannot perform a delta update to the InfoProviders at the end of this process
The DataStore object for direct update is available as an InfoProvider in BEx Query Designer and can be used for analysis purposes.

Thank You