Infocube line item dimension and performance optimization

Hi,
I remodelled an infocube and line item dimension contains only one characteristics set as line item dimension.
previously the dimension as one characteristics but it wasn't set as line item dimension.
and when I checked the SAP_INFOCUBE_DESIGNS from SE38 it looks ok.
/SAP/CUBE /SAP/CUBE3 rows: 8663 ratio: 3 %
After setting it as line item the rows is now minus but it is showing red which means that there is problem with the dimension
/SAP/CUBE /SAP/CUBE3 rows: 1- ratio: 0 %
Its this a performance problem since it is showing red.
thanks

hi,
No,its not performance issue.
for a dimension to be line item dimension...the dimension size shouldn't be more than 20% size of the fact table size.
when a dimension is set as line item dimension,the regarding SID will be placed in Fact Table,but not the DIM ID.
may be that is the reason when your dimension is not line item dimension,it shows the number of rows and when it is made line item dimension,its not showing any rows and the ratio also null.
hope this is clear for you.
Regards
Ramsunder

Similar Messages

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

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.

Line Item Dimension and Navigational attribute

Hi Gurus,
Can somebody tell me how line item Dimensions and navigational attributes works technically?
What are the pros and cons for them?
Regards
Alex

Hi Alex,
You will use navigational attributes based on how you want to track and report history. Let me explain with an example.
Customer Bubba is assigned Sales Group XYZ in Jan 2007. In July the Sales Group on the Customer Master record is changed to ABC. Your are looking at the sales report.
1). If you want to see all the sales made to Customer Bubba at the time of reporting (current) then you will use navigational attributes You will create 0SALESGRP as the navigational attribute of 0CUSTOMER . Then all sales to the customer will show up under Sales Group ABC.
2). If you want to see all the sales made to the customer at the time the actual transaction occured then you will add Sales Group as a characteristic of the InfoCube. Then sales from Jan - June 2007 will show under Sales Group XYZ and from July - Present will show under Sales Group ABC.
Performance issue occurs because navigational attribute is stored outside of the dimension table of the cube and is stored in separate master data tables. So query has to perform additional table read. So essentially there are advantages and disadvantages of usng navigational attributes. It is business requirement that will drive the use of navigational attribute.
Hope this helps!!!. Please assign points.

Differences between High cardinality and line item dimension

Please Search the forum
Friends,
can any one tell me the differences between High Cardinality and Line item Dimension and their use.
Thanks in Advance.
Jose
Edited by: Pravender on May 13, 2010 5:34 PM

please search in SDN

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

Hi friends!
The auditor suggest us "flag the line item option in the dimensions with high cardinality, ie: document number, material number"
In my cubes have 0customer in dimension C toghether with other other characteristics, and 0material in dimension M together to other characteristics..
a) is the auditor suggest ok?
b) do I need mark this dimension as 'line item' in my cubes if the dimension M or C has more than one char?
c) do I need change the arquitecture in my cube and leave 0material alone in dimension M and in dim C only the char 0customer?
Thanks in advance!

Regarding High Cardinality :
If the values in the table are distinct - where the uniqueness of the values is high - a Bitmap index is preferred since the unique values are high...
As for Line item dimension - in a Line Item dimension - only one characteristic is allowed in a line item dimension and the SIDs will get stored directly in the Fact Table and the additional lookup of SIDs with the master data is avoided...
a) is the auditor suggest ok?
I would say that high cardinality is a better option as opposed to line item dimension . For Document Number - a Line item Dimension is preferred since Document number is typically used in reporting but not much on searches for the same ..
Also this is with the information you have given - it could also be that there is some more information to it that Line Item Dimensions were suggested ...
b) do I need mark this dimension as 'line item' in my cubes if the dimension M or C has more than one char?
You can mark a dimension as Line Item only if there is one characteristic
c) do I need change the arquitecture in my cube and leave 0material alone in dimension M and in dim C only the char 0customer?
Keep document number in line item - run the report to analyze the sizes of fact versus dimensions and then rearrange the characteristics to get better ratios instead of making Material and Customer as Line item Dimensions...
Also Material and Customer are usually viewed along with their Nav Attribtes - making them as Line Item will not give you much savings in terms of performance
Edited by: Arun Varadarajan on Mar 25, 2010 1:13 AM

Usage of line item dimension - design or run time?

Hi,
Can anyone please tell me at which stage a line item dimension is considered - at design time or after data load, once queries are run and performance degenerates?
I have read many posts and blogs about line item dimension and high cardinality, but I would require more information on when a line item dimension comes into play.
If we can decide at design time, then how is it done without data being loaded?
At which instances will the dimension table size exceed the fact table's size?
Please explain the above 2 points with a clear example, including the DIM ID and SID table access, and the ratio calculation for line item dimension consideration.
Thanks in advance.

Hello Aparajitha,
I agree with Suhas on point of consideration of LID . It would be good enough to consider a Dimension as LID in the Cube during design, it will be fruitful for the performance point of view. There is no point in saving the LID for future purpose if you have less than 13 Dimension in the Cube. It is going to save a extra join in connecting the relevant data.
If the total Dimension exceeds 13 or more (during design) , then you no option but include the related Char IO together in a one dimension.Here you cannot make a LID .
During the run phase, if the Dim table is more than 20 % of Fact Table, then for the sake of performance you have to go for the LID.In that case you will have the overhead of managing data (backup, delete & restore) .
On your specific questions :
"If we can decide at design time, then how is it done without data being loaded "
Technically same as you do during run-- Goto Dimension -- Right click --Properties -- and Check LID.
Logically -- Depending upon the Business meaning, which char has max unique values you can go with as LID.
"At which instances will the dimension table size exceed the fact table's size "
Frankly I haven't come across that.. ... Fact table is the center table and always will be the huge table in comparison to Dim table . Dim table cannot exceed the Fact Table ....!
Yes if the size of Dim Table is more than 20% of Fact table ( ratio of Dim Table to Fact Table) , then we have to select between the LID or High Cardanility.
Gurus..Please correct if anything is wrong ..!
Regards
YN

Can i change the line item dimension for remodeling ?

Hi everybody,
I want to remodeling a specific dimension of my cube.
But, it is a line item dimension and so, i can't add an other characteristic.
There exist a manipulation to change the option "line item dimension" ?
Thanks for your help !
Rodolphe.

Hi Laloux,
in remodelling u can add a characteristic to the Cube
For InfoCubes, you have the following remodeling options:
For characteristics:
●      Inserting or replacing characteristics with:
○       Constants
○       An attribute of an InfoObject within the same dimension
○       A value of another InfoObject within the same dimension
○       A customer exit (for user-specific code)
●      Delete
For key figures:
●      Inserting:
○       Constants
○       A customer exit (for user-specific code)
●      Replacing key figures with:
○       A customer exit (for user-specific code)
●      Delete
You cannot replace or delete units. This avoids having key figures in the InfoCube without the corresponding unit.
hope it givs u some inforamtion...
Regards,
NR

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

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

Line Item Dimension in a Infocube

Hi,
What is a Line Item Dimension in BI and
How can/based on What factors we can decide declare a Infoobject as a Line Item dimension in Cube
How to measure size of the fact table
Thanks

Hi,
For working out the largest fact tables:
transaction DB02 -> space statistics -> top n largest tables.
If this does not help, your DB administrator should be able to extract the information using SQL.
Also you can use tcode ST14 -> BW Evaluation: performance analysis of BW objects.
Rgds,
Colum

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

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.

Infocube line item dimension and performance optimization

Similar Messages

Maybe you are looking for