This website is not affiliated with, sponsored by, or approved by SAP AG.

Compounding of Info Objects

Business Warehouse

Moderators: Snowy, thx4allthefish

Compounding of Info Objects

Postby aceleron » Thu Nov 04, 2004 2:14 am

Hello ,

I would like to know if there can be preformance issues if compounding infoobjects are used in some 5 to 6 Dimensions of a Info Cube.

Regards,

BW learner
aceleron
 

Compounding of Info Objects

Postby ParinGada » Thu Nov 04, 2004 2:43 am

Generally No, there will not be any different performance issues because of compounded InfoObjects.

Also do you mean that you are going to add main characteristic and its compounded object in the different dimension?

If you are not clear, give us details, what exactly are you trying to achieve with reasons behind, and surely you will receive right suggestions.
Regards,
Parin
ParinGada
 
Posts: 149
Joined: Sun May 30, 2004 6:27 pm

Re: Compounding of Info Objects

Postby CHC » Thu Nov 04, 2004 2:57 am

ParinGada wrote:Also do you mean that you are going to add main characteristic and its compounded object in the different dimension?


especially as it makes no sense to have the characteristic without its compounded object...
CHC
 
Posts: 4100
Joined: Tue Oct 22, 2002 2:27 am

compounding of infoobjects

Postby celeron » Thu Nov 04, 2004 3:00 am

hello,

We have to load data from 5 SAP instances into BW and we have a plant ,Purchasing Organization which is same in 3 systems hence we are forced to compound Purchasing group,plant,Vendor,material with Source system.

any clues...

Bw Learner
celeron
 
Posts: 4
Joined: Fri Oct 01, 2004 5:39 am
Location: Helsinki

Re: compounding of infoobjects

Postby CHC » Thu Nov 04, 2004 3:02 am

aceleron wrote:any clues...

What is your actual question ?
CHC
 
Posts: 4100
Joined: Tue Oct 22, 2002 2:27 am

compounding of infoobjects

Postby celeron » Thu Nov 04, 2004 3:56 am

Hello CHC,

In SAP R/3 we have 3 source systems say 100,200 & 300.
For source systems 100 and 200 one plant has been defined in SPRO as P1 with a different location. Say in 100 PL1 is in Germany and in 200 PL1 is England.
Hence we are forced to compound characterstics like Zplant,Zpurch org,Zpurc Group ,Z material with 0source system.

I would like to know what are the pitfalls with respect to Query runtime performance.

Regards,

Bw learner
celeron
 
Posts: 4
Joined: Fri Oct 01, 2004 5:39 am
Location: Helsinki

Postby CHC » Thu Nov 04, 2004 4:11 am

Following to my own experience in compounding objects with 0soursystem, the only issue is when you have to do it in an already live system, as you then have to reload everything. Think also about the fact you have to compound each level (costcenter compounded = controlling area compounded as well, for instance)

Regarding performance itself, I don't see any issue as it works like any other characteristic.
It could have been a problem if you had, say 100 char to compound to 100 different chars because then you would have multiplied the number of chars in your cube by 2, but with your scenario, the difference should be marginal.

Ch
CHC
 
Posts: 4100
Joined: Tue Oct 22, 2002 2:27 am

Postby geierf » Thu Nov 04, 2004 4:34 am

Just a thought on the other side:
If you compound plant with sourcesystem, the end-user will have to assign the sourcesystem key to a plant (and know what's the country behind).

As we would like to have the queries as simple as possible, we have compounded such objects with the company code that is well known to the enduser.

I am aware that you can have several company codes per plant, but we just double the master data there. And in the transaction data we extract the company code anyways, so the connection will always be defined.

Cheers
Frank
geierf
 
Posts: 123
Joined: Mon Oct 04, 2004 6:30 am
Location: Switzerland

0sourcesystem

Postby chetan » Thu Nov 04, 2004 6:42 am

Hi

My views and observations

in Big Installations for Millions data volume
Compounding even on one level has large performance issues i seen.
Recommendation is always go for concatenation
Depending on Business scenario
as 0SOurcesytem & company code can scatter amongst internal organization for intra company reference purpose as well and we have scenario where one plant has several company codes and in voluminous scenario it does impact performance.

I would suggest to concatenate the key field company code and plant or source system these also avoids later issues when some new sourcesystem comes in picture or company codes go on growing,

Hope it Helps
Chetan
@ CP...
chetan
 
Posts: 1434
Joined: Mon Dec 09, 2002 1:39 pm
Location: New York City - Manhattan

Postby not_yet_a_bw_guru » Thu Nov 04, 2004 9:40 am

I would recomend concatenation too.

Read the white paper on consolidated info objects it will give you a few design ideas.

We have implemented an enterprise data warehouse and feeding one bw system with 2 sap systems and 2 non sap system.

We decided to go down the consolidated info object route.

Nothing wrong with compounding.... but if you have more than 3 source systems, maintaience is a b***h.
not_yet_a_bw_guru
 
Posts: 337
Joined: Fri Jun 11, 2004 10:15 am
Location: Chicago

Postby CHC » Thu Nov 04, 2004 9:50 am

Well, I am not a datawarehouse expert so I will not try to convince anybody else than myself.
I just wonder how you explain your end-user that this shitty concatenated value is the same as the normal one is the R3 system they know ; this is a step avoided with normal compounding.
CHC
 
Posts: 4100
Joined: Tue Oct 22, 2002 2:27 am

Postby not_yet_a_bw_guru » Thu Nov 04, 2004 11:22 am

True...

Having said that its more of a disign than anything else.

You only use the concatinated object as the key buy you still have the original as an attribute and thats what you use in your queries.

There will also be a little training involved. But it works like a charm :)
not_yet_a_bw_guru
 
Posts: 337
Joined: Fri Jun 11, 2004 10:15 am
Location: Chicago

Compounding infoobjects

Postby chetan » Fri Nov 05, 2004 6:14 am

not_yet_a_bw_guru wrote:True...

Having said that its more of a disign than anything else.

You only use the concatinated object as the key buy you still have the original as an attribute and thats what you use in your queries.

There will also be a little training involved. But it works like a charm :)


True
I am speakng of my own experience and with consultation of SAP AG.
cannot name the client but these Instalation i refer to is TOP 5 BW installations in USA,quite huge and extensive cutting all the SAP modules

Hope it Helps
Chetan
@ CP...
chetan
 
Posts: 1434
Joined: Mon Dec 09, 2002 1:39 pm
Location: New York City - Manhattan

compounding of INFOOBJECTS

Postby aceleron » Fri Nov 05, 2004 7:54 am

Hello Chetan,

You are right ...
I am confused what to do now...
Now we have 0Plant which is compounded by 0source system and then storage location , so inthat aspect it is the only characterstic with more than 1 compounding level.
Apart from this compounding of 0source system is with material ,vendor,purchase org.

so even going with cosolidated info objects will increase the work of implementation also cost.
So we have to see which is good in the long run.

Reply

BW learner
aceleron
 

Compounding Attributes

Postby BWJunior1 » Sat Nov 06, 2004 4:52 am

Hai BW learner
Even sap also won't support compounding when u r looking for Performance,ok,Validation is required,better to Upload masters before uploading Transactions and set to skip Transaction data record if masters are not available,that is best and correct way

Rgrds
BW Junior1
BWJunior1
 

Next

Return to Business Warehouse

Who is online

Users browsing this forum: No registered users and 8 guests





loading...


This website is not affiliated with, sponsored by, or approved by SAP AG.