ODS Object

ODS Object

Definition

An ODS object acts as a storage location for consolidated and cleaned-up transaction data (transaction data or master data, for example) on the document (atomic) level.

It describes a consolidated dataset from one or more InfoSources. This dataset can be evaluated using a BEx 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 or master data tables (attributes or texts) 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. Furthermore, a source can be made delta-capable by overwriting it and using the existing change log. This means that the delta that, for example, is further updated in the InfoCubes, is calculated from two, successive after-images.

Use

There are different ODS object types. Before you can begin with modeling, you need to consider how the ODS object needs to be set. Accordingly, select your ODS object type.

The following ODS objects can be differentiated:

1. Standard ODS object: There are three different types of applications:

• Inbound ODS object: The data is saved in the same form as they are when delivered from the source system. This ODS type can be used to report the original data as it comes from the source system. It serves to handle administration more comfortably and to selectively update.
• Consistent ODS object: Data is stored here in granular form and consolidated. This consolidated data on a document level creates the basis for further processing in BW. To do this, compare level one of the
Implementation Scenarios
• Application-related ODS object: The data is combined here according to the business-related problem and can be used specifically as a basis for operative reporting problems. You can report directly for these ODS objects, or you can continue to update them in InfoCubes. To do this, compare level two of the
Implementation Scenarios.

2. Transactional ODS object. The data is immediately available here for reporting. For implementation, compare with the
Transactional ODS Object.

Structure

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

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

Activation queue: For saving ODS data records that are to be updated but that have not yet been activated. The data is deleted after the records have been activated.

Change log: For updating delta from the ODS Object into other data targets, such as ODS Objects or InfoCubes for example.

An exception is the transactional ODS object, which is only made up of the active data table.

The tables containing active data are constructed according to the ODS object definition, meaning that key fields and data fields are specified when the ODS object is defined. Activation queue and change log are the same in the table’s structure. They have the request ID, package ID and the record number as a key.

Data can be loaded from several source systems at the same time. The queueing mechanism allows parallel insertion. The key allows records to be labeled consistently in the activation queue.

The data is loaded into the change log via the activation queue and reaches the active data table when activated. From here, it is made available for reporting. During activation, the requests are sorted according to their logical keys. This ensures that the data is updated in the active data table in the correct request sequence.

See also the Example of Updating Data to an ODS Object

Integration

Integration with data flow

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

1. Loading the data from the DataSource into the PSA.
   In this step, the data from a source system DataSource is loaded and stored in the transfer structure format. The PSA is the input storage location for BW. DataSources with the IDoc transfer method are not supported with ODS objects.
2. Updating the data into the ODS object, and activating the data

• Updating the data into the ODS object using transfer and update rules.
  The transfer rules transform and clean up the data from the PSA. Generally, the update rules are only used here for one-to-one transfer into the ODS object. This is because transformation has already taken place in the transfer rules. The data arrives in the activation queue.
• 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. The data arrives in the table of active data.

3. Updating the data from the ODS object

• Updating the data in the related data targets such as InfoCubes or ODS objects, for example.
  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) into InfoCubes, other ODS objects, or master data tables. Only update rules are used here, because the data is already available in a cleansed and consolidated format.
• Transferring the 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 the BW target system recognizes as a DataSource replica, through the metadata comparison. 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, such as updating into InfoCubes, for example.

Integration with the Administrator Workbench - Modeling

Metadata

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 InfoProvider view of the Administrator Workbench - Modeling, and are displayed in a tree. They also appear in the data flow display.

Update

The update rules define the rules that are used to write to an ODS object. They are very similar to the update rules for InfoCubes. The most important difference is how the Data Fields Are Updated. When you update requests in an ODS object, you have an overwrite option as well as an addition option.

The Delta Process , which is defined for the DataSource, also influences the update. When you are loading flat files, you have to select a suitable delta process from the transfer structure maintenance, this ensures that you use the correct type of update.

Unit fields and currency fields operate just like normal key figures, meaning that they must be explicitly filled using a rule.

Scheduling and Monitoring

The processes for scheduling InfoPackages for updating into InfoCubes and ODS objects are identical. Error handling is an exception here. It cannot be used with ODS objects.

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

The individual steps, including the ODS object processing, 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.

Loadable DataSources

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