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

Similar Messages

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

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.

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

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.

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

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

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

How can i decide candidates for line item dimension?

1Q): we have many infocubes out of all these infocubes, i have to decide which infocubes are the candidates for lineitem dimension? How to do it? Please tell me the technical specs how to do the analysis to find out the candidates for line item dimension?
2Q): if i have the small dimension can i combine all these dimension in to one dimension? what is the benefit of doing this? how to find out which dimensions are small?
Pizzaman i like to hear from you on this topic. Thanks to SDN Community. i appreciate your help. Again Thank you.

The process of figuring out what you might want to create as a line item dimension can vary a bit, it can depend a lot on your exisitng level of domain expertise (how well do you know the data in question). If you are familiar with the data, I would recommend you just take an initial guess at what you believe could be line item dimensions. If you are not familiar witht the data, you might want to examine the source more to understand the cardinality of different characteristics and identify any relationships between characteristics.
I really encourage people to just go ahead and model it and load some data and review, rather than agonizing over developing the theoretically perfect model on paper before they start. You learn a lot more that way.
Any of the SAP rules of thumb, are just that, general rules, not a pronouncement from God. There are always extenuating or unique circumstances that might warrant disregarding the rule, e.g. if the InfoCube will never become very large, maybe some of the concerns just are not worth your effort.
With every release of the Oracle (and the other DBs too)Oracle keeps getting better at data warehousing and star schemas. Oracle 10i is supposed to have made handling bitmap indices much more efficient, which is on of the factors influencing the decision to create a line item dimension.
There are other threads on SDN on line item dims that provide more technical detail and can help answer you first question
As far as 2Q - generally, it's better to have several small dimensions than one larger dimension. But having said that, combining a few very small dimensions into another slightly larger (but still small) dimension is a good idea. It keeps the number of table joins down which will improve query performance. You would do this with characterisitcs that have very few values, e.g. yes/no indicators.
e.g.
You have 8 characteristics that all of which have only two values. You put them in one dimension, and the max size of the dimension table is still only 2x2x2x2x2x2x2x2 or 256 rows. If you had these characteristics in other much larger dimensions, it's not hard to see it causing those dimensions to double, perhaps creating hundreds of thousands of dimension table rows to be created.
For more - read <a href="http://www.kimballgroup.com/html/designtipsPDF/DesignTips2003/KimballDT48DeClutter.pdf">Ralph Kimball Design Tip 48 - Junk Dimensions</a>

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

Removing line item dimention from info cube

Hi All Experts,
Early watch report has suggested us to remove line item dimention and high cardinality from some cubes.
bur our cubes are having data , and when I tried to chekc this in our Dev server, Line Item dimention is disabled when it is filled with data.
but when I delete data from Cube, Line item diemention check box gets enabled.
so does it mean that we can not flag or remove line item dimention form cube if contains data,
and in mine case I have to delete all data from cube and then trensport it to PRD after deleting data from Cube and reload after transport.
Am I correct.
Please advice If I am wrong.

Hi,
yes, you are correct. You have to delete the content of the cube before you can change a line item dim. to a 'normal' dimension. As a workaround you might use a copy of the cube, create and/or copy all update rules to the new cube, and create a new update rule from the old to the new cube. Transport everything to prod, then load you new cube from the old cube and do all the other load as before. Move/copy your queries from the old cube to the new cube as well.
regards
Siggi

Proft center field pick up in recon a/c but not in cust/vendor line item

Dear All
My client want in fbl5n & fbl1n line item should display profit center, How can it be shown&
and how recon a/c automatically pick profit center?
Thanks in advance
vishvas bhavsar
Edited by: vishvas bhavsar on Apr 2, 2008 11:44 AM

Please note it is a myth that in standard SAP you can add a Profit Center to a recon account.
The only way you can do this is now via document splitting in the new GL.
All the talk of changing field status, validations, posting key status is rubbish.
The reason being is that you could have many profit centers in your AR document, and there is only one field.
Document splitting splits the AR line to allow many lines so you can have a single value per PC.

Prob. with addiational line items when clearing Cust/Vendor

Hi Experts,
I've a serious issue with Account Clearing (F-32, F-44, F-03). SAP generates unwanted additional line items when clearing customer/Vendor or GL accounts. I've studied almost all the relevant SAP notes but couldn't found the solution of this issue.......
Company Code:               Single          1000
Segments:               Two               1000, 2000
Document Splitting:                         Active
Splitting Method:                         0000000012
Level of Detail;                              Inheritance
Zero Balance Clearing Account;                    Defined
Document Splitting Characteristic:                      Profit Center and Segment, both are defined as required characteristics and balance to zero in document splitting.
Issue:
1.     T-Code F-32 Creates additional unwanted clearing line items in Customer Subledger/Account
2.     T-Code F-44 Creates additional unwanted clearing line items in Vendor Subledger/Account.
3.     T-Code F-03 G/L Account Clearing also creates unwanted additional clearing line items in GL account.
An immediate help in the above mentioned problem will be highly appreciated.
Regards,

Please check the following Scenario.....
1. Enter a customer invoice of USD 1000 from FB70.
2. Enter a Credit memo of the same customer of USD 1000 from FB70
In both documents all the information should be same.
If you look at the customer account in FBL5N, it'll balance to zero, with two open items i.e an invoice and a credit memo of same amount.
3. Now clear that customer from F-32.
The clearing document contains two line items.
1. Customer Dr. with PK 07 Amount USD 1000
2. Same customer account is credit with PK 17 Amount USD 1000
the above two line items are undesired.
When we analyze the transactions of this customer by FD10N, it shows Dr. during the period USD 2000 and Cr. during the period USD 2000.   Although the actual Dr. amount of Invoice was USD 1000 and Credit amount of Credit memo was USD 1000.
Due to Account clearing F-32, the system shows high turnover of transactions in the customer account. Same thing happens with Vendor and GL clearing.........................
I hope i am able to clear the problem, please feel free to ask me, if any further details required.
Regards,

FDM_COLL01 (Cust Acct-Receivables) Open Bal FBL5N (Cust Line Item)

I have a customer with open balance from FDM_COLL01 (Customer Acct - Process Receivables) 13,533.33. But FBL5N (Customer Line Item Display) has open item of 81,200. The AR data is sent to FSCM daily on batch jobs. What factors can contribute to the difference?
Thanks in advance.
Stephen

I would check the line items.
There will be missing line items, I would check them.
Have you got any noted items, special GL items, items that were cleared in the future?
Also have you activated Head Office display as per Enhancement Package 4 - that could be a reason as well.

Line Item Dim, [Cust ID]

Similar Messages

Maybe you are looking for