An ODS object serves as a storage location for consolidated and cleansed transaction data on a document (atomic) level.

It describes a consolidated dataset from one or more InfoSources. This dataset can be analyzed with a BEx query or an InfoSet query.

An ODS object contains key fields (for example, document number/item) and data fields that can also contain character fields (for example, order status, customer) as key figures. The data from an ODS object can be updated with a delta update into InfoCubes and/or other ODS objects in the same system or across different systems.

Unlike multi-dimensional data storage using InfoCubes, the data in ODS objects is stored in transparent, flat database tables. Fact tables or dimension tables are not created.

The cumulative update of key figures is supported for ODS objects, just as it is with InfoCubes, but with ODS objects it is also possible to overwrite data fields. This is particularly important with document-related structures, since changes made to documents in the source system do not apply solely to numeric fields such as order quantity, but also to non-numeric fields such as goods receiver, status, and delivery date. To map these changes in the BW ODS objects, the relevant fields in the ODS objects must also be overwritten and set to the current value.

Every ODS object is represented on the database by three transparent tables:

Active data: A table containing the active data (A table)

New data: A table containing new data or data that has been modified since the last activation (M table)

Change log: The change log for delta updates from the ODS object into other ODS objects or InfoCubes.

The tables containing active data and new data have the same structure and are constructed according to the ODS object definition, meaning that key fields and data fields are specified at the same time as the ODS object is defined.

When you update ODS object data, the records are stored initially in the table with the new data. For data that is loaded into BW more frequently than once a day, for example, it is possible to update several requests, one after the other.
The data from one or more requests is transferred in a single activation step out of the table containing the new data and into the table containing the active data. The new data is deleted from the corresponding table. The table with the active data is, therefore, the main table for ODS objects. It contains the data for reporting. When you activate the data, the changes are sent to the change log so that the data in the related ODS objects or InfoCubes is updated accordingly.

1. It is assumed that document 123 has already been updated and activated with an amount of 100 in the ODS Object. The table containing the active records contains a corresponding entry.
2. Document 123, with a changed amount of 60, is updated again in the ODS object, and stored in the table containing the new data.
3. When you carry out the activation step, the new/modified data is transferred into the table containing the active data, and deleted from the table containing new/modified data. In the table containing the active data, the amount 100 is replaced by 60.
4. When you activate the data, the change log is notified: The old record from the active table is saved as a negative (-100) and the new record is stored as a positive (60).
5. If all the records are activated, you can update the changes to the data records for the ODS object in the related ODS objects and/or InfoCubes, in a separate step. The amount in this example, is reduced in the related data targets by 40.

The diagram below shows the data flow in BW, enhanced with ODS objects. The data flow consists of three steps:

1. Updating the data in the ODS object (table containing new data) using transfer rules and update rules.
   The transfer rules transform and cleanse the data from the PSA. At this point, the update rules are generally only used for transferring 1:1 into the ODS object.
2. Activating the data in the ODS object.
   When you activate the data, the data necessary for a delta update is sent to the change log.

3. Updating the data from the ODS object

1. Updating the data in the related InfoCubes or ODS objects.
   In this step, the system uses the update rules to update the data that has not yet been processed in the change log (the delta) in the InfoCubes or other ODS objects. Only update rules are used here, because the data is already available in a cleansed and consolidated format.
2. Transferring data from an ODS object into other BW systems
   In this step, it is possible to use the data mart interface to load data from one BW into another BW. In the BW source system, the corresponding ODS object acts as a DataSource that, through the Metadata comparison, the BW target system recognizes as a DataSource replica. The BW target system is now able to request data from the source system, just as it does with every other DataSource. The requested data is stored in the input storage PSA for further processing, for example, updating into InfoCubes.

The ODS objects are fully integrated with BW Metadata. They are transported just like InfoCubes, and installed from Business Content. The ODS objects are grouped with the InfoCubes in the data target view of the Administrator Workbench - Modeling, and are displayed in a tree. They also appear in the data flow display.

The processes for scheduling InfoPackages for updating into InfoCubes and ODS objects are identical.

It is also possible to schedule the activation of ODS object data and the update from the ODS object in the related InfoCubes or ODS objects.

The individual steps, including the processing of the ODS object, are logged in the Monitor. Logs detailing the activation of the new records from the existing request in the ODS object, are also stored in the Monitor.

In full-update mode, every transaction DataSource contained in an ODS object is updated. In delta-update mode, only those DataSources that are flagged as ODS-delta compatible are updated.