Dimension - Line Item

Hi Everybody,
when does make sense to define a Dimension as a Line Item? what are the pros and cons?
Thanks
FedeX

Hi FedeX
When we should create a dimenstion as line item -
Line Item Dimension is created when size of the Dimension is 20% of the fact table.
Advantages :-
1. 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.
2.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
Disadvantages:-
1.A dimension marked as a line item cannot subsequently include additional characteristics. This is only possible with normal dimensions.
For more information please read http://help.sap.com/saphelp_erp2004/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/content.htm
Hope this helps
Regards
Pradip
Don't forget points)

Similar Messages

  • Dimension, Line item dimension

    Hi Friends,
    What exactly the line item dimension? when it is used? can we assign more than one char to a dimension? if so what would be the result? in what situations we do like this? please help me
    regards....

    Line item dimension refers to single field. This is nothing but the SID of the field get stored in the fact table , and there will no extra dimension , hence improves performance while reporting as select need not go thru extra dimension table..
    Line item dimension is used for those fields where the number of records is expected to be more..
    You cant assign more than one characteristic to line item dimension.. But you can assign more than in normal dimension..
    Hope this helps.
    Regards
    Manga(Assign points)

  • 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

  • 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 Data?

    Hi experts,
                   What is Line Item Data? Can somebody give me an example to understand better the use of Line item data from the reporting prospective?
    thanks in advance
    regards,
    dubbu

    Hi
    I think ur question releted to LINE ITEM DIMENSION
    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.

  • 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

  • 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

  • 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 thankz

    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 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?
    thanks

    Thanks 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.

  • DB Statistics on Line item dimension

    Hello,
       We have a new cube with WBS element as line item dimension.  the cube has around 600,000 records in fact table.  The problem is the DB statistics is stuck at sampling the master data table for WBS element. 
    In all our cubes WBS element is always a line item and we do stats for these cubes every week, so why is this taking long.  I thought that stats is per table and not per infocube? Correct me if I am wrong.
    I would also like to if performing stats from the backend like DB13 jobs or DB20 or ORACLE DB is better and sufficient or the Cube Stats is also needed.
    Thanks

    Just saw this - in 3.1 SP22 - OSS Note <a href="https://websmp201.sap-ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=012003146900000348972005">862176</a> indicates that statistics collection on all dependent tables for a cube from the performance tab or as a result of automation settings should <b>NOT</b> be ocurring - just collection on F fact and dimension tables.
    This note provides a fix.  This should speed up statistics collection if you use these methods.

  • 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

  • Line item dimension issue

    Hi,
          I am on development system and want to know the fact and dimension % as I need to create line item dimesion.
    One solution is executing program SAP_INFOCUBE_DESIGN.
          But if I want to use this same program in Production system, it will take a lot of time and will engage resources......
          Kindly suggest me as to how to find out which dimension should be made a line item dimension?
    Thanks,
    Sonu

    Hi,
    Use RSRV.
    Execute RSTRV and here you have the option of single cubes.
    This takes the ourput from the same tables where the SAP_INFOCUBE_DESIGNS takes.
    All Elementary Tests -> Database -> Database Information about InfoProvider Tables.
    Give your infocube name here and execute.
    It gives you a good detailed output.
    Thanks
    Ajeet

  • How to know what were line item dimensions

    Dear SDN,
    How to know what were made line item dimensions.
    Thankyou.

    Rahul,
    Go to the edit mode of your info cube and then check out your dimensions, there if the line item dimension check box is checked then it means that, that particular dimension is a Line item dimension.
    Regards,
    Gattu

  • What indexes are created when we check dimension as line item.

    What indexes are created when we check dimension as line item.
    and also What indexes are created when we check dimension as high cardinality.
    Where can i see that information in the system.
    Answers are highly appreciated.
    Regards
    Kunal

    Hi,
    Line item means it does not have any dimension table.
    High Cardinality means that the dimension is to have a large number of instances (that is, a high cardinality). Also, it is very important to indentify the line item dimension properly. E.g. Sales Order number, this will have the exact number of entries as the fact table entries. Hence, this can be created as a line item dimension. If you are not sure of high cardinality never select that. Activate this function when the dimension has is at least 10%- 20% the size of the fact table (in terms of the number of records). <b>In this case, B tree indices are created instead of bitmap indices.</b>. By default it is BITMAP but with high cardinality it is B-Tree indexing.
    Hope this helps.
    PB

  • 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

Maybe you are looking for