ODS Architecture

[Former Member]

For MM Purchasing SAP delivers 2 ODSs, one for item and one for Schedule line. We are considering combining the two into an additional ODS to allow detailed reporting. Other than having data duplicated in two levels, are there any other flaws in this approach?

Also, is it likely that BW 3.5 business content combines the two?

[Former Member]

Thank you all for responding so quicky. Our P2P extractors are very detailed. We have a cube on top of them which pretty much matches the granularity. The suggestion has been made that we revise our cube for higher level reporting and create this combined ods (schedule line and item) for detailed reporting.

[Former Member]

Hi Carol,

Since you are asking our opinion, my stand is you dont need to create additional ODS for your requirements due to the following disadvantage:

1.) Additional Storage Space for your new ODS.

2.) Additional effort to create Update Rules, Transfer rules, extractors, Info packages, etc...

3.) Additional time consumed during data loading.

4.) Will not provide any value since the data you need is already present in other ODSs and could be accessed using <b>MULTI PROVIDERS</b>.

5.) Additional effort to test its correctness.

Hope it helps...

-- Jkyle

[mstrein]

Hi Carol,

the standard aproach would be to use a Multiprovider to combine data from various data providers.

What is you requirement tha made you decide to build an additional ODS?

regards,

Michael

[Former Member]

Hi Carol:

Michael has the best answer, MultiProvider. Keep in mind that the MP is a union operation, not a join. Since the base InfoProviders of the MP are heterogeneous, it would make sense to take some time to review the union vs. join concepts, so that you are aware of the type of data result sets to anticipate. In some queries, it may at first glance appear to be "holes" since certain InfoObjects only exist in one InfoProvider but not the other.

You might consider the InfoSet option, if you find that you really need a join operation.

Another way to approach this would be to implement some RRI (Report-to-Report Interface) pathways to allow the user to jump from a query on the item ODS directly to a query on the Schedule Line ODS for example.

Regards -

Ron Silberstein, SAP