DSO Is Previously Called As ODS. Creation of DSO

DSO is previously called as ODS.
Creation of DSO,
All non-changing fields (characteristics should be dragged into Key fields).

Drag key figures to data fields. Then rest of the steps are same as creating Info
cubes.
Above picture is dataflow for DSO.
Above white columns are index columns. Index columns are not applicable for key
figures because it has changing data.
Until now, SAP BW stood for a data warehousing solution. As of release 3.5 however,
SAP BW offers additional functions such as data mining and BPS that do
not constitute the usual data warehouse functions. This will be taken into
account in the next SAP NetWeaver release, and the description SAP BW will
be replaced by the description SAP Business Intelligence (SAP BI).
ODS Objects are the most important data targets with typically huge amounts of
data. Performance of operations with tables partially depends on the size of those
tables. Keeping tables small can improve performance.
ODS Objects consist of three tables,

. Activation Queue: In this table the new data is stored before activation. The
structure is like a PSA table. The key is made up of the request, data package, and
record number. After activation, a request is deleted from the Activation Queue.
. Table with active data: In this table the currently active data is stored. The table
has a semant key defined by the data modeler for example.order number, order
item). Reporting is done on that table.
. Change Log: During activation, changes in the active data are stored in the
Change Log. You can find the entire history of activations for the ODS Object in that
table because data is not automatically deleted from that table. If data targets
are supplied with data from the ODS Object, in a delta process the data is
read from the Change Log. The Change Log is a PSA table and can be maintained
in the PSA tree of the administrator workbench. That is why the Change Log also
has a technical key that consists of the request, data package, and record number.
Upload and activation process: New data is loaded to the ODS Object and the
technical key is added to the records. Requests can be loaded independently from
each other (sequentially or in parallel). All requests are stored in the activaton
queue first. Activation can be triggered manually or automatically. At the beginning
of the activation, the data is sorted by the semantic key and the technical key.
Therefore, records with identical semantic keys are activated in the same data
package and in the right order. Data packages for activation are then created.
The size of those packages can be customized. Those packages can be processed in
parallel. The maximum number of packages and the server group the activation
runs on can also be customized.
Table names of the involved tables are:

. /BI*/A (active data)
. /BI*/A (activation queue)
. /BI*/B (change log)
The change log table has the same technical properties as PSA tables.
There are no restrictions for parallel upload of data to an ODS Object. Within one
request, parallelism is possible because of packaging (data packets come in parallel
from the source system). Several requests can be loaded in parallel to an ODS
Object as well.
The data is inserted into the activation queue. There are no database accesses
required so a mass insert can be done after processing the update rules. Unlike
InfoCubes, no dimension table entries need to be read or inserted.
For reporting it is necessary to have links from the tables holding transactional
data to master data tables. These links are the so-called SIDs (master data keys).
This is not necessary if you report on the data in the ODS directly with an InfoSet.
Consider this option if determining the SIDs takes too long.
An ODS Object that is enabled for BEx reporting needs to have its data checked
for those links (referential integrity). If SIDs don.t exist they have to be created.
Checking is time consuming and more so is creating SIDs during activation. You
should only flag for BEx reporting if required.
However, the process runs in parallel. For each InfoObject, up to 10,000 master
data values are collected and then a separate process is started to check the SIDs.
The parallel processes can be on the same server as well.
The maximum number of parallel processes is the same as for the activation itself
(see below).
Performance can be improved if InfoObjects are loaded first.
After checking/creating the SIDs, the data is written to the change log and the
active data table. This process runs in parallel because of the sorting that is done
(the same key will not be in two different packages).
Customizing can be done in transaction RSCUSTA2. The number of parallel
processes determines how many packages are processed in parallel for SID
determination as well as for the activation of the data ifself. The minimum number
of data records per data package can be set and a server group can be assigned
for the activation run.
If the unique flag is set, the system relies on unique key combinations during
loading. The loading process can be simplied:
. No sorting is necessary.
. Data does not need to be checked against existing data in the active data.
. Before images don.t have to be created and inserted into the change log table.
. No updates take place, data can be mass inserted.
. Performance will usually be far better if the unique flag is set. So always set
it if applicable. You have to be sure that there will never be any duplicate
records loaded to the ODS Object.
Customizing Loading to ODS Objects
. Customizing in the source system is also relevant for loading to the activation
queue of an ODS Object.
. Activate ODS Object data automatically if possible.
. For huge request splitting into smaller requests may improve
performance.
. Frequency of activation/Size of activation queue is important for
performance because of:
. Overall run time for one activation job
. Runtime for Sorting (non-linear operation)
Data is loaded to the activation queue in the same way as to an InfoCube, so packet
sizes, parallel processes and frequency of Info-IDOC are used in the same fashion.
The size of the activation queue has an impact on the time it takes for sorting
the data during activation because the runtime for sorting operations grows
proportionally. The frequency of activations depends on business needs. However,
if possible and useful, activate data automatically after loading.

Even splitting of a request into smaller sub-requests may improve overall
activation performance.
Customizing in the source system is also relevant for loading to the activation
queue of an ODS Object.
Activate ODS Object data automatically, if possible.
For a large request, splitting it into smaller requests may improve performance.
Frequency of activation/Size of activation queue is important for performance
because of:
. Overall run time for one activation job
. Runtime for Sorting (non-linear operation)

DSO Is Previously Called As ODS. Creation of DSO

Uploaded by

Copyright:

Available Formats

DSO Is Previously Called As ODS. Creation of DSO

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DSO Is Previously Called As ODS. Creation of DSO

Uploaded by

Copyright:

Available Formats

DSO is previously called as ODS.

All non-changing fields (characteristics should be dragged into Key fields).

Above picture is dataflow for DSO.

ODS Objects consist of three tables,

Table names of the involved tables are:

if possible and useful, activate data automatically after loading.

You might also like