Skip to Content
author's profile photo Former Member
0
Former Member

ODS Architecture

Posted on Feb 16, 2005 at 06:34 PM 13 Views

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?

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

3 Answers

  • author's profile photo Former Member
    Former Member
    Posted on Feb 16, 2005 at 06:40 PM
    0

    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

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member
      Feb 16, 2005 at 09:22 PM

      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

  • author's profile photo Former Member
    Former Member
    Posted on Feb 17, 2005 at 01:34 AM
    0

    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

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Feb 17, 2005 at 01:31 PM
    0

    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.

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.