DataStore Objects (DSO) previously referred to Operational DataStores
(ODS is the old acronym) are especially put to use in the BW
environment to stage data and allow for an additional tier of data
cleansing before data is moved to the InfoCube. Having said that, you
could also use a DSO to report from (although not recommended as SIDs
are assembled in real-time) overcoming the need to for an InfoCube. It’s
a great practice to often involve 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 distinctive from an InfoCube? DataStore Objects consist of much fewer tables as data is kept at the detail level. DSOs do not employ 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. Every record is distinct in a DSO attributed to technical keys which I will talk about below.
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 transports it over to the Active Data (00) table and the Change Log table (##…). During the activation, the New Data table gets purged, and a change record is loaded to the Change Log.
Three Types of DSOs:
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
What makes a DSO distinctive from an InfoCube? DataStore Objects consist of much fewer tables as data is kept at the detail level. DSOs do not employ 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. Every record is distinct in a DSO attributed to technical keys which I will talk about below.
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 transports it over to the Active Data (00) table and the Change Log table (##…). During the activation, the New Data table gets purged, and a change record is loaded to the Change Log.
Three Types of DSOs:
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
0 comments:
Post a Comment