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 transactionaldata 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 checkedfor 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. Youshould only flag for BEx reporting if required.However, the process runs in parallel. For each InfoObject, up to 10,000 masterdata 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 theactive 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 parallelprocesses determines how many packages are processed in parallel for SIDdetermination as well as for the activation of the data ifself. The minimum numberof data records per data package can be set and a server group can be assignedfor the activation run.

If the unique flag is set, the system relies on unique key combinations duringloading. 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 setit if applicable. You have to be sure that there will never be any duplicaterecords loaded to the ODS Object.Customizing Loading to ODS Objects. Customizing in the source system is also relevant for loading to the activationqueue of an ODS Object.. Activate ODS Object data automatically if possible.. For huge request splitting into smaller requests may improveperformance.. Frequency of activation/Size of activation queue is important forperformance 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 packetsizes, 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 sortingthe data during activation because the runtime for sorting operations growsproportionally. 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 overallactivation performance.Customizing in the source system is also relevant for loading to the activationqueue 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 performancebecause of:. Overall run time for one activation job. Runtime for Sorting (non-linear operation)