DataStore Objects (DSO) formerly known as Operational DataStores (ODS is the old acronym) are primarily used in the BW environment to stage data and allow for another layer of data cleansing before data is moved to the InfoCube. However, you could also use a DSO to report from (although not recommended as SIDs are generated in real-time) bypassing the need for an InfoCube. It’s a best practice to always include DSOs in your source to target data flow. The three containers of data within your data flow should be DataSource (source of data) –> DSO (detail level data) –> InfoCube (data to be reported).
What makes a DSO different from an InfoCube? DataStore Objects consist of much fewer tables as data is stored at the detail level. DSOs do not utilize the ‘Extended Star Schema’ and therefore it is best to not report from this type of InfoProvider. DSOs are essentially a flat table (think of a spreadsheet) where data is dumped into.
When data is loaded into a DSO, it first gets sent to the New Data (40) table. The data will sit in the New Data table until it is activated, which then ships it over to the Active Data (00) table and the Change Log table (##…). During the activation process, the New Data table gets wiped out, and a change record is loaded to the Change Log.
New Data (Activation Queue) table
when data is loaded into DSO, its first stored in this table..
key fields consist of
* Request ID - Number given to each data loading
* Package ID - Request ID is divided into number of data sets known as Package ID
* Record number - Individual records in each package ID are assigned a number . this is record number.
Active Data Table
The data from the active data table is generally used for reporting. This table can also supply the full data upload to another data target. The key field chosen while designing a DSO is the key of this table.
The activation process moves data from new data to active data... The process is actually cut and paste..
after activation data wont be available in new data.. it will be available only available in active data.. and change log table...
Change Log Table
All of the changes to existing records are recorded in the change log table.
when we load data to DSO..
the data will be available only in New data table... and wont be available for reporting or any other needs..
after activation data will be cut and pasted to active table and change log table.
the data will be available only in New data table... and wont be available for reporting or any other needs..
after activation data will be cut and pasted to active table and change log table.
now data is available in active data table and change log table...
when we do query on DSO... data is actually taken from active table..
one of the main plus point of DSO is.. its overwriting capability..
lets see how it is done..
new request id is copied in new data table..
now lets activate our new request RQ2..
as you can see change log table has all track of all records...
Three Types of DSO's:
Standard (most commonly used)
When to use- Line item detail level
Capable of using secondary indexes to improve read performance
Secondary indexes are set within the DSO modeling screen, lower right
Remember to delete data from change log regularly as it will continue to grow overtime and cause performance issues
Any data no longer being used in the active table should be archived
Associated tables:
New Data: /BIC/Adsoname40
Active Data: /BIC/Adsoname00
Change Log: /BIC/########## (dynamically generated)
Write-Optimized (less common)
When to use- When data does not need to be updated, just written
Every record is ‘written’ not ‘updated’ so data loads quickly
Uses a technical key
[RequestID | DataPackage | DataRecordNumber]
Uses an optional semantic key that the user defines for ordering/grouping data logically
If you enable the ‘Do Not Check Uniqueness’ checkbox
semantic keys will become disabled
data will load faster
reporting will be slower
Build indexes on what is accessed most often
Associated tables:
Active Data: /BIC/Adsoname00
Direct-Update (least used)
When to use- When data is only needed in one version, active
Data is written using BAPIs and Function Modules
Associated tables:
Active Data: /BIC/Adsoname00
Standard (most commonly used)
When to use- Line item detail level
Capable of using secondary indexes to improve read performance
Secondary indexes are set within the DSO modeling screen, lower right
Remember to delete data from change log regularly as it will continue to grow overtime and cause performance issues
Any data no longer being used in the active table should be archived
Associated tables:
New Data: /BIC/Adsoname40
Active Data: /BIC/Adsoname00
Change Log: /BIC/########## (dynamically generated)
Write-Optimized (less common)
When to use- When data does not need to be updated, just written
Every record is ‘written’ not ‘updated’ so data loads quickly
Uses a technical key
[RequestID | DataPackage | DataRecordNumber]
Uses an optional semantic key that the user defines for ordering/grouping data logically
If you enable the ‘Do Not Check Uniqueness’ checkbox
semantic keys will become disabled
data will load faster
reporting will be slower
Build indexes on what is accessed most often
Associated tables:
Active Data: /BIC/Adsoname00
Direct-Update (least used)
When to use- When data is only needed in one version, active
Data is written using BAPIs and Function Modules
Associated tables:
Active Data: /BIC/Adsoname00
No comments:
Post a Comment