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