Write Optimized DSO

Write Optimized DSO

This can be used a base level DSO where the data can be stored same format as it is extracted from source.  Most of the cases the data is saved as replica of PSA, wherein, even if the PSA is deleted the data is always present in this layer.

• Records with the same key are not aggregated, but inserted as new record, as every record has new technical key.
• There are No SIDs generated for this DSO, which decreases the load time.
• It allows parallel load, which saves time for data loading.

Reporting can be done on this DSO but it is not recommended.

Data that is loaded into write-optimized DataStore objects is available immediately for further processing. There is no activation needed for the DSO, saving time. No SIDs are generated and the DSO consists of only ‘Active Table’.

Delta cannot be created based on entries (image based delta ) as they do not have change log, but a request based delta is possible.

For performance reasons, SID values are not created for the characteristics that are loaded. The data is still available for BEx queries. However, in comparison to standard DataStore objects, you can expect slightly worse performance because the SID values have to be created during reporting.

Semantic Key

They act as key fields in the DSO, similar to the std. DSO key fields. They help is getting unique records in the DSO, as they do not allow duplicates. The regular technical key of the Wdso would be Request GUID field(0REQUEST), the Data Package field (0DATAPAKID) and the Data Record Number field (0RECORD).

Semantic Key identifies error in incoming records or Duplicate records, thus protects Data Quality such that all subsequent Records with same key are written into error stack along with incorrect Data Records.

My Notes
Semantic keys
they can handle duplicate records..
But if the same record is coming in a next load, it filters out those values tooo...

I think it works when deleting and reloading the data