Line Item dIm use

Hi
LIne item dim of the cube increases the loading performance or the query performance.
Reagards

Hi,
Please refer
/people/juergen.noe/blog/2007/12/07/spot-on-line-item-dimensions
extract from sap-help : http://help.sap.com/saphelp_nw04/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
-Line item: This means the dimension contains precisely one characteristic. This means that the system does not create a dimension table. Instead, the SID table of the characteristic takes on the role of dimension table. Removing the dimension table has the following
Advantages:
-When loading transaction data, no IDs are generated for the entries in the dimension table. This number range operation can compromise performance precisely in the case where a degenerated dimension is involved.
- A table- having a very large cardinality- is removed from the star schema. As a result, the SQL-based queries are simpler. In many cases, the database optimizer can choose better execution plans.
Nevertheless, it also has a disadvantage: A dimension marked as a line item cannot subsequently include additional characteristics. This is only possible with normal dimensions.
Hope this helps
Regards
Raj

Similar Messages

Line item dim

hi,
could u tell me about line item dim and give me some realtime scenario.
thanks
rashmi..

Hi,
A typical scenario when you would use line Item dimension would be:
1. When the number of master data is very high - like for example - customer master running into millions.
2. When you add this to a dimension - the DIM table size increases dramatically and the cube performance is affected. Since a DIM ID is created for every combination of characteristics possible- where if you put customer master ( 1 mill records ) and the material master ( 50000 records ) you get 1 mill * 50,000 records in DIM Table.
3. TO avoid this you would separate the customer master into a separate dimension but even then if the size is high you can declare it as a line item dimension which would make the SID part of the fact table and hence improve cube performance. However you can have only one characteristic in a line item dimension.
4. If you are familiar with the star schema and the extended star schema - a cube with only line item dimension would become a star schema cube.
Point: If the master table is 20% of the fact table, then its recommended to use line item dimension. It will remove the dimension table and SId table will directly to fact table. During the blue print desing you need to ask the user the amount of data that char is going to be fethced(Approx) and the amount of data the cube is going to be.
You should decide at what level cube is going to hold the data (summerised or detail). Mostly cusotmer, vendor and material are created as line item dimension.
when you run stadard program "sap_infocube_designs" it will diplay all the sizes of dimention tables vs fact tables.
it will display in red those dimentions have exceeded the standard sizes. normally dim tables should have 10 - 20 %      of      the      fact      table.      so based on this criteria you will change the char. as line item dimentions. ex:document      numbers..etc... and you should check high cardinality for the line item dimention tables. if you check high cardinality b-tree indexes will be used instead of bitmap indexes.
Cardinality: With Line Item Dimension, you can assign ONE Dimension to only one characteristic.
With Cardinality, you can assign a Dimension containing Multiple Characteristics.
The scenario totally depends on what is the size of the Dimension Table w.r.t Fact Table. If it is greater than 10% of Fact Table then you need to consider about these.
Cardinality creates indexes on the Dimension table entries and there by you would see an improvement in performance.
Point: Some of the options on index type that get created are DB dependent - that is - not available in all the DBs that      BW      runs      on.
With Oracle DB, setting the Cardinality option causes a b-tree index to be built instead of a bitmap index even if it is not      a      line      item      dim.
Setting it as a Line Item dim also causes a b-tree index to be built instead of a bitmap index, but also embeds SID directly      in      the      fact      table,      eliminating      the      dimension      table.
Added mention of embedding SID in fact table for Line Item dimension.
b-tree indices are more efficient than bitmap in case of high cardinality dimensions.

Query runs forever when using selection on line item dim

we have a cube zcube which has po number as a line item dimension .
everymonth users run queries this cube using po number as selection
criterai and using a wild card search on this field . every time
queries have run fine . however , this month when we try to do so
the query runs forever and no results are returned . i also tried
listcubing with similar selection but it also did not return any results .
our production system has lot of data . i tried in test system it worked fine
i checked the cube for compression and indices in production , they look fine
can anyone think of anything that could have gone wrong ? also did rsrv tests ..
but all come green
we have not done any developments on this cube , however we have shifted to
a new hardware in the past month . can anyone think of any reasons ?
anything that can help me catch the issue ? all suggestions welcome

Not sure,
Are you saying that you need both the counts seperately? or a combined count?
how are you joining alpha and beta tables? what is the join condition?
you need to do something like this,
SELECT COUNT(CASE WHEN
                    (A.col1 = 'Pete' AND SUBSTR(A.col2,,1,12)=SUBSTR(B.col2,,1,13))
                 OR ( A.col1 != 'Pete' AND SUBSTR(A.col2,,1,15)=SUBSTR(B.col2,,1,15))
                THEN 1 ELSE 0
             END)
FROM alpha A, beta b
WHERE alpha.join_cloumn= beta.join_columnG.

Issue with sorting of TO line item while using LM05 / LM07

Hi,
We have found an issue in using LM05 / LM07 trnasactionwhile performing picking activity using the RF transaction.
1. Transfer Order is created for the same Material and Batch Combination with multiple line items. So when we display the TO the materials appear in the sequence of TO line item say 1, 2, 3, 4, 5 etc.
2. When we try to confirm the transfer order using LM05 the system is not picking the line items in the order that the TO was created. It is pickinga a random line item from the order and selecting an item from the lower line items of the TO's.
We have debugged and found that there is no specific sort sequence which is changing the sequence of line items as all the sort eliments have the same values except that there are few empty fields. The statement where the sort sequence is changing is 'SORT TMP_SORT_TAB BY NLTYP SORLP NLENR MATNR CHARG' but my concern is it is not sorting by this sequence specified in the code after execution.
If anyone has seen this kind of an issue and has a solution please let me know.
Thanks in Advance,
Harish

As for std SAP ME59N - make sure there is not rounding value is activated in the Material master as well as info record
If this is not the case than check any custom code is activated for ME59N
becuase generally in many compnay when they use ME59n they don't want the same material from diff PR to create the diff line item in the PO so using the custom logic in the user exist they trick the code
it might be the case for you where you have issue.

How to find the open po line item by using EKKO &EKPO tables

Hi Gurus,
what i am doing is finding out the OPEN PO line item from EKPO table. I know it has to check the ELIKZ field from the EKPO table.Can you please clarify me on the same in more detail.I has to use the ELIKZ EREKZ fields from EKPO table.

Use the field ELIKZ in EKPO. If the field is Blank its an OPEN PO Line Item
refer this link.
How to open PO line item

How can we know the size of the dimension(in Line item Dim)?

Hi to all experts,
We use Line item dimension if the size of dimension is 20% or more of the fact table. My doubt is that how can v know that the size of the dimesion is 20% or more of FT?. But we never store MD in dimension tables......So please help me to understand this scenario? Thanks in advance.

Hi
Normally before modelling you will assume the number of entries in your master data and transactional data..
If your dimension is having 3 characteristics
say A,B .....and these characteristic values are say
A---10,000( Total number of master data records)
B----7,000( Total number of master data records)
then your dimenstion would be 10,000 * 7,000 =700000000
in this case you better keep A in a dimension and B in another dimension.
Normally SAP recommends your dimension table shouldnot exceed 100,000...
so whenever you expect a characteristic is having more values then you should make it as line item...
If you want to add a new characteristic to the existing model then you can decide by comparing the ratio of dimension table to the fact table..
Please have a look at the below url for sizes
dimension size
Hope it helps
Thanks,
Teja
Edited by: Teja badugu on Apr 24, 2008 12:19 PM

Delete Line Item Document Using DI W/Out Using Recordset

in my DI Version 6.50.097 , there is no properties in Document_Lines Object that fasilitate us to remove one of line items in document. We can do that by recordset.doquery "delete POR1 where ......
but when we open the document the value (if we update every line item do not reflect the value we wants especially in total in header document.
Any suggestion to do that without using recordet.
Thx
Cheers,

I haven't tried this myself, but I guess you could set up a dummy Item Master called "Cancelled" with a price of zero, and try changing the item code to that.
John.

Re: Line item dim of cube

Hi
I have changed one dim of the cube as Line Itm dms with one char. Moved the remaining char to newly created dim.
I have another cube(cube2) with same scenario.
1)Both are the part of infoprovider.How should go about the dims of the MultiProvider.
2)MultiProvider dims properties doesnot show line item option.
3)How should I go about the query.Do I need to make any changes in the query.
Regards
bipower

HI
One More question
I have a multiprovider..which contains only one cube...in which two dims are made as Line Itm dim.
Now when I try to activate the MultiProvider it gives the error.Most of the dims are as per the cube
in the Multiprovider.
I see that old chars exists in the dimensions which are made as the line Item dm.Can change the
structure of the multiprovider.along with this do i need to make any changes.
When I try to activate the multiprovider it gives the following error
Error messages from point of view of OLAP processor:
Regards
Edited by: Bi power on Jun 15, 2009 8:15 PM
Edited by: Bi power on Jun 15, 2009 10:14 PM

Line Item Dim, [Cust ID]

Is it possible that one might have to use Cust ID as the only Char in Line Item Dimension?

Hi,
Yes, it can be if CUSTID column has the same of rows as the fact table. If CUSTID characteristic has a large number of values, which, in combination with other characteristics, would lead to a large increase in dimension tables for the fact table, then yes, it should be line item dimension.
PB

Changing other line item by using MIGO_BADI-LINE_MODIFY

Hi,
My requirement is that when user change the receiver field ( goitem-wempf) of the first line item in mat doc. I need to copy that value and copy it to all other items as well.
I try using BADI migo_badi-line_modify and export the value of the first item into abap memory, then import it again to other line. But this solution require user to manually click each line item to trigger method line_modify.
Is there a way I can change the data in other line item during method line_modify of the first item line.
Thanks for all the help.

Solution found

Document Splitting Error (GLT0002) while clearing Vendor line items by using F-44

Dear Guru's,
My client is getting below error while clearing the vendor using T code F-44, I checked related links but i could not find the suitable solution for this issue.
Doc No: 35112789 has the problem.. i checked Document splitting related Config but it is fine and
i can see the values in table FAGL_SPLINFO_VAL and not in FAGL_SPLINFO. Please help me to resolve the below issue

Hi,
You are getting this error as the document was posted before Document Splitting Activation or was posted when Document Splitting Active was deactivated.
For the Documents posted before Document Splitting, Migration Cockpit is to be used.
If there are few documents, then U can take a down time (ensure no document is posted in this time, if posted then you will get same error for the posted documents), remove the tick, clear the documents and Activate Document Splitting.
Regards,
Debashri Dutta

The impact to use line item dimension

Hi,guys,
I have a question here:
When modeling a cube,we can use the line item dimesion to improve the reading performance in some cases.for example when we use SD doc. characteristic as a line item dimesion.
But what I wonder is there any limitation or impact when we use this function? What about if I click this function even for a casual characteristic like bussiness area or something? Is that useful to improve performance or impact vice versa?
Hope someone could help me.
Thanks

Hello Johnson,
The Infocube has extended star shema structure, i.e fact table contains Key figures & Dimentions, so characteristics is link with SID (Surrogate ID) to dimention table for faster access the data. These SID is further link with ur Master Data.
In this case dimension tables are eliminated and characteristics infoobjects SID is directly written in the fact table insted of dimension id so it will improve the performance.
SAP recommends that you use ODS objects, where possible, instead of InfoCubes for line items
If you are looking at better query performance and you have less than 13 chars. in ur datamodel, then you can place them individually in each dimension. make the dimensions as line item Dim .
In this case Line item IC is better than ODS.
but if you are having many data fields and you want to report on lowest granularity of data, then ODS is better option.
For Example :
Line item dimension for Order or Order item contains huge data, same as fact table. two huge table joins creates performance issues.
So SAP suggests, ODS reporting is good for Order level reporting then Line item dimensions.
Advantages of Line item :
Line item dimension is used to improve queryperformance.
Instead of joining fact table to dimension reduce joints
Disadvantages of line item :
A dimension marked as a line item cannot subsequently include additional characteristics.
Hope it clears ur doubt,
Regards,
Santosh

Line Item: After reading all your links and discussions

From the links and the discussions I was referred to in a previous post, please correct me if I am wrong. I understood that with if a characteristic is going to have several values (defined in that case as "has cardinality"), then it is better to make that characteristic a line item.
It has some advantages as a result of the fact that the line item dimension has no dimension table but only SID table.
1--Does this make loading data faster Or, running queries faster?
2--I also read that "line dimension on means that this dimension becomes part of fact table", can you explain this?
3--Some of the experts said you create line item when the characteristics in the dimension is 20 or 30 % that of the fact table. Is this 20 or 30? And, are we comparing all the characteristics in all the dimensions in the Cube or just the one dimension which we want to make the line item?
4--Also, I get the 20 or 30% of the Dimension but what it being compared to in the Fact Table?
5--I didn't get the cardinality stuff well so any hints other than links will help.
6--Finally, won't this easily make the designer run out of the 13 (16-3 reserved) available dimensions?
7--If the Rule of thumb is dimension table size should be smaller than fact table, and line item dimensions makes this possible, isn't it in the same token killing the ratio of 16 dimension to 1 Fact table in a cube?
8--Is this a consideration after data has been loaded into Cubes or during the design phase of the Cube?
9--If this consideration is applicable only when there is data then how can you factor this into your design? How to wait until you are in trouble to fix the problem?
Thanks

HI Caud,
1] Query reading performance will be improved. As it can access only Master data table and Fact table.
Setting it as a Line Item dim also causes a b-tree index to be built instead of a bitmap index, but also embeds SID directly in the fact table, eliminating the dimension table.
2] Line item Diemsion- when ever ur Dimension table contains a single Char then it is better to join ur master data table with the Fact table. So there will be connection with SID.
3]U chooses the line item when ever there is a high cardinality. i.e if ur DIM table is 10%of Fact table then u will go with the Line item Dim.
the percentage is w.r.t the number of records.
4] its total number of records.
5]Cardinality creates indexes on the Dimension table entries and there by you would see an improvement in performance.
With Cardinality, you can assign a Dimension containing Multiple Characteristics
6] It depends based ur business requirement and the type of data that u use.
8] It is before loading into the cube.
9]it is better to design at the initial stage it self.
Refer this link..
http://help.sap.com/saphelp_nw04/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
Regards-
MM
Assign points if it helps.
It is better to assign points to all who ever replies to u. As they spent lot of time on these Threads.
Message was edited by: vishnuC

Line item dimensions

hi..
wat is line item dimensions nd cardinal heights???
regards
deepa

Hi Deepa,
Line Item Dimension:
When your dimension table becomes large (>10% of the fact table) then you can make the dimension a "line-item" dimension. The constraint is that the dimension should have only 1 characteristic. By making the dimension as line item the SID values are directly used instead of the Dim ids and the query performance is better.
The disadvantage is that once you make the dimension line -item you cannot add another characteristic to that dimension and you cannot remove the line -item checkmark without deleting the cube data.
http://help.sap.com/saphelp_nw04/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
Multi Dimensional modelling will include fact table in center with Dimension tables around it. Overall system performance is greatly affected and dependent on the size of these dimension tables in respect to the fact table. SAP recommends that size of dimension table should be 20% of the size of fact table. In case if this size is more than 40% dimension should be defined high cardinal ( should be supported by database) If dimension tables are more than 40% the dimension should be defined as line item. When dimension is defined as line item, Dim ID in the fact table is replaced with the SID ID, Only one characteristic will be defined in that dimension. This results in improved performace.
Here is how it will work
Fact table
Dim ID1 DIM ID2 DIM ID3 AMOUNT QTY
Dimension Table 1
Sid1 DimID1
Dimension Table 2
Sid 4 Dim ID 2
Dimension Table 3
Sid6 Dim ID 3
Cosidering that Dim1 is too big, We can define Sid 1 in Line Item Dimension and Dim ID 1 is replaced by Sid 1 so fact table will look like this
Sid 1 Dim2 Dim3 Amount Qty
Compounding Attribute is superior object to define characteristic, for example
Plant A manufactures TV
Plant B manufacture TV
The only way to differentiate product can be TV and Plant A
Also,
Cost center 100 can be in Controlling Area A and
Controlling Area B can also have cost center 200,
So Cost center is compounded with CO Area to uniquely identify that line.
Just check this thread line item dimension
Cardinality defines the numeric relationships between occurrences of the entities on either end of the relationship line.
Check this link:
http://www.datamodel.org/DataModelCardinality.html
For cubes -> High Cardinality means that this dimension contains a large number of characteristic values. This information is used in accordance with the individual database platform in order to optimize performance. For example, an index type other than the standard may be used. Generally a dimension is perceived to have high cardinality when the dimension is at least 20% the size of the fact tables in terms of the number of entries each contain. Avoid marking a dimension as having high cardinality if you are in any doubt.
Also refer the below link for Line Item Dim and High Cardinality.
http://help.sap.com/saphelp_nw04/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
Check this explanation by pizzman:
Re: High cardinality (CARDHeight) vs Line item
Refer these links on line-item and cardinality:
Line Item Dimension
Re: Line Item Dimension
Cardinality
Re: High Cardinality Flag
****Assign Points If Helpful****
Regards,
Ravikanth

Line item...Card H

hi guys,
while creating infocube dimensions...I found some things I didnot understand...
1.Line Item Dim
2.Card H Dim
what are they and where do we use them in real time....
thanks and rgds
Surekha

Hi
Line item: This means the dimension contains precisely one characteristic. This means that the system does not create a dimension table. Instead, the SID table of the characteristic takes on the role of dimension table. Removing the dimension table has the following advantages:
○ When loading transaction data, no IDs are generated for the entries in the dimension table. This number range operation can compromise performance precisely in the case where a degenerated dimension is involved.
this can be created when you are creating dimension in infocube.
select dimension tab in infocube declarationselect creategive 1. description for thatin the same line you find a check box called line itemcheck that-then select assign tabinclude charactertics for that dimension--activate it.
Cardinality High
When you select high cardinality for a dimension (usually when dimension table is >20% the size of the fact table), the system depending on the database, will create a different type of index (btrees instead of bitmap), which enhances selection from these structures by queries.
On your second query, on compression, the requests will be visible in the manage screen, but will not be visible in the cube and data will be compressed/summarised/aggregated). So it will not be possible to delete data from the cube based on request selection.
Please find an link for SAP Help
http://help.sap.com/saphelp_nw04/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
Many thanks
kiran

Line Item dIm use

Similar Messages

Maybe you are looking for