Cardinal - Dimensions

What does it mean by cardinality ? What is Cardinal dimensions
line item dimensions ?
How do these effect on the way we model the dimensions?
Thanks

Hi,
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
Bye
Dinesh

Similar Messages

  • Benchmark for High Cardinality

    In the link below SAP uses 20% as a benchmark figure for high cardinality
    http://help.sap.com/saphelp_nw04/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/content.htm
    Whereas in the link below Oracle (we are using 9.0.2.x) uses 1% as a benchmark for high cardinality
    http://www.lc.leidenuniv.nl/awcourse/oracle/server.920/a96524/toc.htm
    Why is there such a stark difference in benchmark values and which is the correct benchmark to consider.
    Thank You for any help offered

    I'm not sure that you are comparing apples to apples.
    SAP is refering to a high cardinality dimension in it's stmt, not a single column that Oracle's doc is talking about. Oracle's doc also mentions that the advantage is greatest when ratio of the number of distinct values vs the nbr of rows is 1%. Remember, both SAP's and Oracle's stmts are general rules of thumb.  
    Let's use Oracle's example:
    - Table with 1 million rows
    - Col A as 10,000 distinct values, or 1%.
    But now, let's talk about a dimension that consists of   two characteristics, Col A, and Col B.
    - Col A has 10,000 distinct values as before (low cardinality as per Oracle)
    - Col B has 100 distinct values (very low cardinality per Oracle)
    Now what happens if for every value of Col A, at least one row exists with every Col B value - the number of rows in your dimension in your dimension table is 10,000 x 100, or 1,000,000 or 100% of the fact table.
    Dimension tables can grow very quickly when you have characteristics that individually have low cardinality, but when combined, result in a dimension that does not.
    Hope this makes sense and clears things up bit.
    Harry -
    You have had several posts related to Cardinality.  I would suggest that rather than closing out each question, and posting another question, just go ahead and post a follow-up question in the original thread (assuming it's related).  I think this creates a more educational thread for other forum members to follow.
    Cheers,
    Pizzaman

  • Queries on Modelling,Extraction

    Hi BW Guys,
                        I have one query on modelling that is
    1) If we have 50 characteristics in a cube,how many dimensions we will create,suppose we created 10 dimensions,how would you arrange the characteristics ?  Would you give any preference in arranging the characteristics?
               The other queries are
                                        1) what are the differences in SD&FI,if u have worked on FI&SD PROJECTS?
                                         2)What would you do if repeat delta also fails?
                                         3)What is so special about LO Extraction?
                                          4)Tell me errors in BW Side not R/3 Side?
    Can u please help me out for this questions.
    Thanks
    Amarnath K

    Regarding Dimensions
    Every additional characteristic or a dimension incorporated into the InfoCube is a burden on the system because of the DIMIDs and the SIDs that are to be created or located for reuse.Hence, it is highly recommended to include in the InfoCube only the characteristics that will really be used in the queries. However, if you would like to incorporate additional characteristics that will potentially be used for future reporting, it would be beneficial to house this data in an ODS.
    In summary,
    o Do not include a characteristic in an InfoCube that will never be used in any query on that InfoCube.
    o Between using a navigational attribute vs. a characteristic, the first option is better for load performance whereas the second option is better for query performance.
    o Minimize the size of the dimension tables
    o Minimize the number of dimensions, but it is more important to minimize dimension sizes
    If more than 13 characteristics are included in the InfoCube, group related characteristics into a dimension to achieve a good balance between the sizes of the dimensions vs. the number of dimensions
    o For high cardinality characteristics use Line Item dimensions
    o For high cardinality dimensions use B-Tree index type
    o If the number of characteristics will always be less than or equal to 13, create one dimension for each characteristic and mark each dimension as a Line Item Dimension.*
    1) what are the differences in SD&FI,if u have worked on FI&SD PROJECTS?
    SD is realred to Sales & distribution whereas FI is related to Finance. sales and distribution you can have info abt sales , billing  whereas FI includes Accounts payable & receivable etc. You can find several threads dedicated for this.
    2)What would you do if repeat delta also fails?
    You should analyse the cause of the failure and work on it. You can delete the request by making it red and pull it again. But first try to solve the failure cause.*
    3)What is so special about LO Extraction?
    Nothing special as such. But you can select how data should be transferred to from source system. The type of delta to be maintained.*
    4)Tell me errors in BW Side not R/3 Si
    In extraction you get errors for SID's not maintained. IDOC stuck in queue etc.
    Regards,
    Sachin Shetty
    Edited by: Sachin Shetty on Nov 7, 2009 6:33 PM

  • Line item dim

    hi,
    could u tell me about line item dim and give me some realtime scenario.
    thanks
    rashmi..

    Hi,
      A typical scenario when you would use line Item dimension would be:
    1. When the number of master data is very high - like for example - customer master running into millions.
    2. When you add this to a dimension - the DIM table size increases dramatically and the cube performance is affected. Since a DIM ID is created for every combination of characteristics possible- where if you put customer master ( 1 mill records ) and the material master ( 50000 records ) you get 1 mill * 50,000 records in DIM Table.
    3. TO avoid this you would separate the customer master into a separate dimension but even then if the size is high you can declare it as a line item dimension which would make the SID part of the fact table and hence improve cube performance. However you can have only one characteristic in a line item dimension.
    4. If you are familiar with the star schema and the extended star schema - a cube with only line item dimension would become a star schema cube.
    Point: If the master table is 20% of the fact table, then its recommended to use line item dimension. It will remove the dimension table and SId table will directly to fact table. During the blue print desing you need to ask the user the amount of data that char is going to be fethced(Approx) and the amount of data the cube is going to be.
    You should decide at what level cube is going to hold the data (summerised or detail). Mostly cusotmer, vendor and material are created as line item dimension.
    when you run stadard program "sap_infocube_designs" it will diplay all the sizes of dimention tables vs fact tables.
    it will display in red those dimentions have exceeded the standard sizes. normally dim tables should have 10 - 20 %      of      the      fact      table.      so based on this criteria you will change the char. as line item dimentions. ex:document      numbers..etc... and you should check high cardinality for the line item dimention tables. if you check high cardinality b-tree indexes will be used instead of bitmap indexes.
    Cardinality: With Line Item Dimension, you can assign ONE Dimension to only one characteristic.
    With Cardinality, you can assign a Dimension containing Multiple Characteristics.
    The scenario totally depends on what is the size of the Dimension Table w.r.t Fact Table. If it is greater than 10% of Fact Table then you need to consider about these.
    Cardinality creates indexes on the Dimension table entries and there by you would see an improvement in performance.
    Point: Some of the options on index type that get created are DB dependent - that is - not available in all the DBs that      BW      runs      on.
    With Oracle DB, setting the Cardinality option causes a b-tree index to be built instead of a bitmap index even if it is not      a      line      item      dim.
    Setting it as a Line Item dim also causes a b-tree index to be built instead of a bitmap index, but also embeds SID directly      in      the      fact      table,      eliminating      the      dimension      table.
    Added mention of embedding SID in fact table for Line Item dimension.
    b-tree indices are more efficient than bitmap in case of high cardinality dimensions.

  • Performance - DIM and FACT tables

    Experts,
    I have performance issues where my DIM tables are bigger than the FACT tables by 50 %.
    Can any one please let me know what should be done in order to solve this issue
    I have already done below steps
    1)Kept the small dimensions together
    2)kept the line item dimensions wherever needed
    3)Grouped related characteristics into one dimension only
    4)Removed high cardinality dimensions
    pls help
    thanks in advance

    Often, not much thought is given to the dissemination of characteristics to dimensions. Dimension tables, however, have a huge impact on InfoCube performance. The star schema design works best when the database can assume minimal records in the dimension tables and larger volumes in the fact table.
    Rationale : -
    Each dimension should be of approximately equal size and that the file size of each dimension should not make up more than 10 percent of the associated fact table. The dimensions must also support growth.
    You should make every attempt to split up the most dynamic characteristics so they do not exist in the same dimension. This ensures that the system does not create too many entries in a dimension table.
    Example : Order data is loaded into BW with the dynamic characteristics customer and material. If these InfoObjects were to be placed together in the same dimension, it poses a problem for the system because a new dimension record would be created each time the combination of customer or material changed. This would make the dimension very large in relation to the fact table.
    When one dimension grows very large in relation to the fact table, it makes it difficult for the database optimizer to choose an efficient path to the data, because the guideline of each dimension having less than 10 percent of the fact table’s records has been violated. This condition of having a large volume of data growth in a dimension is known as “degenerative dimension.”
    In the data modeling phase, it is very important to determine if a dimension table will be degenerated, and then explicitly set it as a line item dimension
    The best way to fix a degenerative dimension is to move the offending characteristics to different dimensions
    Line-item dimensions arise in nearly every case where the granularity of the fact table represents an actual working document like an order number, invoice number, sequence number.. This can only be accomplished if no data is in the InfoCube. If data is present, however, a dump and reload is required. This underscores the point that the data modeling decisions need to be well thought out during the initial implementation to avoid a dump and reload of data.
    Because it is far better to have many smaller dimensions than a few large dimensions, I suggest you identify the most dynamic characteristics and place them in separate dimensions. The current size of your dimensions can be monitored in relation to the fact table by running report SAP_INFOCUBE_DESIGNS in transaction SE38 for live InfoCubes
    This shows the size of the fact table and its associated dimension tables. It also shows the ratio percentage of fact to dimension size.
    Recommendation: -
    Try to limit the number of records in the dimension tables. Use the following guidelines:
    1. If an InfoObject has almost as many distinct values as there are entries in the fact tables, the dimension this InfoObject belongs to should be defined as a line item dimension. If the dimension is defined in this manner, the system will write the data directly to the fact table instead of creating a dimension table that has almost as many entries as the fact table.
    On the other hand, if there are several dimension tables with very few entries (for example, less than 10), these smaller dimensions should be combined into one dimension.
    2. Group related characteristics into one dimension only. Unrelated characteristics can use too much disk space and cause performance problems (for example, 10,000 customers and 10,000 materials may result in 100,000,000 records).
    3. Avoid characteristics with a high granularity, that is, many distinct entries compared with the number of entries in the fact table.
    4. Remove all "High-Cardinality" indicators from the InfoCube definition,generally, a dimension has a high cardinality if the number of dimension entries is 20% (or more) of the number of fact table entries. When in doubt, do not set a dimension with high cardinality
    5.Because it is far better to have many smaller dimensions than a few large dimensions, I suggest you identify the most dynamic characteristics and place them in separate dimensions. The current size of your dimensions can be monitored in relation to the fact table by running report SAP_INFOCUBE_DESIGNS in transaction SE38 for live InfoCubes This shows the size of the fact table and its associated dimension tables. It also shows the ratio percentage of fact to dimension size.
    Hope it Helps
    Chetan
    @CP..

  • Data warehouse mgt

    Hi Gurus
    Would you pl clear my following doubts?
    1.What is the difference between start routine ,transfer routine and update routine?
    2.what is alpha conversion? and when it is used?
    3.when and why do we do partitioning ?In which stage of project shall we do it?
    4.Whats Global transfer rules? where do we use it?
    5.What is the use of the folloing options available in update rule?
    1)Initial value
    2)Look up for master data attribute
    6.What is ALE and where it is used?
    7.What is high cardinality dimension and when it is used ?what are the implications?
    8.what is cache?
    9.What is aggregate realignment and when it is used?
    10.simple meaning of Inexing and buffering.
    11.What is SQL traces and how it is related to BW?
    Thanks in advance

    Hi,
    <i>1.What is the difference between start routine ,transfer routine and update routine?</i>
    http://help.sap.com/saphelp_nw04/helpdata/en/b3/0ef3e8396111d5b2e80050da4c74dc/content.htm
    http://help.sap.com/saphelp_nw04/helpdata/en/b9/2d9778476b11d4b2b40050da4c74dc/content.htm
    <i>2.what is alpha conversion? and when it is used?</i>
    http://help.sap.com/saphelp_nw04/helpdata/en/9b/f9c18f5a07f0459127e9676ae22a54/content.htm
    <i>3.when and why do we do partitioning ?In which stage of project shall we do it?</i>
    http://help.sap.com/saphelp_bw33/helpdata/en/33/dc2038aa3bcd23e10000009b38f8cf/content.htm
    <i>4.Whats Global transfer rules? where do we use it?</i>
    http://help.sap.com/saphelp_nw04/helpdata/en/b7/f470375fbf307ee10000009b38f8cf/content.htm
    http://help.sap.com/saphelp_nw04/helpdata/en/80/1a62bfe07211d2acb80000e829fbfe/content.htm
    thanks

  • Star Schema - How to improve the ratio DIM to FACT table

    If any one want to repply here
    Experts,
    I have performance issues where my DIM tables are bigger than the FACT tables by 50 %.
    Can any one please let me know what should be done in order to solve this issue
    I have already done below steps
    1)Kept the small dimensions together
    2)kept the line item dimensions wherever needed
    3)Grouped related characteristics into one dimension only
    4)Removed high cardinality dimensions
    pls help
    thanks in advance
    thanks

    Guidelines how to limit the number of records in dimension tables
    1. If an InfoObject has almost as many distinct values as there are entries in the fact table, define the
    dimension of the InfoObject as a line item dimension. If defined in this manner, the system will write
    the data directly to the fact table (a field with the data element RSSID, which immediately shows the
    SID table of the InfoObject, is written in the fact table) instead of creating a dimension table that has
    almost as many entries as the fact table.
    2. Only group related characteristics into one dimension. Unrelated characteristics can use too much
    disk space and cause performance problems (for example, 10,000 customers and 10,000 materials
    may result in 100,000,000 records).
    3. Avoid characteristics with a high granularity, that is, many distinct entries compared with the number of entries in the fact table.
    4. If you cannot avoid characteristics with a high granularity and most of your queries do not use these
    characteristics, create an aggregate that stores summarized information. Do not use characteristics
    with a high granularity in this aggregate.
    Please note that the LineItem flag can have negative performance impact on F4 help usage (for which
    the setting 'Only Values in InfoProvider' is used (transaction RSD1 &#56256;-> Tab 'Business Explorer')).
    5. It is also worthwhile to try the checks in transaction RSRV. Use for example RSRV -> All
    Elementary Tests -> Transaction Data -> Entries Not Used in the Dimension of an InfoCube.

  • Design of a cube

    Dear experts,
    Many experts might have worked in desigining the cubes, will any expert share there experience how to convert the nornmization in denormised table, while designg the cube, what precaution u take while desinging the cube
    Regards
    Radha

    Hi ,
    Basic considerations....
    Keep the small dimensions together
    Keep line item dimensions wherever needed
    Group related characteristics into one dimension only
    Remove high cardinality dimensions
    Using aggregates and compression.
    Refer these threads.....
    Tips for Cube Modeling
    Designing cube
    InfoCube Design
    /thread/785462 [original link is broken]
    CUBE DESIGN
    tarak

  • Flat aggregates

    Hi,
    What is the concept of flat aggregates and its relationship with line item/high cardinality dimensions...

    hi
    If you create an Aggregate with more than 16 characteristics, then we call that aggregate as FLAT Aggregate
    When an aggregate is active then new data is not available for reporting,These aggregates are called Flat Aggregates.
    If an aggregate has less than 15 components, BW 3.x puts each component automatically into a separate dimension that will be marked as “line item” (except package and unit dimension); these aggregates are called flat aggregates.
    Note : Flat aggregates can be rolled up on DB Server (without loading data into Application Server).
    simply said flat aggregate is when each characteristic is put into separate dimension, these dimensions are marked as 'line item' dimension, in other word every dimension has only one characteristic (except the package and unit dimension).
    check these links
    aggregate
    aggregate
    line item and high cardinality
    http://help.sap.com/saphelp_nw04/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm

  • Regarding the cube

    hi,
          any one can help regarding i want to know the details of  cubes and ods  which are having the dimensions, character,key fig,lineitem dimension,queries,in how many multiproviders it is using , no of navigational attributes, non cumulative key fig,records it is stored, no of aggregates, no of high cardinality dimensions.
    to know above things is there any table or tools  instead of doing manually.
    thanks in advance
    regards
    praveen

    hi,
    Goto RSA1-> Business content .
    or
    Transport connection.
    Regards,
    Senthil Kumar.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.
    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:
    &#61601;        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. 
    &#61601;        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.

  • Cardinality property of dimension

    Hi,gurus here.
    Dimension "Order info" includes Sales document and Sales document Item.
    Sould I use High Cardinality Property?
    Thanks, for a lot.

    Hi Nice Day:)
    I think you don't need it.Because high cardinality property is used to increase performence whenever the size of dimension table is more then %20(more or less)of the fact table.However, as far as I understand, your Sales document and Sales document Item characteristics do not have mxn relationship.They have nx1 relationship.That means one sales document may have n sales document item but one sales document item is not alllowed to have more than one sales document(correct me if I am wrong and use this property otherwise).Then your dimension table will not be very big so no need to use this property .Check these out:
    Use of Line item dimension & High cardinality
    http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/005f3197-d3da-2e10-1a94-a5c62342f2aa?QuickLink=index&overridelayout=true
    In fact, you can see the size of the dimension table(size of the dimension) so that you can decide easier about using high cardinality or not. Check this out:
    To find the size of the fact table and dimension table
    Regards,
    Sunny
    Edited by: sunnybt on Dec 2, 2011 9:26 AM

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

Maybe you are looking for