Line Item Dimention Vs Hig Cardinality

HI ALL
           I have a problem with a cube and the below are the challenges...
                   1) can we use High cardinality / line item dimension if we already used one of these(High cardinality / line item dimension)?
                   2) while loading 4lakh records in to cube, i tried optimizing the cube by segregating characteristics into different dimension and i am successful in bringing down the percentage levels but all dimension levels are almost near to 30%. I Have only 1 key figure , will it cause any problem....
         please let me know the concept....
Thanks
vijay

Hi Vijay,
High Cardinality Purpose: If data volume stored in a table is very huge, it's difficult to retrieve particular record or sets of records. For fast retrieval purpose system creates Indexes on various columns, by default SAP BW creates 'Bitmap' index on each dimension.
If dimension doesn't contains large number of distinct values 'Bit Map Indexes' are fine, but in case distinct values are high and the dimension table is at least 20% of the size of the fact table, SAP recommends checking the 'High Cardinality' check box to create 'B-Tree' indexes. When compared to Bitmap indexes B-Tree indexes data retrial is fast, this is recommended on Oracle Data base.
Line Item Dimension: By checking this the relational path of Fact Table -> Dim_ID -> SID will be reduced to Fact -> SID, so you must create a dimension which doesn't create more relations between included characteristics in dimension.
So you can check Line Item dimension to make the system aware of not creating the Dim_ID path and you can check the High Cardinality to make the system to generate B-Tree indexes.
Hope this helps.
Regards
-Sunil

Similar Messages

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

Line item dimention

hi experts,
what is line item dimention. when it is used.what is the importence of it in creating cube
puli

Hi Sridhar,
It is very often possible in the data model to assign only one characteristic to a dimension.This will probably occur with specific reporting requirements or if for example you have the document line item in your model.
In these situations a dimension table means only overhead. BI allows you to define this kind of dimension as a line item dimension (Check box dimension definition). In doing this no dimension table will be generated for this dimension. As dimension table will serve the SID table of this characteristic. The key in the fact table will be the SID of the SID Table.
The fact table is created during InfoCube activation. The structure of the fact table in the BI data model is the same as it is in the normal Star schema. The keys of the dimension tables (i.e. the DIM-IDs) or the SIDs of line item dimensions are the foreign keys in the fact table.
If all dependent attributes of a characteristic are navigational or display attributes in the characteristics master data table or nodes of an external hierarchy, then remember you have the option to define this characteristic as a line item dimension.
USE OF LINE ITEM DIMENSION:
As the BI schema does not enforce that you put a parent attribute into the same dimension table as its child attribute, it is often worth thinking about locating parent attributes in their own dimension table (e.g. with 100,000 article and 2,000 article groups why not put the article group in its own dimension table if queries are
often reported at article group level?)
Hope this helps.
Thanks,Ramoji.

Regarding line-item-dimention

hi,
plz clarify my doubt regarding line-item-dimention.
When line-item Dimensions are used without containing the line-item characteristic in the aggregate, which aggregate should be built?
thanks,
Neelima.

Hi Nl .G
Aggregates can be built out of other aggregates to reduce the amount of data to be read and, hence, to improve the roll-up performance Aggregate hierarchy is determined automatically.
In order to use an aggregate in the first place, it must be defined activated and filled. When you activate it, the required tables are created in the database from the aggregate definition. Technically speaking, an aggregate is actually a separate BasicCube with its own fact table and dimension tables. Dimension tables that agree with the InfoCube are used together. Upon creation, every aggregate is given a six-digit number that starts with the figure1.
am sure using basic aggreate will solve this issue..Try and let me know..
any furthur info you can read from the given link..
[Aggregates|https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/cbd2d390-0201-0010-8eab-a8a9269a23c2]
Edited by: Prasanna Kumar Perla on Aug 4, 2008 1:52 PM

Line item dimensions and cardinality?

hi all,
how to identify nor use the cardinality relationship as well as the line item dimension?
can anyone explain me about it. since i am trying to create an multi provider which enables to fetch data from 3 ods.
regds
Hari Chintu

Hi,
Below is some useful information on Line item dimension and high cardinality.
These concepts hold good for Cube design only, coming to ODS, these dont help you. As ODS is nothin but a flat structure, we do not have the facility of Star schema. Reporting on ODS can lead to performance issues, it is better to load data from ODS into Cube and then have a multiprovider on them instead of having it on ODS.
Hope this helps.
Regards,
Kalyan
Use
When compared to a fact table, dimensions ideally have a small cardinality. However, there is an exception to this rule. For example, there are InfoCubes in which a characteristic document is used, in which case almost every entry in the fact table is assigned to a different document. This means that the dimension (or the associated dimension table) has almost as many entries as the fact table itself. We refer here to a degenerated dimension. In BW 2.0, this was also known as a line item dimension, in which case the characteristic responsible for the high cardinality was seen as a line item. Generally, relational and multi-dimensional database systems have problems to efficiently process such dimensions. You can use the indicators line item and high cardinality to execute the following optimizations:
       1.      Line item: This means the dimension contains precisely one characteristic. This means that the system does not create a dimension table. Instead, the SID table of the characteristic takes on the role of dimension table. Removing the dimension table has the following advantages:
        When loading transaction data, no IDs are generated for the entries in the dimension table. This number range operation can compromise performance precisely in the case where a degenerated dimension is involved.
        A table- having a very large cardinality- is removed from the star schema. As a result, the SQL-based queries are simpler. In many cases, the database optimizer can choose better execution plans.
Nevertheless, it also has a disadvantage: A dimension marked as a line item cannot subsequently include additional characteristics. This is only possible with normal dimensions.
       2.      High cardinality: This means that the dimension is to have a large number of instances (that is, a high cardinality). This information is used to carry out optimizations on a physical level in depending on the database platform. Different index types are used than is normally the case. A general rule is that a dimension has a high cardinality when the number of dimension entries is at least 20% of the fact table entries. If you are unsure, do not select a dimension having high cardinality.
Note: In SAP BW 3.0, the term line item dimension from SAP BW 2.0 must a) have precisely one characteristic and b) this characteristic must have a high cardinality. Before, the term line item dimension was often only associated with a). Hence the inclusion of this property in the above. Be aware that a line item dimension has a different meaning now than in SAP BW2.0.
However, we recommend that you use ODS objects, where possible, instead of InfoCubes for line items. See Creating ODS Objects.
Activities
When creating dimensions in the InfoCube maintenance, flag the relevant dimension as a Line Item/ having High Cardinality.

Line item 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.

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

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

Line Item Dimension has been reset / cancelled after upgrade to 7.0

Hello,
we upgraded to Netweaver BI 7.0 SP 17 and now I receive the message that the line item flag in the dimension has been reset / cancelled.
Can I set the line item flag again also in the new BI 7.0 Multicube?
Does anyone know where to set the flag ?
Thanks and regards,
Ilona

Hi llona,
U need to set the flag at the dimention screen of the Multiprovider..
When u enter the Dimention screen there u can find all the dimentions of the Multiprovider, right side to those dimension u can check the Line Item Dimention flag..
Make sure that u will assign only one char to the line item dimension.. then only u can treat a dimension as Line Item..
Thanks
Do these things in D and move it to the further landscapes..
thanks
Assign points if this helps

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 and Cardinality (DB2)

I have 2 issues with a cube.
Issue 1:
I read everywhere in this forum that if Line Item is marked for a dimension that there will be no index/sid table for this dimension. In stead the sid table of the InfoObject would be used.
I have however an example of a cube with a line-item-dimension that HAS an index table. The table has two columns and both columns have exactly the same data. The number of records is the same as for the SID table of the single InfoObject contained in the dimension. The system runs with a DB2 database.
Can someone explain this?
Issue 2:
In my case, the InfoObject has 27.000.000 distinct values (document number). In the cube I have 12.000.000 records, each with its own unique document number (so about 50% of the document numbers occur in my cube). The line-item is ON, but the high cardinality is OFF.
Is there a guesstimate on how much performance I would gain if I would set High Cardinality on?
Does this setting influence to load-performance?

The table that appears for the line-item dimension is normally a view, it is named as a dimension table for whatever reason. Do check (maybe in SE11) whether it is indeed a table, or a view on the master data table.
I do not understand it fully, however if the line-item dimension is 'on', I don't think it should make any difference whether the 'high cardinality' is checked or not.

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

Line Item: After reading all your links and discussions

From the links and the discussions I was referred to in a previous post, please correct me if I am wrong. I understood that with if a characteristic is going to have several values (defined in that case as "has cardinality"), then it is better to make that characteristic a line item.
It has some advantages as a result of the fact that the line item dimension has no dimension table but only SID table.
1--Does this make loading data faster Or, running queries faster?
2--I also read that "line dimension on means that this dimension becomes part of fact table", can you explain this?
3--Some of the experts said you create line item when the characteristics in the dimension is 20 or 30 % that of the fact table. Is this 20 or 30? And, are we comparing all the characteristics in all the dimensions in the Cube or just the one dimension which we want to make the line item?
4--Also, I get the 20 or 30% of the Dimension but what it being compared to in the Fact Table?
5--I didn't get the cardinality stuff well so any hints other than links will help.
6--Finally, won't this easily make the designer run out of the 13 (16-3 reserved) available dimensions?
7--If the Rule of thumb is dimension table size should be smaller than fact table, and line item dimensions makes this possible, isn't it in the same token killing the ratio of 16 dimension to 1 Fact table in a cube?
8--Is this a consideration after data has been loaded into Cubes or during the design phase of the Cube?
9--If this consideration is applicable only when there is data then how can you factor this into your design? How to wait until you are in trouble to fix the problem?
Thanks

HI Caud,
1] Query reading performance will be improved. As it can access only Master data table and Fact table.
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.
2] Line item Diemsion- when ever ur Dimension table contains a single Char then it is better to join ur master data table with the Fact table. So there will be connection with SID.
3]U chooses the line item when ever there is a high cardinality. i.e if ur DIM table is 10%of Fact table then u will go with the Line item Dim.
the percentage is w.r.t the number of records.
4] its total number of records.
5]Cardinality creates indexes on the Dimension table entries and there by you would see an improvement in performance.
With Cardinality, you can assign a Dimension containing Multiple Characteristics
6] It depends based ur business requirement and the type of data that u use.
8] It is before loading into the cube.
9]it is better to design at the initial stage it self.
Refer this link..
http://help.sap.com/saphelp_nw04/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
Regards-
MM
Assign points if it helps.
It is better to assign points to all who ever replies to u. As they spent lot of time on these Threads.
Message was edited by: vishnuC

Creating a Summary Cube from Line Item Cube

Friends,
1. I have a GL Line Item cube that gives me item level information
2. As I needed to create a summary cube I copied line item cube adjusted dimensions (removed Line Item) and activated it.
3. When I loaded the summary cube from Line Item cube I got same number of transactions
What have I missed? I want to summarize the info at GL Account level; or at any other info object level.
I have done this before but it did not work this time. I think I have missed a step.
I will be looking forward to your recommendations!
Thanks for reading this!
Ram

Hi,
Just removing tick against Line item will not work. You have to remove that characteristic from the cube. As this characteristic is High cardinality , you need to remove it from he cube.
Decide at what level you want to have aggregated data and keep only those characteristics in the cube.
Regards
SS

Line Item Dimention Vs Hig Cardinality

Similar Messages

Maybe you are looking for