Can "Line item dimension" have attributes?

Hi,
I understand that, Line item dimension should have only one Characteristic.
Is it allowed to have ATTRIBUTES along with it?
Thanks for your help.
Lakshmi

Hi
the only restriction of a line item dimension is that it only has one characteristic.
Of course this char can have attributes, nav or not nav.
Don't forget that a line item dimension has no dimension table has such, therefore when you'll request this char, the fact table will be systematically read.
Hoping this will help

Similar Messages

  • How many line item dimensions can a fact table have?

    Hi,
    How many line item dimensions can a fact table have? Is it tht Max of 16 dimensions(13+3) .Does the 16 dimensions include line items dimensions as well .
    Pls reply.
    Thanks
    Praveen

    It includes all dimensios, including line item dimensions.
    If you have line item dimension, pl note you cant assign any other characteristic to that dimension.
    Ravi Thothadri

  • 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

  • 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?
    <u>Pizzaman i like to hear from you on this topic</u>. 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 <b>very small dimensions</b> into another  slightly larger (<i>but still small</i>) 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 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.

  • Compound Attributes&Line item Dimensions

    Hi,
    Plesae can anyone expalin me about compound attributes & Line item dimensions
    Thanks,
    Gal

    Please search...there are many threads about this in the BI forums.

  • Can anyone explain me line item dimension

    Hi all
    Can any one explain me line item dimension with real time exeamples.
    thanxs a lot
    hari

    hi hari..
    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..
    In modelling there are strong entities like customer, material which for dimensions. There are a few entities viz. "intersection entities" of the strong entities like "sales order no". Such intersection entities normally for line item dimensions.
    n this example, if u want to have granularity level till the sales order no., you will have a real high no. of records in the sales order no dimension(if it was a regular dimension) as compared to the fact table(the ratio which u mentioned).
    So we will treat this sales order no. as line item dimension.
    Refer to the link below.
    http://help.sap.com/saphelp_nw04/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
    This topic has been discussed on SDN earlier
    Please refer to follwing SDN threads
    Re: line item dimension,
    Re: Line item dimension
    Please go through this link from SAP help for line item dimension
    http://help.sap.com/saphelp_nw04/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/content.htm
    hope it helps...

  • 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

  • Aggregates for master data & Line item Dimension

    Hi i have question
    1     Can we create Aggregate for Master Data?
    2     Can we create Aggregate with Navigational Attributes?
    3     Can we create Aggregate with Line Item Dimension?
    4     How many dimension we can add with how many characteristics in it if we create a new Aggregate

    1 Can we create Aggregate for Master Data? - <b>No</b>
    2 Can we create Aggregate with Navigational Attributes? - <b>No</b>
    3 Can we create Aggregate with Line Item Dimension? - <b>No</b>
    4 How many dimension we can add with how many characteristics in it if we create a new Aggregate - <b>You can create a maximum of 13 dimensions in the cube.You can add as many characteristics for an aggregate,adding many characteristics in the aggregate is as good as having the query fetch data from the Cube instead of the aggregates.</b>
    Aggregates are subsets infocubes derived from the main InfoCube to increase the query performance.You can create as many aggregates you want in an InfoCube.
    For each aggregate,internally dimensions are created based on the selected characteristics.
    Take a look at this link for detail information...
    http://help.sap.com/saphelp_nw04/helpdata/en/7d/eb683cc5e8ca68e10000000a114084/content.htm

  • 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

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

  • 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

  • Using Line Item Dimension

    Hello Guru’s
    We have finished all initial loads to BW and now we are facing problems during the segmentation in CRM, using queries from BW.
    SAP consultants indicated to use “Line Item dimension”.
    Can we do it now? It is possible now to flag “line item” after the initial load?
    We made the aggregation/compression and our problem still the same.
    Thanks a lot!
    Cristina Barbosa

    Dear  Bhanu Gupta,
    I´m CRM consultant and I´m not a BW expert, but I need to finish this project.
    I read about Line item and my quastion is:
    You wrote me we cannot use line item now.
    Can we insert severeal characteristics in normal dimension?
    It will be helpful? In other words, this can increase the performance as line item?
    We can´t delete the data in the cube.
    In one of this cube, we have more than 40 millions facts.
    Is there something else we can to to improve the performance?
    Thanks for your help and patience.
    Cristina

  • 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

Maybe you are looking for

  • [ERROR] could not find source for resource bundle modules.

    We are in the process of upgrading our flex application from SDK3.6 to SDK4.5.0.17899. Flexmojos version used for compilation is 3.9. The flex library project is complied with SDK4.5.0 version but BUILD is not getting SUCESS from maven. The following

  • Apple TV and Dual zone receivers

    I have the lasted ATV and hooked it up to the surround sound. It works great throughout the main room but turn on the dual zone or 2 source I get no sound. Now after research I find that the dual zone only plays analog and not digital. I know i need

  • Where is the summary button to manually sync iTouch?

    How do I customize my sync content?

  • Free hand SQL

    Hi I want to create a report without using the semantic layer. Can I build a request that based on SQL that I write (like in BOs' free hand SQL)? I'll be happy to have the documentation Thanks Moshe

  • IDOC PPCC2PRETEVENT is not working

    Hi Experts, I wanted to use the IDOC "PPCC2PRETEVENT" for posting the confirmation of a process order. I have done all the settings in WE20 and BD64. IDOC is getting generated and the status is 53. But no confirmation is getting updated. Even if ther