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.
Similar Messages
-
Re-Filling Dimension table, after removing line-item property
Hi Friends,
We need to remove line item property of a line item dimension of an infocube. I made that change and activated the cube. But when i check the dimension table of this dimension, i see no records regarding this.
This cube has 60 mil. records, so we can not delete the content and reload it.
Do you guys know anyway to fill that dimension table with the existent data in the cube ?
Thanks & Regards
S.P.Hi Suresh,
I didn't delete the content of the cube but was able to remove checkmark of line-item dimension. Cube was activated successfuly. But the problem is that there in no data in this newly created dimension table..
Regards
S.P. -
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.
VenkatHi 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 -
I can successfully add products to my shopping cart. The problem is that I cannot remove them. My app consists of 2 beans and 2 jsp pages. One bean is just a setter/getter for a product (not show). The shopping cart bean is here:
package shoppingcart;
import java.util.ArrayList;
import java.util.Iterator;
import javax.servlet.*;
import javax.servlet.http.*;
public class CartBean extends HttpServlet {
private ArrayList items = new ArrayList();
public void addItem(OrderItem o) {
items.add(o);
public void removeItem(OrderItem o) {
items.remove(o);
public Iterator getContents() {
System.out.println(items.size());
return items.iterator();
}The product page (not shown) just sends a value for 'product' over to the shopping cart. With the code here, I get a variable o unknown.
<%@ page import="shoppingcart.OrderItem" %>
<%@ page import="shoppingcart.CartBean" %>
<jsp:useBean id="cart" class="shoppingcart.CartBean" scope="session"/>
<%
String action= request.getParameter("Action");
%>
<%
if (action.equals("addtocart")) {
String product = (String)request.getParameter("product");
System.out.println(product);
OrderItem o = new OrderItem();
o.setProduct(product);
cart.addItem(o);
if (action.equals("Remove"))
cart.removeItem(o);
%>
<%
Iterator contents = cart.getContents();
if (!contents.hasNext()) {
out.println("<tr><td height=50><center>" + "You have no items to checkout" + "</center></td></tr>" );
else {
while (contents.hasNext()) {
OrderItem o = (OrderItem)contents.next();
%>
<tr class="text">
<td class="text"><%=o.getProduct() %> </td>
<td align="center"><input name="Action" type="submit" value="Remove"></td>
...Any suggestions on how I can remove an line item at a time?? Thanks!If you upgrade a capex planning application through the upgrade wizard then the "Line Item" dimension will remain the same name, if you create a new application then it will use the new options.
Cheers
John
http://john-goodwin.blogspot.com/ -
hi..
wat is line item dimensions nd cardinal heights???
regards
deepaHi 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 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 ChintuHi,
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. -
Hii All,
Can you plz explain what is Line Item Dimensions...with examples.I am confused.
Plz help.
Thanks & Regards,
Madhavi S BichakalHi
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. -
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 -
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 -
Delete Unused LINE ITEM DIMENSION Entries
Hi,
I'm using RSDRD_DIM_REMOVE_UNUSED to remove unused items in the dimesions of a cube. However several of these dimensions are line item dimensions. RSDRD_DIM_REMOVE_UNUSED skips these diemensions. My questions are. Does someone know why? Secondly is there a way to control the size of this dimension?
Thx RolfHi,
A line item dimension does not exist in the database. So the report can not delete the unused entries as there are none.
Explanations :when you have a single characteristic in a dimension of a cube, this is not worth to generate the Dimension IDs. This would be a copy of the indexes of the master data called SIDs.
By ticking the box Line Item Dimension, you precise that the indexes for the fact table will not be those generated in the dimension, but those from the master data. This is the reason why we do have indexes for master data.
To control the size of your dimensions, there is this report : SAP_INFOCUBE_DESIGNS
Regards -
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. -
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 -
Loaded Cube Modification in BI 7.0 (Line item Dimension)
Hi
We need to modify the cube 0CA_C11, as in one of the dimension it conatian huge data , we planed to make that line item dimension , by creating new dimension and move some Object to the new dimension.
in BI 7.0 is there any option that we can can create a new dimension with out deleting the data.
We tried in Remodling in that there is no option of creating new dimension
kindly suggest me
many many thankzHi
We need to modify the cube 0CA_C11, as in one of the dimension it conatian huge data , we planed to make that line item dimension , by creating new dimension and move some Object to the new dimension.
in BI 7.0 is there any option that we can can create a new dimension with out deleting the data.
We tried in Remodling in that there is no option of creating new dimension
kindly suggest me
many many thankz -
Line item dimension wont insert sid values in infoobject sid table
Hi all,
I have a strange problem, whenever I load data into a cube which has a line item dimension on 0customer without first loading the master data I am getting inconsistency in RSRV saying that no corresponding DIMid exists in sid table.
So there are Dimids in the fact table but the dimension table, which is same as the sid table in the the case of line item dimension, doesnt have them.
Can someone explain me why is this happening? I thought if a characteristic value doesnt exist in the master data but comes in through the transaction data it inserts the same in the sid table.
Is there a different rule for line item dimensions? Can someone point me to some OSS or documentation?
thanksThanks all..
To clear up a few questions:
1. What I mean by <i>"So there are Dimids in the fact table but the dimension table, which is same as the sid table in the the case of line item dimension, doesnt have them"</i> is:
the line item dimension table /bic/D<cubename>9 which is really a view on the sid table for characteristic /bic/s<ch. name> does have all the sid values (or all the dim values) as the fact table.
So fact table has more entries for that dimension than the sid table.
2. Yes we are facing reporting errors where we cannot drill down by that infoobject and LISTCUBE doesnt show us any cube data when that characteristic is chosen for display.
3. I have checked notes where it seems to be a RSRV bug but in our case it doesnt seem to be as observed in the actual table mentioned in #1
Now it is apparent that I am right both from help.sap.com link and what I am observing that for line item dimensions master data HAS TO BE LOADED FIRST for the characteristics used as a line item. -
To remove line items from invoice which have 0 qty.
Dear Friends,
Requirement: To remove line items from invoice which have 0 qty.
For this I wrote the code in RV60AFZZ. It is very well happening, but when last line item comes it is failing.
What I have written is " DELETE XVBRP WHERE FKIMG = '0' ." . This code is deleting all the line items with 0 qty except last line item.
Actually, this exit works line item wise. Once the line item is appended, the code what I have written is working. For the last line item, record is not appended when this exit is triggerred, thats why last record is not deleted.
The include where all line items are getting appended in XVBRP is LV60AB03. I modified this also. Same code I have written here to delete the records once it is appended. But after doing this the problem is - invoice is not getting created.
Please help me in doing this so as to delete this last record also. I tried with other logics also, not able to track the last record.
Please help me to resolve this problem.
Thanks.Hi,
Check user exit RV60AFZC.
RV_INVOICE_DOCUMENT_ADD is the FM which is called to generate number for the invoice after all the line items have been added to vbrp structure. Add a break-point here and check.
All the best.
Regards,
Amit
Maybe you are looking for
-
How do I install software from a disc on to the new Macbook Pro?
I recently purchased the new Macbook Pro Retina Display, which I love. But just went to install my Photoshop CS5 and realised there's no disc option. What do I do?
-
How can i transfer music from my computer to my iphone 5??
i just got an iphone 5 today and i need help mostly with EVERYTHING .HELPPPP!!!!!!!!!
-
Lenovo not working with samsung Lcd TV.need advice...
I am using a Lenovo 3000 N100 series AQ1 768 laptop.Its got no external graphics card.I want to connect it to my Samsung LA32B550 LCD TV via a vga cable. I have all the hardware fixed but there seems to be something missing on the configuring sectio
-
Can I use existing games in new Games Centre
Just updated my 3gs to OS4.1 with no problems, my question is:- Can I use existing games already bought & paid for at the iStore in the new Games Centre? Iv'e tried dragging them in to no avail i'm begining to think in that money making fashion of Ap
-
When I preview a page in a browser it looks different from my design
Hi, I'm having problems with my font and pictures not spacing correctly. They look perfectly in dreamweaver but when I publish or preview that are further apart than they're supposed to be. I need Help!