cancel
Showing results for 
Search instead for 
Did you mean: 

Load to ODS first ?

Former Member
0 Kudos

Hi all,

I am now confuse of what concept is actually the right one.

Let's say I have a standard datasource with delta capability. Normally I will load it directly to a cube. But, I have seen someone do it in the way that load to ODS first, then do delta upload from this ODS to cube.

What are the benefits of doing this ? Will it affect performance or make support easier ?

Please have your opinions. Thanks.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Thanks.

Why is it better to have a staging layer in form of DSO first before coming to cube for delta supported datasource ?

Then, from what you said, is it possible that one datasource only support delta for DSO and not for cube ? Is there any example.

Former Member
0 Kudos

Hi,

having a staging layer will allow you to e.g. store line item data in BW in order to be able to do special reporting on them. In a cube you normally store the data much more aggregated. Posting real delta data to a ods/dso will make it necessary to set the keyfigures to addition in the update rules/transformation.

If a datasource support delta this is not depending on the data target, but if a datasource doesn't provide a delta or at least only a generic delta you have to post it to a ods/dso first so that the ods/dso will build the delta for you (here you have to set the keyfigure update mode to overwrite).

regards

Siggi

Answers (4)

Answers (4)

Former Member
0 Kudos

Thanks all for your inputs. Points have been rewarded.

Former Member
0 Kudos

So, can I conclude that :

For delta enabled datasource, I do not need to load to ODS first before to cube unless I have a requirement to drilldown to more details level.

Then, what is the difference if I just put all the details infoobject into the same cube ?

Please advice again. Thanks.

Former Member
0 Kudos

Hi,

first --> correct

second --> it is just a question of performance. Your cube will be a lot bigger then and you will have to deal with creating more aggregates, maybe with compression of the cube .....

regards

Siggi

Former Member
0 Kudos

Hi.........

1) We use DSO depending on the Recordmode................

The properties of the delta process for a DataSource:

• Delta type (explained in detail later)

• Record modes in the delta process (explained in detail later)

• Serialization

The record mode now describes the type of change that a data record contains.........Following r the different types of recordmodes..........

The characteristic values are as follows:

• ' ': The record provides an after image.

The status of the record is transferred after it has been changed, or after data

has been added. The record can only be directly updated to an InfoCube if

the corresponding before image is in the request ........

• 'X': The record provides a before image.

The status of the record is transferred before it has been changed or deleted.

All attributes for the record that can be aggregated (key figures) must be

transferred with a reversed plus/minus sign. Responsibility for reversing the

plus/minus sign lies either with the extractor (default) or with the service

API. These records are ignored in a non-additive (overwriting) update of a

DataStore object. The before image complements the after image.

• 'A': The record provides an additive image.

With attributes that can be aggregated, only the changes are transferred.

In the case of attributes that cannot be aggregated, the status after data

was changed or created is transferred. The record can be updated to an

InfoCube without restrictions, but requires an additive update to be made

to a DataStore object.

• 'D': The record must be deleted.

Only the key is transferred. This record (and therefore the DataSource too)

can only be updated to a DataStore object.

• 'R': The record provides a reverse image.

The content of this record is equivalent to a before image. The only

difference occurs when updating a DataStore object: An existing record

with the same key is deleted.

• 'N': The record provides a new image.

The content of this record is equivalent to an after image without a before

image. A new image should be transferred instead of an after image when a

record is created. The new image complements the reverse image.

So here u can see.............like in case of if only after image is send..........then it can be updated only in a DSO first............because DSO has the overwritten property............infocube is always Additive........Only if both after image and before image is sent ..........then only the value can be directly updated in a cube...........

2) Now also in case of RDA...................data hav to be loaded to the DSO..............bcoz in case of Real Time Data Acquisition..............data is always loaded to the Standard DSO.............it cannot be loaded in a cube..................because generally RDA is used for Operational reporting..........

Hope this helps........

Regards,

Debjani........

Former Member
0 Kudos

Thanks Siggi.

Ok, so in ODS I can load the data in more details way. But if my report only needs the summary figures, do I still need to load to ODS first before loading to cube ?

Is there any benefits for support team if I load to ODS first ?

Former Member
0 Kudos

Hi,

no, if your datasource provides real delta you don't need to post the data to a ods/dso first. This is just a possibility in case you have the requirement to do very detailed (line item) reporting for specific reasons.

Siggi

former_member205352
Active Contributor
0 Kudos

Having a DSO will help as staging layer for your data.

Also the choice depends on delta support capablility of datasource.

Like ABR is supported for both cube and DSO directly.

If your datasource supports delta for cube then you can load directly to cube but its bette to have a staging layer in the form of DSO.

If your datasource doesnt support delta for cube and supports only for DSO then ofcourse you need DSO.

Hope thie helps.