What Is A SAP BW DSO And ODS?

[quote]AnSAP BWDSOstands for Data Store Object and was previouslycalled an ODSwhich stands for Operational Data Store. Why has the name changed? Dont ask me! SAP seem to change the names of there product names more often than I have hot dinners. I am sure they have their reasonsA DSO is a SAP BW object primarily used to store detailed transactional data at a granular (document) level. Unlike multidimensional data storage objects like InfoCubes, DSOs are designedas a 2-dimensional flat database table that containskey figures and characteristics. Data can be aggregated as well be over-written.

There are 3 types of DataStore Objects that are generally used in BW systems: Standard, Write Optimized, Direct Update. In this article by RoulaSawma she focuses mainly on the architecture of these three types of DSOs and the main functions of the objects themselves.

Functions of DSOs in a SAP Data Warehouse

First DSOsare mainly used to harmonize data before it is storedin multidimensional InfoCubes in aggregated forms. An example of harmonization would be: say a customer number has 10 characters in a source system A and 13 characters in source system B. BW will harmonize the length of the customer number by creating a DSO with a customer number of 13 characters to ensurethe data from both systems can be stored together without any loss of data.

Second unlike InfoCubes, DSOshave the ability to overwrite data, Add or choose not to update at all. This is all dependant on the logic and delta mechanism used in the DSO.

Third, you can use DSOs for direct reporting but normal reporting scenarios involve a drill down from an InfoCube to a DSO.

Architecture of Standard DSO

The standard DataStoreobject is filled with data during the extraction and load process of the BW system. This process makes use of 3 tables that make up standard DSOs:

1. Activation Queue This table serves to save DSO data records that are to beupdated, but that have not yet been activated. The data isdeleted after the records have been activated.BExreporting can not use this data until it is activated.

2. Active Data Table When the data transfer is triggered, the data is first written to this table. This table containsthe active data and depending on the transformation and delta process that has been definedwill aggregated, add, delete, update records in the DSO. This is the table used for Bex reporting.

3. Change Log Table During the activation process and depending on the transformation that has been created, changes are storedin the Change log table. Here, you can find the complete history of the changes since the content ofthe change log is not automatically deleted. The data targets such as DataStoreobjects or InfoCubesare updatedfrom the change log table if the delta method is triggered on the DSO.Note that upon activation, the data arrives in the change log from the activation queue so that both the old and new records are written to the active table which will also update existing records. See the picture below:

Architecture of Write-Optimized DSO

The Write-Optimized DSO was primarily designed to bethe initialstaging area for data coming into a BW system from an outside source system. The idea is to then move this data into another DSO or Cube. You may wonder what the point of this is. It is all down to speed. It is advisedto use Write-Optimized data store as a first layer for data, as a temporary storage area because it is designed in such a way as to allow very fast data loading.

Write-Optimized DSOs consist of only one table: the active data table. The key benefit of using it is that the data is immediately available for further processing in an active state. Like I mentioned above, this type of DSO is all about speed.

Architecture of Direct Update DSO (3.x ODS)

This is nothing but the previous3.x transactional ODS. It consists of only one table: the active table. Direct update DSO ensures that the data is available quickly, and can be written to the DSO by several users at the same time.

Where do we define the type of the DSO in BW workbench?

This is achievedthrough the Modeling functional area of the BW Workbench Transactioncode RSA1.

Choose InfoProvider, the tree will be displayed on the right hand side of the screen.

Choose the appropriateInfoAreain whichyou want to create the DSO => In its context menu choose Create DataStore Object.

In the screen that follows enter the technical name of the DSO and a description and press the create button that is highlighted in red.

Open theSettingsdrop down list, and press on theEditbutton marked below.

A pop up window appears indicating the three types of DataStore objects:

Standard

Direct Update

Write-Optimized

DSO SummaryDSOs are in no way a substitute of InfoCubes in reporting but using them as part of you BW Data Model provides flexibility in data staging,data cleansing and document/detail level reporting.

...

SAP BI / BW Data Store Objects DSO ods operational data stores SAP write-optimized DSOAbout the Author:PetePete has been working with SAP technologies for over 10 years. He started out as an ABAP consultant and then moved on to BW where he has worked many different clients covering a wide variety of industries. "I love introducing SAP technology (especially BI) to new clients and showing them how they can go from zero to hero within their business in super fast time". Contact me on twitter @PeterMoxon

How To Add Favorites To Your SAP Menu All Posts How To Create SAP ABAP HR Reports Using A Logical Database (LDB)3 Comments1. Laurent THIBERTMarch 27, 2012 at 1:54 pmHi Pete,

Your explanation on the Write Optimized DSO is a bit uncomplete. The initial staging area for data coming into a BW system is still the PSA even for a Write Optimized DSO.

The goal of such DSO is mainly to request its data with the Bex tools in order to provide queries at the raw data level.

Data are going from Write Optimized DSO to standard DSO or cubes with transformation and agregation. Then the data are no more raw.

A strategy for validating a BW project is to compare data before transformation/agregation versus data after transformation/agregation.

In 3.x we can generate an export datasource on the PSA. This datasource is mapped to a virtual provider with transfer/update rules. A query can then request the data upon the virtual provider to display their raw version (from the PSA).

In 7.x the schema is easier help to such Write Optimized DSO which provides the data to the Bex.

In fact such Write Optimized DSO is a PSA but provider of the Bex.

Regards,Laurent

PeteMarch 27, 2012 at 2:15 pmHi Laurent,

Thanks for the comment. You are right in that the PSA is still the staging area but quite often a write-optimized DSO is still used to stage data before moving it onto other BW objects. I think the main point Roula was making is that write-optimized DSOs are great for loading data into BW fast to enable the data to be processed further without slowing down the data load process.

I appreciate the additional information you have added about the 3.x export datasource. Its all good information.

The scope in which BW is used is massive and different companies use the tools in many different ways. Its great to share experiences, tips and trick along the way.