Getting Started New sletters

Store

Welcome, Guest

Login

Register

Search the Community

Solutions Industries Lines of Business

Services & Support Training & Education University Alliances

About SCN Partnership Events & Webinars

Downloads Developer Center Innovation

Activity Brow se Communications Actions

7 Replies Latest reply: Nov 18, 2008 10:27 PM by Ram Goswami

Share

Tw eet

Like

Ram Goswami Nov 17, 2008 10:28 PM

Dimension issue
This question has been Answered. Guys, I understand designing dimensions in infocuve play an important role when it comes to performance both dataload and query sides. I read some interested tips on sdn etc. like the following: 1. small dimensions 2. few dimensions (less important than small dimensions) 3. only as many details as necessary 4. characteristics in the 'right' order (technical order >>> most selective first) 5. hierarchies only if necessary 6. time dependent structures only if necessary 7. avoid MIN, MAX aggregation for key figures in huge infocubes I have 20 chars and 8 keyfigures and I am asked to design an infocube. I know we are only limited to 13 dimensions. Each of which can have up to 248 chars and 233 keyfigures. How do I know which char to group with with another char and put them in one dimension and which one will go as a line item dimension? If I made every dimension as line item dimension, I won't have enough dimensions. Please help. Someone on SDN saif that 1:1 char should go into one dimension but I am having tough time understanding this. sample: Char1: Char2: Char3: Char4: Char5: Char6: Char7: Char8: Char9: Char10: Char11: Char12: Char13: Char14: Char15: Char16: Char17: Char18: Char19: Char20: When looking at 1:1 relationship. What 2 chars am I comparing this 1:1....Char1:Char2 ??? Char1:Char3??? and so on Thank you, RG

Correct Answer by Ajeet Kumar Singh on Nov 18, 2008 9:40 PM HI Ram, The same rule applies with all the 20 chars. You will have to group all of them logically. Genrally company codes sales org division distribution channel are commmon and should be put together.all sold to party, shipt to party, payer, bill to party should go together..... I generally put all the dates together all the document numbers as line item. You know better about the source system and should be aware of the kind of data you get. try to analyze the source records before creating the cube. You can use the program SAP_INFOCUBE_DESIGNS to see the existing cubes which are loaded into production and try to see what is the ratio for the dimensions for which combinations of characteristics .This will give you a fair amount of idea.the one for which the dimesion is showing in red are badly built. After creating and data loadings of the cube you can check the dimensions behaviour in RSRV well.Here also you can see the dimension percentage of the cubes. then modify them accordingly...after 2 or 3 takes I think you should have an idea. Thanks Ajeet

Helpful Answer by Ajeet Kumar Singh

532 View s

Average User Rating (0 ratings)

Ajeet Kumar Singh Nov 18, 2008 5:13 AM (in response to Ram Gosw ami) Re: Dimension issue Hi, The characteristics in the dimension are chosen wisely. you should go by functional knowledge as well as bit experience. Try to avoid those characteristics in the same dimension which generates more number of combination. Or try to put those char in the dimension which belong to each other. For example Sales document item category and item number have 1:1 relation i.e. each item will have one category asscociated with it. So you will put them together in one dimension along with all those char which are related to items...eg. item description,item lenght etc. Another example You have different kind of material objects ...e.g. material,material plant( material compounded with plant),etc. Different kind of customer objects e.g. customer,customer sales,customer partner, etc. Since the value of material and customer is always the same in different infoobjects.....You will put all the material objects in the same dimension...all the customer objects in the same dimension.This will reduce the size of dimension...if you put customer and material together then the size of dimension will be beyond imagination. You will put all the company lebel information in same dimension like,sales org,company code, etc. Go for line item only for those objects which are huge in number like billing doc,material doc,sales doc,...which are always unique. they are only made line item so that they do not combine with other objects and create many record for every one records of material.... and generate huge dimension table.

Hope it explains. Thanks Ajeet

Like (0)

Ram Goswami Nov 18, 2008 5:41 PM (in response to Ram Gosw ami) Re: Dimension issue Ajeet, Thanks for your reply, I think you are saying that I need to find KEYS in my chars. like the example you gave "Sales document item category and item number have 1:1 relation i.e. each item will have one category asscociated with it.". Sales document category and item number are keys. Did I understand you correctly? Also what do you mean when you say "Since the value of material and customer is always the same in different infoobjects.....You will put all the material objects in the same dimension...all the customer objects in the same dimension"Thanks, RG

Like (0)

Ajeet Kumar Singh Nov 18, 2008 6:12 PM (in response to Ram Gosw ami) Helpful Answer Re: Dimension issue Hi, For your understanding you can take it as keys. Bascially its just a concept to keep the size of the dimension table as small as possible. And as I have written depends mainly on how the data is coming from R/3 data source. "Since the value of material and customer is always the same in different infoobjects.....You will put all the material objects in the same dimension...all the customer objects in the same dimension" By this I meant....you can put different infoobjects which contains same kind of values like cusomer sales...customer compounded with comapny codes...this all if put together in same dimension will not result in more then one combination and therefore only on record in the dimension table. For above example when you load the data from R/3 ...for a particular record in the cube all these fields will generally contain the same value so when put together in the dimension table will not create many combinations. But if you try to put a customer address with material it will create lot of combination as one customer can have many material sold to it and therefore per customer many records. ...but if customer address is put in a dimension with customer then we will get only one record per customer. I hope it explains. Thanks Ajeet

Like (0)

Debjani Das Nov 18, 2008 7:01 PM (in response to Ram Gosw ami) Re: Dimension issue Hi Ram.... Always try to keep the the size of the dimension table as small as posiible........Before grouping characters in a dimension.........always keep this thing in mind......

Suppose if u put Customer and material in a single dimension............just imagine the size of the table.......one customer can take different materials............So if u do permutation combination......what will be the size of the dimension table........ But if u put Material number and material description in one dimension....................then its ok......For one material there will be only one description................number of characteristics in a dimension is directly proportional to the overload in load time. ............For an example............ Two charcteristics with no correlation Char A and Char B. Assume that every day when the transactions are loaded to the InfoCube, there are 1,000 new values of Char A and 1,000 new values of Char B. If each Char is in a separate dimension, then the load process only has to read the number range tables for each of the dimensions 1,000 times ( total of 2,000 reads ) to get the next Dim ID number. The load process then has to insert 1,000 records into each of the dimension tables ( total of 2,000 writes ). Now what happens if you put both Chars in the same diemsnion. Since they are unrelated, you potentially could have a combination of characteristics where every value for Char A, you have every possible value of Char B - or 1,000 * 1,000 combinations of values. That would translate to 1,000,000 reads of the number range table and 1,000,000 inserts to the Dimension table.................So there lies the problem.............. Regards, Debjani.........

Like (0)

Ram Goswami Nov 18, 2008 9:01 PM (in response to Ram Gosw ami) Re: Dimension issue Guys, Thanks a lot for your valuable information. I am much more clear than before. However, the examples you guys provided will only suite if I were to have 2 chars. What do I do when I am dealing with 20 or more chars? Thanks a lot again RG

Like (0)

Ajeet Kumar Singh Nov 18, 2008 9:40 PM (in response to Ram Gosw ami) Correct Answer Re: Dimension issue HI Ram, The same rule applies with all the 20 chars. You will have to group all of them logically. Genrally company codes sales org division distribution channel are commmon and should be put together.all sold to party, shipt to party, payer, bill to party should go together..... I generally put all the dates together all the document numbers as line item. You know better about the source system and should be aware of the kind of data you get. try to analyze the source records before creating the cube. You can use the program SAP_INFOCUBE_DESIGNS to see the existing cubes which are loaded into production and try to see what is the ratio for the dimensions for which combinations of characteristics .This will give you a fair amount of idea.the one for which the dimesion is showing in red are badly built. After creating and data loadings of the cube you can check the dimensions behaviour in RSRV well.Here also you can see the dimension percentage of the cubes. then modify them accordingly...after 2 or 3 takes I think you should have an idea. Thanks Ajeet

Like (0)

Ram Goswami Nov 18, 2008 10:27 PM (in response to Ram Gosw ami) Re: Dimension issue Thanks for being such a big help...

Like (0)

Share

Tw eet

Like

Site Index Privacy

Contact Us Terms of Use

SAP Help Portal Legal Disclosure

Copyright

Follow SCN