When we create Line item dimension Like before implementation or productio

Hi BW experts ,
i have doubt Regarding the creation of Line item Dimension
When we creating the lineitem dimension means After Implementation or Before implementation plz Give the Exact answer .
if u give the exact answer i will assign the moer points
Regards
prakash.v
[email protected]

Hi Prakash,
You can create the line dimension before implenmentation and after implementation.. if u know the size of data u can create at initial stage otherwise go RSRV tcode u can know the size and can create the line dimension, otherwise if dimension table is bigger than fact table u can create line dimension.

Similar Messages

InfoCube Design for Variable data - Use of Line Item Dimensions

I have an infoprovider based on billing conditions which we have extended the extractor structure for 2LIS13_VDKON and we now have a requirement to add Customer fields such as Customer Purchase Order Number and Contract Number. These fields are obviously highly variable. I have added to them to the reporting DSO and now need advice on what is the best way to add these types of fields as reportable dimensions to the infocube so as to not impact performance? I currently have 9 dimensions with multiple charachteristics and a time dimension. Should I just create a line item dimension for Purchase Order? Problem is I have 8 other line item dimensions to add which are customer specific reporting fields that we capture on the sales order and wish to report on. I know there is a limit of 16 dimensions and I am also concerned about performance.
Any advice is greatly appreciated
Lee Lewis

Hi,
To make sure that the infocube you have created should not have any performance issue: Please do the following
Go to RSRV > All elementary tests-> Database---> database information about infoprovider tables
Upon clicking on database information about infoprovider tables, on the right hand side, in the parameter enter your infocube name and execute and see the log: ( log will automatically popping up once you are done with execution )
There see the database infomation about infoprovider:
This log wil make you to understand how well you have designed your infocube and make sure that each (f ) table corresponding to each dimension will not exceed 20 % of the infocube size.
You create dimensions of infocubes in a such a way ( whether line item or normal dimension ) so that any of the dimensional F table will not exceed 20 % of the infocube size.
Actually this will give us the information of the size of the data of particular dimension and there by if any particular dimension is exceeding the 20 % of the infocube size, then you need to create line item dimension for the characteristics existing in that dimension .
After creating again, test it and see whether any of the dimension table exceeding 20% infocube size .
Repeat this process until you see all dim F tables less than 20 % of the info cube table size
This will negate any performance issues arise in reporting
Edited by: S Simran on Nov 6, 2009 10:11 AM

What is line item dimension and cardinality in BI 7.0

Can u plz suggest me what is line item dimension and cardinality in BI 7.0..
Thanks in advance.
Venkat

Hi Babu
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.
Note: In SAP BW 3.0, the term line item dimension from SAP BW 2.0 must a) have precisely one characteristic and b) this characteristic must have a high cardinality. Before, the term line item dimension was often only associated with a). Hence the inclusion of this property in the above. Be aware that a line item dimension has a different meaning now than in SAP BW2.0.
SAP recommends that you use ODS objects, where possible, instead of InfoCubes for line items.
Hope this helps.
Plz check these links:
SAP Help:
http://help.sap.com/saphelp_nw04s/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
Thanks & Regards
Reward if helped
Edited by: Noor Ahmed khan on Aug 5, 2008 2:36 PM

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 dimensions and cardinality?

hi all,
how to identify nor use the cardinality relationship as well as the line item dimension?
can anyone explain me about it. since i am trying to create an multi provider which enables to fetch data from 3 ods.
regds
Hari Chintu

Hi,
Below is some useful information on Line item dimension and high cardinality.
These concepts hold good for Cube design only, coming to ODS, these dont help you. As ODS is nothin but a flat structure, we do not have the facility of Star schema. Reporting on ODS can lead to performance issues, it is better to load data from ODS into Cube and then have a multiprovider on them instead of having it on ODS.
Hope this helps.
Regards,
Kalyan
Use
When compared to a fact table, dimensions ideally have a small cardinality. However, there is an exception to this rule. For example, there are InfoCubes in which a characteristic document is used, in which case almost every entry in the fact table is assigned to a different document. This means that the dimension (or the associated dimension table) has almost as many entries as the fact table itself. We refer here to a degenerated dimension. In BW 2.0, this was also known as a line item dimension, in which case the characteristic responsible for the high cardinality was seen as a line item. Generally, relational and multi-dimensional database systems have problems to efficiently process such dimensions. You can use the indicators line item and high cardinality to execute the following optimizations:
       1.      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.
       2.      High cardinality: This means that the dimension is to have a large number of instances (that is, a high cardinality). This information is used to carry out optimizations on a physical level in depending on the database platform. Different index types are used than is normally the case. A general rule is that a dimension has a high cardinality when the number of dimension entries is at least 20% of the fact table entries. If you are unsure, do not select a dimension having high cardinality.
Note: In SAP BW 3.0, the term line item dimension from SAP BW 2.0 must a) have precisely one characteristic and b) this characteristic must have a high cardinality. Before, the term line item dimension was often only associated with a). Hence the inclusion of this property in the above. Be aware that a line item dimension has a different meaning now than in SAP BW2.0.
However, we recommend that you use ODS objects, where possible, instead of InfoCubes for line items. See Creating ODS Objects.
Activities
When creating dimensions in the InfoCube maintenance, flag the relevant dimension as a Line Item/ having High Cardinality.

BW : Line Item Dimension

Hii All,
Can you plz explain what is Line Item Dimensions...with examples.I am confused.
Plz help.
Thanks & Regards,
Madhavi S Bichakal

Hi
Line Item and High Cardinality
Use
When compared to a fact table, dimensions ideally have a small cardinality. However, there is an exception to this rule. For example, there are InfoCubes in which a characteristic document is used, in which case almost every entry in the fact table is assigned to a different document. This means that the dimension (or the associated dimension table) has almost as many entries as the fact table itself. We refer here to a degenerated dimension. In BW 2.0, this was also known as a line item dimension, in which case the characteristic responsible for the high cardinality was seen as a line item. Generally, relational and multi-dimensional database systems have problems to efficiently process such dimensions. You can use the indicators line item and high cardinality to execute the following optimizations:
       1.      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.
       2.      High cardinality: This means that the dimension is to have a large number of instances (that is, a high cardinality). This information is used to carry out optimizations on a physical level in depending on the database platform. Different index types are used than is normally the case. A general rule is that a dimension has a high cardinality when the number of dimension entries is at least 20% of the fact table entries. If you are unsure, do not select a dimension having high cardinality.
Note: In SAP BW 3.0, the term line item dimension from SAP BW 2.0 must a) have precisely one characteristic and b) this characteristic must have a high cardinality. Before, the term line item dimension was often only associated with a). Hence the inclusion of this property in the above. Be aware that a line item dimension has a different meaning now than in SAP BW2.0.

Regarding line item dimension

Hi all,
what are the necessary prerequisities will u take regarding line item dimension.
for eg., for sd cubes we r using sales doc no., i.obj as a line item dimension? why can't the other i.obj?
plz explain me clearly?
Thanks & Regards,
V.Vijay.

HI,
Line Item and High Cardinality
When compared to a fact table, dimensions ideally have a small cardinality. However, there is an exception to this rule. For example, there are InfoCubes in which a characteristic document is used, in which case almost every entry in the fact table is assigned to a different document. This means that the dimension (or the associated dimension table) has almost as many entries as the fact table itself. We refer here to a degenerated dimension. In BW 2.0, this was also known as a line item dimension, in which case the characteristic responsible for the high cardinality was seen as a line item. Generally, relational and multi-dimensional database systems have problems to efficiently process such dimensions. You can use the indicators line item and high cardinality to execute the following optimizations:
Line Item Dimensions
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.
High Cardinality
If your dim table size exceeds the 20% of your fact table then you can say it as high cardinality, for ex: your fact table contains 100 records and your customer dimension contains 25 records means this dim is with high cardinality. you can check with your client for the expected records for those dimensions or for the info objects which you define in one dimension. to know the sizes of the dimension tables and fact tables you can runa a program in SE37 SAP_INFOCUBE_DESIGNS, it displays all your info cubes fact and dimension tables with sizes, if any dimension exceeds the more than 10% to 20% it will be in RED.
It means that the dimension is to have a large number of instances (that is, a high cardinality). This information is used to carry out optimizations on a physical level in depending on the database platform. Different index types are used than is normally the case. A general rule is that a dimension has a high cardinality when the number of dimension entries is at least 20% of the fact table entries. If you are unsure, do not select a dimension having high cardinality.
http://help.sap.com/saphelp_nw04/helpdata/en/b2/fbb859c64611d295dd00a0c929b3c3/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/5c/d14d3c306f090ae10000000a11405a/frameset.htm
Note: In SAP BW 3.0, the term line item dimension from SAP BW 2.0 must a) have precisely one characteristic and b) this characteristic must have a high cardinality. Before, the term line item dimension was often only associated with a). Hence the inclusion of this property in the above. Be aware that a line item dimension has a different meaning now than in SAP BW2.0.
SAP recommends that you use ODS objects, where possible, instead of InfoCubes for line items.
Tarak

13 line item dimension cube into BWA?

I have heard earlier that BWA does not support line item dimensions due to swap of data between blades. not sure this is still an issue.
My cube has 13 line item dimensions. For performane reasons, we created 13 line item dimensions as cube storing 240 million records and user want to analuse all this data.
I want to push this line item cube to BWA for better performance and like to know the impact.
thanks for advance replies.
Thanks

texas_user wrote:
My assumption for BWA has no limitations. That's why we spent so much for BWA right?
Rewording Mark Victor Hansen: "Only in imagination, there's no limitation".
Best cases for BWA performance are documented; unfortunately the only link I have on hand is to BIExpert article [Tips and Techniques for Optimal Query Performance with SAP NetWeaver BI Accelerator|http://www.bw-biexpertonline.com/article.cfm?id=3665].
> It should support all navigation included single record reading to whole set of data.
> I have 300 million of records in cube. We don't know what kind of adhoc analysis user planning to do.
> We put all 14 fields from base cubes in query allowing user to do anything with data to make better decisions.
> My question is making 13 line item dimension in cube and putting 300 millions records in BWA improve performance or not?
> Space or cost is not concern here. Do we able to do it?
> Does Web intelligence query come back? Or die?
So far there is nothing worrisome in your description. 300M recs is not mind-blowing. The areas of watch-out:
1/ There used to be performance implications with line-item dimensions in the past, when number of records in dimension was higher than number of records in fact table. But it was 2-3 years ago...
2/ Once you put something on top of BW, like BO in your case - you need to check where time is spent, because in the past communication between BI tool and BW used to have impact as well. Make sure you have latest patches there.
Cheers,
-Vitaliy

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 dimension,partitioning IN BW7.0

HOW TO MAKE A CHARACTERISTIC AS LINE ITEM DIMENSION.
STEPS FOR CREATING PARTITIONING IN CUBE
Edited by: TSUCHITRA on Jul 28, 2010 12:08 PM
Please search the forum before posting a new thread
Edited by: Pravender on Jul 28, 2010 7:53 PM

Have you tried the help files?
Partitioning here
http://help.sap.com/saphelp_nw04/helpdata/en/33/dc2038aa3bcd23e10000009b38f8cf/frameset.htm
Line item dimension here
http://help.sap.com/saphelp_nw04/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/content.htm
Should these excellent help files not help you - please don;t hesitate in coming back with more specific questions

Re: Line Item Dimension

Hi everyone,
Can anyone please give me a real time scenario to use line item dimension. i mean when to use it and why to use it using a real time example like document number or invoice number.
thank you,
chintan

This topic comes up regularly. Seach the BI forums on "Line Item Dimension" and you'll find several threads that go into detail.
Searching the forums first is a great way to learn about a topic, then come back and post questions where you need more detail, or didn't quite understand something.
Put yourself on the SDN world map (http://sdn.idizaai.be/sdn_world/sdn_world.html) and earn 25 points.
Spread the wor(l)d!
Pizzaman

How to consider an object as Line Item Dimension?

Can I have the formula for Line Item Dimension? I know basic idea like If the LID is more than 20% of the fact table then we consider as LID but how can we say that the object having more than 20% than Fact table?

Hi sanjeev kumar--
I hope thru that program you will get the ratio between different dimesion tables and the facttable.
In doing so if the size of the dimesion table is too high then we have to trace out the offending charecteristic in that dimension and have to assign that char as a line item dimension.
Generally it can be created on single char infoobjects. After creating it directly links to the MD . i mean to say there won't be a dimension for this..
You can check this under the Tcde listschema .
Hope this Helps,
Regards,
Vishwa.

Removing line item dimension

Dear All,
I have encountered a problem after I removed line item dimension flag from the dimension properties and added new characteristics to that dimension.
When I checked the data in the cube, I was surprising to find the old characteristic (that was the only char. in the dimension previously) having irrelevant values.
Now I can understand that there was no dimension table before removing the flag. And the new dimension table leaded to wrong matching between fact table and SID table.
Can you suggest any solution to make the correct matching between the fact table and SID table ?
thanks in advance..
regards,
berna

Try performing the RSRV Tests.
Go to tcode: RSRV and perform the following tests:
All Combined Tests --> Transaction Data --> Foreign Key Relationship Between Dimension(s) and SID Tables for the Associated Characteristics
All Combined Tests --> Transaction Data --> Fact and Dimension Tables of an InfoCube
Cheers,
Neel.

Line item dimension Vs Cordinality height

What is the difference between LI dimension and Cardinality height? Can both be used simultaniously? which is better for which situation?

When compared to a fact table, dimensions ideally have a small cardinality. However, there is an exception to this rule. For example, there are InfoCubes in which a characteristic document is used, in which case almost every entry in the fact table is assigned to a different document. This means that the dimension (or the associated dimension table) has almost as many entries as the fact table itself. We refer here to a degenerated dimension. In BW 2.0, this was also known as a line item dimension, in which case the characteristic responsible for the high cardinality was seen as a line item. Generally, relational and multi-dimensional database systems have problems to efficiently process such dimensions. You can use the indicators line item and high cardinality to execute the following optimizations:
1.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:
a)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.
b)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.
2. High cardinality: This means that the dimension is to have a large number of instances (that is, a high cardinality). This information is used to carry out optimizations on a physical level in depending on the database platform. Different index types are used than is normally the case. A general rule is that a dimension has a high cardinality when the number of dimension entries is at least 20% of the fact table entries. If you are unsure, do not select a dimension having high cardinality.

When we create Line item dimension Like before implementation or productio

Similar Messages

Maybe you are looking for