why using ods?

[Former Member]

i am entry level of BW, in bw ODS, key valuse are drag into data field, characteristics fileds drag into key fields . why this format using?

please any one reply me for future study. i am waiting for reply

[Former Member]

hi venkat

read this link clearly<a href="http://help.sap.com/saphelp_nw04/helpdata/en/c7/dc833b2ab3ae0ee10000000a11402f/frameset.htm">http://help.sap.com/saphelp_nw04/helpdata/en/c7/dc833b2ab3ae0ee10000000a11402f/frameset.htm</a>

this will clear your basics on ODS and solves your problem

nagarjuna

[Former Member]

hi venkat..

welcome to sdn..

There could be many reasons

- when you want to laod document level record and reporting performance is not important

- when you need use the overwrite feature in update rules

- when you have large number of characteristics and key figures all of which are not used in reports, but you do want them to be pulled to BW

- when you want an additional datastaging which can help in creating more update rules at different levels

for more n more details

http://help.sap.com/saphelp_bw33/helpdata/en/f9/45503c242b4a67e10000000a114084/content.htm

http://help.sap.com/saphelp_bw33/helpdata/en/bd/c627c88f9e11d4b2c90050da4c74dc/content.htm

ODS stores the data in 2 dimensional format , It also contain Granular , Detailed data . But Cube will have only summarised data .

So if you need a Report that should show detailed data , Then created a qury based on Cube ans Do an RRI jump to the ODS to show the detailed report .

Eg :

Cube output :

SD NO Net Sales

00001 10000

If you press SD no you can see the item details from the ODS content like ..

ODS output

SD NO Item No Sales

00001 1 2500

00001 2 2500

00001 3 2500

00001 4 2500

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.

We do reporting from ods active table (/bic/A[odsname]00 for our own created or /bi0/A[odsname]00 for business content)

The uses of ODS:

1) It can be used as a Backup of raw data.(ODS AS PSA)

2) It can be used to provide the delta functionality, if the DS is not supporting this

3) Overwrite Functionality will be used ,if any report requirement lead to have it.

4) Some complex logic of transformations(or caluculations) can not be possible at each record level(i.e for ex: storing of Marks on the basis of Sales/returns for a month). Here we need to divide the logic into two steps. part of logic will be executed in the update rules of ODS and remaining part will be executed records comes from ODS)

More details here:

Have a look at these links which have some examples:

http://help.sap.com/saphelp_bw33/helpdata/en/10/54853b175d214ee10000000a11402f/frameset.htm

http://help.sap.com/saphelp_bw33/helpdata/en/a9/49453cabf4ef6fe10000000a114084/frameset.htm

Also Refrer this link

http://help.sap.com/saphelp_nw04/helpdata/en/0e/19b33b90131e73e10000000a11402f/content.htm

Assign points if useful

[Former Member]

Venkat,

Be careful with that assumption. Not all Characteristic fields are dragged into the Key Section of an ODS.

Key Figures, yes, they can't be keys, so they go to the "Data Fields" section.

The best way to decide is, first, know the data. What are the Characteristics which combination makes a record unique in the ODS. For example, if you have an ODS for Material/Plant, every combination of Plant and Material is unique, so Plant and Material are your keys.

At the end, this is the definition of a "KEY". They're unique.

Also, normally, time characteristics form part of the ODS Key as well.

If you create a Generic Extractor from a Table or View, it's even easier. Just use as your ODS Key the same Key fields you have in your Table or View.

Always analyze the specific case and make this question "What Characteristics combination makes each record unique?" The answer is your key.

Hope this helps.

Regards,

Luis

[Former Member]

You need to use a ODS when you have to maintain the data inside BW but in a trasactional way.

The ODS works like a R3 table and maintain the data in that way.ODS doesn not cumulate data as a cube and only maintain certain fields as primary key (like R3 tables).In that way it works as a table and could be the source for an infocube...

Normally tha data in ODS is trasnferred to an infocube in order to report it through a BEX Query.

[Former Member]

See the bolw link,

https://www.sdn.sap.com/irj/sdn/advancedsearch?query=ods&cat=sdn_all

assign points if it hlps you..

MSR

[Former Member]

read THIS hareesh adapala blog in SDN this will help you in detail

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.

This data 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

Before you can begin with modeling, you need to consider how the ODS object needs to be set. Accordingly, select your ODS object type and the implementation variant.

The following ODS objects can be differentiated:

...

1. Standard ODS Object

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

The following implementation variants are conceivable for standard ODS objects:

· ODS object with source-system oriented data: Here the data is saved in the form it is delivered from the DataSource of the source system. This ODS type can be used to report on 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.

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: Contains the change history for delta updating 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.

This graphic shows how the various tables for the ODS object work together during data loading.

Data can be loaded performantly from several source systems simultaneously because a queuing mechanism enables parallel inserting. The key allows records to be labeled consistently in the activation queue.

The data get into the change log via the activation queue and is written to the table for active data upon activation. During activation, the requests are sorted according to their logical keys. This ensures that the data is updated in the correct request sequence in the table for active data.

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 (for more information, see Installing Business Contentsapurl_link_0004_0005_0008). 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.

In ODS there are three types of tables available

1.New table

2.Active table

3.Change log Table

When a new data is entered in to the ODS it is get in to the New data Table, And if u activate the ODS these data will be move to Active table. If there is is any Change occurs in the data based on the key fiels this modification and chages can be entered in the Change log table....and those can categorized based on the Record mode

ODS have 3 tables .

New Table

Change Log table

Active Table.

New Table :

When ever a new data comes from source system through scheduing , It will be in the new data table . Do the scheduling , You will get the status in Monitor as Red Green circle . This means that new table is having data . To view data in new table , Just Rt click the ODS -> Manage -> Requests , You select the table as new and extecute .

Active Table .

To make the data to reach the data target , You activate the ODS , So that data from new is moved to Active table . Then the status will become green. Now the data in the new table will be deleted . The active and change log will have entries .

Change Log table :

This table will keed the entries to do the change log processing such as Before Image , After Image Etc..

Hareesh

[Former Member]

Hi,

ODS gives you detailed level of reporting and this is needed some cases.Check the following links for details.

Regards,

®