DataStore Objects

7/30/2019 DataStore Objects

1/9

Hema (Kanaka V H Geddam)March 6, 2013


2/9

What is a DSO?Overview of Types of DSOs

Additional Information

Agenda


3/9

A DataStore object serves as a storage location for consolidated and cleansed transactiondata or master data on a document (atomic) level.

A DataStore object contains key fields (such as document number, document item) anddata 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 thesame system or across different systems.

Unlike multidimensional data storage using InfoCubes, the data in DataStore objects isstored in transparent, flat database tables. The system does not create fact tables or dimension tables.

What is a DSO?


4/9

Type of DSO

Use Structure Data Supply SIDGenerationDuringActivation

StandardDataStoreObject

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

It consists of threetransparent, flattables (activationqueue, active data,and change log)

DTP Yes

WriteOptimized

DataStoreObject

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

It consists of justone table of active

data

DTP No (you canchose to

generateduringreporting)

DirectUpdateDataStoreObject

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 justone table of activedata

Externalsystems viafill or delete

APIs

No (you canchose togenerateduring

reporting)

Overview of Types of DSOs


5/9

Transformation rules define the rules that are used to write data to a DataStore object. They are verysimilar to the transformation rules for InfoCubes. The main difference is the behaviour of data fields in theupdate. When we update requests into a DataStore object, we have an overwrite option as well as anaddition option.

In full-update mode, each transaction data DataSource contained in a DataStore object can be updated. Indelta-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 BIsystem or into another DataStore object. This function is only necessary for DataStore objects thatobtained their data from InfoPackages.

If we choose the main menu path Environment Automatic Request Processing, we can specify that thesystem automatically sets the quality status of the data to OK after the data has been loaded into theDataStore object. We can also activate and update DataStore data automatically. Data that has the qualitystatus OK is transferred from the activation queue into the table of active data, and the change log isupdated. The data is then updated to other InfoProviders.

Additional Information


6/9

The tables of active data are built according to the DataStore object definition. The activation queue andthe change log are almost identical in structure: the activation queue has a SID as its key, the package IDand the record number; the change log has the request ID as its key, the package ID, and the recordnumber.

In standard DSOs, data can be loaded from several source systems at the same time because a queuingmechanism enables a parallel INSERT. The key allows records to be labeled consistently in the activationqueue.

The data arrives in the change log from the activation queue and is written to the active data table uponactivation. During activation, the requests are sorted according to their logical keys. This ensures that thedata 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 recordmode responsible for aggregation remains, however, so that the aggregation of data can take place later instandard DataStore objects.

Additional Information contd..


7/9

The system generates a unique technical key for the write-optimized DataStore object. The standard keyfields are not necessary with this type of DataStore object. If there are standard key fields anyway, they arecalled semantic keys. The technical key consists of the Request GUID field (0REQUEST), the DataPackage field (0DATAPAKID) and the Data Record Number field (0RECORD). Only new data records areloaded to this key.

The DataStore object for direct update differs from the standard DataStore object in terms of how the datais 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 inprecisely 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 existin 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 themonitor. However, we can update the data in DataStore objects for direct update to additionalInfoProviders.



8/9

If we switch a standard DataStore object that already has update rules to direct update , the update rulesare 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 beused for analysis purposes.



9/9

Thank You

DataStore Objects

Documents

Transcript of DataStore Objects