Top 10 lowest level dimension members based on measure

Hi,
I'm trying to create a condition with JDeveloper to show the top 10 dimension members based on a measure for the lowest level of the hierarchy, but doesn't work.
All other conditions are working well, including top 10 dimension members in other levels of the hierarchy (not in the lowest).
Any suggestion??
I think the dimension is defined ok, all other conditions are working well and the lowest level could be shown with other conditions and drills.
Thanks in advanced....

Hi,
First, my BI Beans version is 9.0.3.5 and my database version is 9.2.0.2.1
I will try to clarify my problem. I am trying to create a graph to show the top10 members of a dimension based on my measure. When I define this condition
to show the top 10 members of a middle level (not de low level), it works fine, I mean, it shows the top 10 members of that level. But, when I define the condition
to show the top 10 members of the low level, it displays me that there is no data to display (The data has an insufficient number of columns and rows).
I have been testing this case, and I have seen that if I change the low level column (number type) of the dimension to a varchar type column, it works. This low level is
the primary key of the dimension table, and it's referenced by a foreign key in the fact table.
Which could be the problem?? Is it not possible to define a level of a dimension with a number column??
I have a demo sample to see this problem (two simple dimensionS with three levels and a fact table). It's a bit large to post it complete, so I post here an extract of it.
-- Dimension and fact tables
CREATE TABLE PR_DIM_A (DIM_A_KEY NUMBER,
               LOW_A_LEVEL_NAME VARCHAR2(50),
               ALL_A_LEVEL_ID VARCHAR2(50), ALL_A_LEVEL_NAME VARCHAR2(50),
               GROUP_A_LEVEL_ID VARCHAR2(50), GROUP_A_LEVEL_NAME VARCHAR2(50),
               CONSTRAINT PK_DIM_A PRIMARY KEY (DIM_A_KEY));
CREATE TABLE PR_DIM_B (DIM_B_KEY NUMBER,
               LOW_B_LEVEL_NAME VARCHAR2(50),
               ALL_B_LEVEL_ID VARCHAR2(50), ALL_B_LEVEL_NAME VARCHAR2(50),
               GROUP_B_LEVEL_ID VARCHAR2(50), GROUP_B_LEVEL_NAME VARCHAR2(50),
               CONSTRAINT PK_DIM_B PRIMARY KEY (DIM_B_KEY));
CREATE TABLE PR_FACTS (FACT_KEY NUMBER, DIM_A_KEY NUMBER, DIM_B_KEY NUMBER,
               MEASURE_1 NUMBER, MEASURE_2 NUMBER,
               CONSTRAINT PK_FACTS PRIMARY KEY (FACT_KEY));
ALTER TABLE PR_FACTS ADD CONSTRAINT FK_DIM_A FOREIGN KEY (DIM_A_KEY)
               REFERENCES PR_DIM_A (DIM_A_KEY);
ALTER TABLE PR_FACTS ADD CONSTRAINT FK_DIM_B FOREIGN KEY (DIM_B_KEY)
               REFERENCES PR_DIM_B (DIM_B_KEY);
-- Data inserts in the dimensions
INSERT INTO PR_DIM_A VALUES (1,'ALL','ALL_NAMEa','GROUP1a','GROUP1_NAMEa','LOW1a','LOW_NAME1a');
INSERT INTO PR_DIM_A VALUES (2,'ALL','ALL_NAMEa','GROUP1a','GROUP1_NAMEa','LOW2a','LOW_NAME2a');
-- ......... dimension B is the same kind of data.
-- OLAP dimension A creation script
cwm2_olap_dimension.create_dimension('BI02', 'PR_A_DIM', 'DimA Diaplay name', 'DimA Plural name', 'DimA Short Description','DimA Description');
cwm2_olap_dimension_attribute.create_dimension_attribute('BI02', 'PR_A_DIM', 'Short Description', 'Short Descriptions', 'Short Desc', 'Description', TRUE);
cwm2_olap_hierarchy.create_hierarchy('BI02', 'PR_A_DIM', 'HIER_DIM_A', 'HIER_DIM_A Display name', 'HIER_DIM_A ShortDesc', 'HIER_DIM_A Desc','Unsolved Level-Based');
cwm2_olap_dimension.set_default_display_hierarchy( 'BI02', 'PR_A_DIM', 'HIER_DIM_A' );
cwm2_olap_level.create_level('BI02', 'PR_A_DIM', 'ALL_LEVEL_A', 'ALL_LEVEL_A DisplayName', 'ALL_LEVEL_A PluralName', 'ALL_LEVEL_A ShortDesc', 'ALL_LEVEL_A Desc');
cwm2_olap_level.create_level('BI02', 'PR_A_DIM', 'GROUP_LEVEL_A', 'GROUP_LEVEL_A DisplayName', 'GROUP_LEVEL_A PluralName', 'GROUP_LEVEL_A ShortDesc', 'GROUP_LEVEL_A Desc' );
cwm2_olap_level.create_level('BI02', 'PR_A_DIM', 'LOW_LEVEL_A', 'LOW_LEVEL_A DisplayName', 'LOW_LEVEL_A PluralName', 'LOW_LEVEL_A ShortDesc', 'LOW_LEVEL_A Desc' );
cwm2_olap_level_attribute.create_level_attribute('BI02', 'PR_A_DIM', 'Short Description', 'ALL_LEVEL_A', 'Short Description', 'All_LEVEL_A DisplayName', 'ALL_LEVEL_A ShortDesc', 'ALL_LABEL Desc', TRUE );
cwm2_olap_level_attribute.create_level_attribute('BI02', 'PR_A_DIM', 'Short Description', 'GROUP_LEVEL_A', 'Short Description', 'GROUP_LEVEL_A DisplayName', 'GROUP_LEVEL_A ShortDesc', 'GROUP_LEVEL_A Desc', TRUE );
cwm2_olap_level_attribute.create_level_attribute('BI02', 'PR_A_DIM', 'Short Description', 'LOW_LEVEL_A', 'Short Description', 'LOW_LEVEL_A DisplayName', 'LOW_LEVEL_A ShortDesc', 'LOW_LEVEL_A Desc', TRUE );
cwm2_olap_level.add_level_to_hierarchy('BI02', 'PR_A_DIM', 'HIER_DIM_A', 'LOW_LEVEL_A', 'GROUP_LEVEL_A' );
cwm2_olap_level.add_level_to_hierarchy('BI02', 'PR_A_DIM', 'HIER_DIM_A', 'GROUP_LEVEL_A', 'ALL_LEVEL_A' );
cwm2_olap_level.add_level_to_hierarchy('BI02', 'PR_A_DIM', 'HIER_DIM_A', 'ALL_LEVEL_A' );
cwm2_olap_table_map.map_dimtbl_hierlevel('BI02', 'PR_A_DIM', 'HIER_DIM_A', 'ALL_LEVEL_A', 'BI02', dim_table, 'ALL_A_LEVEL_ID' );
cwm2_olap_table_map.map_dimtbl_hierlevel('BI02', 'PR_A_DIM', 'HIER_DIM_A', 'GROUP_LEVEL_A', 'BI02', dim_table, 'GROUP_A_LEVEL_ID' );
cwm2_olap_table_map.map_dimtbl_hierlevel('BI02', 'PR_A_DIM', 'HIER_DIM_A', 'LOW_LEVEL_A', 'BI02', dim_table, 'DIM_A_KEY' );
cwm2_olap_table_map.map_dimtbl_hierlevelattr('BI02', 'PR_A_DIM', 'Short Description', 'HIER_DIM_A', 'ALL_LEVEL_A', 'Short Description', 'BI02', dim_table, 'ALL_A_LEVEL_NAME' );
cwm2_olap_table_map.map_dimtbl_hierlevelattr('BI02', 'PR_A_DIM', 'Short Description', 'HIER_DIM_A', 'GROUP_LEVEL_A', 'Short Description', 'BI02', dim_table, 'GROUP_A_LEVEL_NAME' );
cwm2_olap_table_map.map_dimtbl_hierlevelattr('BI02', 'PR_A_DIM', 'Short Description', 'HIER_DIM_A', 'LOW_LEVEL_A', 'Short Description', 'BI02', dim_table, 'LOW_A_LEVEL_NAME' );
-- OLAP dimension B creation script is similar than A.
-- OLAP CUBE creation script
cwm2_olap_cube.create_cube( 'BI02', 'PR_CUBE', 'Sample Cube', 'Sample Cube', 'Sample Cube' );
cwm2_olap_measure.create_measure('BI02', 'PR_CUBE', 'MEAS1', 'MES1 DisplayName', 'MES1 ShortDesc', 'MES1 Desc');
cwm2_olap_measure.create_measure('BI02', 'PR_CUBE', 'MEAS2', 'MES2 DisplayName', 'MES2 ShortDesc', 'MES2 Desc');
cwm2_olap_cube.add_dimension_to_cube( 'BI02', 'PR_CUBE', 'BI02', 'PR_A_DIM' );
cwm2_olap_cube.add_dimension_to_cube( 'BI02', 'PR_CUBE', 'BI02', 'PR_B_DIM' );
dimkeymap :=
     'DIM:'
|| 'BI02'
|| '.PR_A_DIM/HIER:HIER_DIM_A/LVL:LOW_LEVEL_A/COL:DIM_A_KEY;DIM:'
|| 'BI02'
|| '.PR_B_DIM/HIER:HIER_DIM_B/LVL:LOW_LEVEL_B/COL:DIM_B_KEY;';
cwm2_olap_table_map.map_facttbl_levelkey( 'BI02', 'PR_CUBE', 'BI02', fact_t, /*'ET'*/ 'LOWESTLEVEL', dimkeymap );
cwm2_olap_table_map.map_facttbl_measure( 'BI02', 'PR_CUBE', 'MEAS1', 'BI02', fact_t, 'MEASURE_1', dimkeymap );
cwm2_olap_table_map.map_facttbl_measure( 'BI02', 'PR_CUBE', 'MEAS2', 'BI02', fact_t, 'MEASURE_2', dimkeymap );
Thanks a lot for your help....

Similar Messages

  • Storage option for Non leaf level dimension members: Store vs Dynamic calc

    Hi All,
    What is the general rule regarding the storage options for non leaf level members? My understanding is that it should be Dynamic Calc under normal circumstances and have it as store if we are going to load data at non leaf level. Is this correct? Are there any other considerations while defining the members?
    Thanks and Regards,
    Amol

    Don't forget to consider whether the dimension is sparse or dense. Upper level dynamic calcs generally work well on dense dimensions as long as you aren't entering data into upper level members. Upper level dynamic calcs in a sparse dimension CAN work well, but usually only on smaller dimensions. This really depends on what else you have going on in your cube. On large sparse dimensions, upper levels are almost always stored, but this is one of those areas where you can sometimes bend the rules.
    Also, don't forget to consider the calc order implications of making something stored or dynamic.
    - Jake

  • Skip Level Dimensions

    Dear all
    We have a client with an interesting problem. I was wondering if the group could offer any feedback on this design question, where we think it involves a concept called 'skip levels'. The client is using Oracle 9.0.2 with their data mart cube held as ROLAP. Our first thoughts are that what they want to do is better served by using a true OLAP tool such as Oracle Express, or Oracle 9i OLAP, which deals with skip level dimensions easier. Anyway, here's the problem :
    "For our warehouse project, we need some dimensions (initially: account, company) that use a skip level hierarchy. This means that the lowest level dimensions are of the same level (G/L account or company) and they need to roll up in a structure of varying levels, before they come together again in a highest level.
    Ideally, we would like to use a data structure that can be used transparently by the user and allows for rollups of amounts through the dimension. We would like to be able to populate the dimension through OWB and to query the data using both Crystal reports v9 and BI beans and possibly other tools that recognize the Oracle data warehouse concept.
    The two solutions we are aware of are:
    1.     Insert Dummy levels:
    This is not a nice solution but is will work and it is simple.
    2.     Insert a helper table that contains the higher level account with all the children (as per Ralph Kimball)
    This seems a cumbersome solution but I am sure it would work also. The question is how the Oracle's BI beans and the CWM2 metadata would recognize this and how we can make this transparent to the user.
    I am sure there are other solutions to the problem. It seems like the problem would be solved by the next release of Oracle (9.0.3?), which allows us to deal with skip level hierarchies through CWM2 (which I believe this is). The solution we choose should also allow us to easily upgrade to the new skip level hierarchy, which I would expect to be easier to use then the above."
    The main thing to bear in mind here is that they want to implement a ROLAP solution, using Oracle 9i tables, dimensions and heirarchies. It also has to work with Oracle Warehouse Builder, take advantage of the CWM2 metadata (if possible) and work with the BI Beans.
    Any thoughts on this? Does anyone know how Oracle are going to cater for skip-level dimensions with the next release? Is this through the improved support for the CWM2 metadata standard for ROLAP cubes, or is the customer best of going to the true OLAP 'Analytic Workspace'? If we ignore a MOLAP solution, what's the best way of dealing with this, in such a manner that it's transparent to query tools, and isn't too much of a 'hack'?
    Many thanks in advance,
    Mark Rittman
    Mark Rittman
    Consulting Manager, Plus Consultancy
    [email protected]
    [email protected]--------------

    As part of my search i've uncovered an article by Ralph Kimball on using 'helper tables' to deal with ragged hierarchies.
    http://www.dbmsmag.com/9809d05.html
    This advocates using a table between the fact table and the dimension. Quoting from Mr. Kimball;
    "You can solve this modeling problem by inserting a helper table between the dimension table and the fact table, as shown in Figure 3 (http://www.dbmsmag.com/9809d05.html#fig3). Amazingly enough, you don't have to make any changes to either the dimension table or the fact table; you just rip the join apart and insert the helper table.
    The helper table contains one record for each separate path from each node in the organization tree to itself and to every node below it. There are, then, more records in the helper table than there are nodes in the tree. In Figure 3 we need a total of 43 records in the helper table. See if you can work this out.
    Each record in the helper table contains the fields:
    - Parent Customer Key
    - Subsidiary Customer Key
    - Depth From Parent
    - Lowest Flag
    - Topmost Flag.
    If you are descending the tree from certain selected parents to various subsidiaries, you join the dimension table to the helper table and the helper table to the fact table with the joins as shown in Figure 3. The Depth From Parent field counts how many levels the subsidiary is below the parent. The Lowest Flag field is True only if the subsidiary has no further nodes beneath it. The Topmost Flag field is True only if the parent has no further nodes above it.
    The beauty of this design is that you can place any normal dimensional constraint against the Customer dimension table and the helper table will cause all the fact table records for the directly constrained customers plus all their subsidiaries to be correctly summarized. In other words, you can use your standard relational databases and your standard query tools to analyze the hierarchical structure."
    My question is - has anyone tried to implement this with OWB, or with the Oracle ROLAP data warehouse in general, reporting through Discoverer or BI Beans? Any opinions?
    thanks
    Mark

  • ROLAP skip level dimension support - CWM2?

    Dear all
    We have a client with an interesting problem. I was wondering if the group could offer any feedback on this design question, where we think it involves a concept called 'skip levels'. The client is using Oracle 9.0.2 with their data mart cube held as ROLAP. Our first thoughts are that what they want to do is better served by using a true OLAP tool such as Oracle Express, or Oracle 9i OLAP, which deals with skip level dimensions easier. Anyway, here's the problem :
    "For our warehouse project, we need some dimensions (initially: account, company) that use a skip level hierarchy. This means that the lowest level dimensions are of the same level (G/L account or company) and they need to roll up in a structure of varying levels, before they come together again in a highest level.
    Ideally, we would like to use a data structure that can be used transparently by the user and allows for rollups of amounts through the dimension. We would like to be able to populate the dimension through OWB and to query the data using both Crystal reports v9 and BI beans and possibly other tools that recognize the Oracle data warehouse concept.
    The two solutions we are aware of are:
    1.     Insert Dummy levels:
    This is not a nice solution but is will work and it is simple.
    2.     Insert a helper table that contains the higher level account with all the children (as per Ralph Kimball)
    This seems a cumbersome solution but I am sure it would work also. The question is how the Oracle's BI beans and the CWM2 metadata would recognize this and how we can make this transparent to the user.
    I am sure there are other solutions to the problem. It seems like the problem would be solved by the next release of Oracle (9.0.3?), which allows us to deal with skip level hierarchies through CWM2 (which I believe this is). The solution we choose should also allow us to easily upgrade to the new skip level hierarchy, which I would expect to be easier to use then the above."
    The main thing to bear in mind here is that they want to implement a ROLAP solution, using Oracle 9i tables, dimensions and heirarchies. It also has to work with Oracle Warehouse Builder, take advantage of the CWM2 metadata (if possible) and work with the BI Beans.
    Any thoughts on this? Does anyone know how Oracle are going to cater for skip-level dimensions with the next release? Is this through the improved support for the CWM2 metadata standard for ROLAP cubes, or is the customer best of going to the true OLAP 'Analytic Workspace'? If we ignore a MOLAP solution, what's the best way of dealing with this, in such a manner that it's transparent to query tools, and isn't too much of a 'hack'?
    Many thanks in advance,
    Mark Rittman
    Mark Rittman
    Consulting Manager, Plus Consultancy
    [email protected]
    [email protected]--------------

    Dear all
    We have a client with an interesting problem. I was wondering if the group could offer any feedback on this design question, where we think it involves a concept called 'skip levels'. The client is using Oracle 9.0.2 with their data mart cube held as ROLAP. Our first thoughts are that what they want to do is better served by using a true OLAP tool such as Oracle Express, or Oracle 9i OLAP, which deals with skip level dimensions easier. Anyway, here's the problem :
    "For our warehouse project, we need some dimensions (initially: account, company) that use a skip level hierarchy. This means that the lowest level dimensions are of the same level (G/L account or company) and they need to roll up in a structure of varying levels, before they come together again in a highest level.
    Ideally, we would like to use a data structure that can be used transparently by the user and allows for rollups of amounts through the dimension. We would like to be able to populate the dimension through OWB and to query the data using both Crystal reports v9 and BI beans and possibly other tools that recognize the Oracle data warehouse concept.
    The two solutions we are aware of are:
    1.     Insert Dummy levels:
    This is not a nice solution but is will work and it is simple.
    2.     Insert a helper table that contains the higher level account with all the children (as per Ralph Kimball)
    This seems a cumbersome solution but I am sure it would work also. The question is how the Oracle's BI beans and the CWM2 metadata would recognize this and how we can make this transparent to the user.
    I am sure there are other solutions to the problem. It seems like the problem would be solved by the next release of Oracle (9.0.3?), which allows us to deal with skip level hierarchies through CWM2 (which I believe this is). The solution we choose should also allow us to easily upgrade to the new skip level hierarchy, which I would expect to be easier to use then the above."
    The main thing to bear in mind here is that they want to implement a ROLAP solution, using Oracle 9i tables, dimensions and heirarchies. It also has to work with Oracle Warehouse Builder, take advantage of the CWM2 metadata (if possible) and work with the BI Beans.
    Any thoughts on this? Does anyone know how Oracle are going to cater for skip-level dimensions with the next release? Is this through the improved support for the CWM2 metadata standard for ROLAP cubes, or is the customer best of going to the true OLAP 'Analytic Workspace'? If we ignore a MOLAP solution, what's the best way of dealing with this, in such a manner that it's transparent to query tools, and isn't too much of a 'hack'?
    Many thanks in advance,
    Mark Rittman
    Mark Rittman
    Consulting Manager, Plus Consultancy
    [email protected]
    [email protected]--------------

  • Filtering Dimension Members

    Hi,
    Is it possible in OLAP DML to filter dimension members based on dimension attribute ?
    For example show customers where gender is male ?

    Thanks, it works.
    One more question
    I want to use the same condition in a QDR expression. i-e Retrieve the sales of male customers. The statement
    report sales(gender_rel, 'MALE') --- ( Does not work because gender_rel is not a dimension)
    Could you please tell me how can I achieve this ?

  • How can I modify Time dimension to create a Top member above year members ?

    Hi experts,
    I would like to modify Time dimension to add a Top member above year members.
    I already did a test:
    I added a member in Time dimension which is the parent of all year members. I granted it these property values:
    - ID = TOTAL
    - EVDESCRIPTION = Total
    - LEVEL = TOTAL
    - HLEVEL = 1 (and I added 1 to all the other members)
    - TIMEID = 10000001
    All other properties were left blank for this member.
    I processed the dimension. It went well. But when I tried an evdre in BPC excel it failed.
    Any idea of something missing ?
    I am working on SAP BPC MS 7 SP4
    Thanks for your help
    Ludovic

    Hi Petar,
    Thanks for your answer. No doubt that we could solve the issue using on of the way you suggested.
    However, even though I had the evdre issue right after applying time dimension modifications, it occurs that the evdre issue was not due to time dimension modifications. I tested it better and I can tell that using "total" as a level works.
    Best regards,
    Ludovic

  • Lowest Level in Dimension

    HI guys
    i have rdbms 9.0.4
    can i define lowest level of dimension that is not the primary key of the dim table ( this field has unique values)
    or the lowest level of dimension should be the primary key of the dimension table.
    thanks alot.
    Brad

    Hi Matt!
    Glad to read you again!
    I agree with you that in this simple example, I should be able to make this a star schema.
    but :
    - on a functional point of view, this date is an attribute of a vehicle, not of an invoice. But let's ignore this.
    - this problem is the same as one we have in another part of the BM, which is much more complex. In this complex BM, I can't use star schemas because it removes some joins we need in order to perform some reports.
    This is why I'm looking for another way to proceed.
    If you have time to spend on the complex BM, here is a simplified description :
    * in the physical layer, I have:
    - a calendar table with multiple aliases to be used with each dates in the following,
    - an invoice header table
    - an invoice detail table
    with
    some header date -> header table -> detail table
    some detail table -> detail table
    * in the logical layer (stars), i have:
    - my calendar dates with their dimensions
    - an invoice dimension table with the two sources (header + detail) + its dimension
    - an invoice header fact table
    - an invoice detail fact table
    header date -> header fact
    invoice dim -> header facts
    invoice dim -> detail facts
    detail date -> detail facts
    I mus be able to query details facts while showing or filtering the header date. In such a configuration, you'll understand it isn't possible as there isn't any relationship between the detail facts and the header date. This is why the header date should be kept as a dimension of the invoice dimension, which is similar to my basic example.
    Unless I went wrong somewhere?
    Thanks!
    Ced.
    Message was edited by:
    ced

  • How to obtain BOM componnts at the lowest level based on SUB item indicator

    I am doing a report based on CK13N wherein i hav material and plant as the selection parameters and based on that i get the product costing of the entire BOM.
    I pass material to MAST.get the BOM num and usage
    Pass it to STAS and get STLKN (ITEM NODE NUMBER)
    After that i pass STLKN and STLNR(BOM number) to STPO to get the BOM subitems based on UPSKZ(Sub items indicator). But that fails because UPSKZ is nt set for all the assemblies.
    So hw do i get the BOM components at the lowest level USING these TABLES..

    Ashwin
    1) As Taj Said, Sub item is not actually a item or component.
    2) The sub item number what we are viewing the sub item sceen will be 001,002 like ,it not mean any item
    3) For Example a car has 4 wheels, so the item/component description is WHEEL
    4) The BOM Quantity of wheel is 4
    5) In BOM General item over view, you can select the wheel then click subitem
    6) This will lead to sub item screen
    7) There you can see subitem 001,002,003 then installation point,subitem text,qty etc
    8) Against installation point you can decalre Front Left,Front Right,Rear Left,Rear Left
    9) Against sub item text,qty you can declare Front Left wheel-1,Front Right wheel-1, Rear Left wheel-1, Rear Right wheel-1 no
    9) This does not mean there are addition Sub items for wheel (ie) additional BOM component)
    10) Just declaring the positions for fitting in the car to ease the Assembly Person for fixing the wheel
    11) So if you get the cost for WHEEL as assigned in BOM item then ok, don't worry about sub item cost
    Reward me if my answer is helpful
    K.Prabakaran

  • Attribute Dimension and association with multi level base members

    I am trying to associate attribute dimension members with base members that can be at different levels (level 0 or level 1 or level 2 ).
    First question - Is that possible ? Second how do I do that.
    I am building the dimensions(base and attribute) members first and then trying to associate.
    I get the following error message :
    Base member (xxxxxxx) association level does not match base dimension association level
    The base dimension looks like
    Supplier
    |-----Supplier Group
    |---------Supplier ID (Associate this member to an attrbiute dimension)
    |---------------Invoice Number
    Sometimes the Supplier ID may not have a Supplier Group or an Invoice Number (hence it can be a level 0 or directly under the dimension name - Gen2)
    The Attrbute Dimension looks like
    Supplier Value
    |---High
    |---Medium
    |---Low
    Edited by: 816875 on 30-Nov-2010 07:01

    First to clarify, base mambers by definition would all be level 0 members, but to your question, attributres can only be associated to a single level within a dimension. your problem is sometimes the supplier is level 0 and other times level 1. This can't be done.

  • On deleting lowest level members

    Hi, Why is it that some upper level member data is lost when I delete its lowest level members? I don't have dynamic calculation members in my cube. Is this because of the restructuring after the outline has been changed?

    Is this only occurring on one-to-one relationships? i.e - a parent with only one child?If this is the case this is due to an implicit share (the data is only stored once, not in both members) and when you delete the child the value disappears from the parent also.Hope this helpsDavid Cooper, Analitica Ltdwww.analitica.co.uk

  • Exluding lowest level dimensionmembers from a total report.

    Hi,
    I know this thread might belong in the Discover part of the forum, but based on previous experience it seems that Discoverer for OLAP help is difficult to come by in that part. Also I think this quickly might end up with being a bit more OLAP technical.
    To the issue:
    Say that you have a sales cube with 3 dimensions, time, product and customer.
    The customer dimension has three levels with one standard hierarchy in the following order: Total, customerclass and customertype.
    For the lowest level there is a customertype member thats named "internal". This means that all employees buying from their own company with a special discount is placed under this member.
    Now to the report:
    Using discoverer for Olap, management want two total reports. One where the Internal member is included, and one where it is excluded. This meaning that the initial report should just show the total levels for all dimensions, just with different totals.
    Now I thought of just not include the internal member when you choose different dimensions in the query builder, but as far as I know this would only work for the lowest level. Total and customerclass would still show sums that include the internal level since the cube has aggregated these levels in advance.
    Does anyone a way to work around this?
    some cube facts:
    database version 10.2.0.3. with the OLAP A patch
    cube compressed and partitioned along month, fully aggregated for all levels(except year).
    regards Ragnar

    Rangar,
    Simplicity is in the eye of the beholder, but you should be able to make it work. The details will depend on your source mapping, but I will assume that you have a single dimension star table with three columns, one per level.
    CREATE TABLE CUST
    Total varchar2,
    CustomerClass varchar2,
    CustomerType varchar2
    I'll assume further that the member 'INTERNAL' appears as CustomerType. Define a VIEW on top of the table like this.
    CREATE VIEW CUST_VIEW AS
    SELECT *
    FROM CUST
    WHERE CustomerType != 'INTERNAL'
    Now create two new levels
    TOTAL_EXTERNAL
    CUST_CLASS_EXTERNAL
    Create a new level hierarchy, EXTERNAL_HIER say, that includes the two new levels along with the existing CustomerType level.
    TOTAL_EXTERNAL
    CUST_CLASS_EXTERNAL
    CUSTOMER_TYPE
    Note that even though the CUSTOMER_TYPE level appears in two hierarchies, the members in that level can vary be hierarchy. This is important since it means you do not have to reload the leaf data for the cube.
    Now map the new hierarchy to the three key columns in CUST_VIEW. To do this correctly you need to switch to the "Snowflake Schema" view on the AWM mappings tab. This allows you to explicitly set the parent column for each hierarchy. So, in your new EXTERNAL_HIER hierarchy the parent of CUSTOMER_TYPE is CUST_VIEW.CustomerClass. In your old hierarchy, INTERNAL_HIER say, the parent of CUSTOMER_TYPE is CUST.CustomerClass. If you don't switch to the "Snowflake Schema" view then you will end up with null values for the parent dimension. (I just wasted 45 minutes discovering this fact.)
    You now have two hierarchies and five levels. Your aggregation strategy for the cube should reflect this in some way. If you want full pre-aggregation, then you will need to add the two new levels to the cube. If not, then you are probably set.
    David

  • Leaving some level 0 members out of calculation

    Hi Everybody,I have two measures in my Accounts dimension. The first can take advantageof the Outline consolidation of the Products dimension, but the second needsto skip some level 0 members. I have tagged the the members I don't want toconsolidate with an UDA "Base".I tried to use CALC ALL EXCEPT MBR(@UDA(Products,Base)); But this causes anEssbase error when calculating. (Not in a calcscript Editor).Any workaround ideas to to leave these members out of the consolidation.Thanks in advantage.

    Question: Is Your Level zero Data is calculated or Loaded through Data files ?Answer1: If it is loaded Data Then Follow Below Procedure.Fix((@UDA(Products,Base))ClearData "Measure you want special Calc" ;Endfix ;Load Data for the lowest level where the memebers are tagged with Base UDA.Answer2: If it is calculated Data Then Follow Below Procedure.Then run the calc Script to Populate lowest level Data if needed.Please let me know if you have any Questions ?ThanksSreenivas

  • SSRS with calculated dimension members SSAS

    Hello everybody,
    I have an interesting scenario involving a SSRS report with a matrix connected to a SSAS cube containing calculated dimension members.
    One of the parameters is "Reference Week".  Based on that parameter, I need the measures for the previous 5 weeks.
    So I created an anchor dimension "Analysis Weeks" with the members "Week -1" to "Week -5".
    Everything is working fine.  The only problem is the names of the columns on the report.  
    Currently I have "Current Week", "Week -1", etc. as column names, I'd like to show the real dates.
    For example, if I choose "2014-02-15" as the reference week, I want the first column to show "2014-02-15" instead of "Current Week". The second would show "2014-02-08" instead of "Week -1", etc.
    I tried to get the current column position in the matrix, which I could use the with @ReferenceWeek parameter, but I can't access that property.
    Any suggestion?
    Thanks

    If I understand correctly, your column group is on "Analysis Weeks", is that right? If so just get the value of that field and use it to get the dates.
    =DateAdd("d",-1*CInt(Right(Fields!AnalysisWeeks.Value,1))*7,Fields!ReferenceWeek.Value)
    "You will find a fortune, though it will not be the one you seek." -
    Blind Seer, O Brother Where Art Thou
    Please Mark posts as answers or helpful so that others may find the fortune they seek.

  • Aggregation at the lowest level in the cube

    Hi guys
    I designed very simple test cube with one dimension (both MOLAP driven).
    The dimension PRODUCT consists of three levels:
    - Group
    - Category
    - Product_detail
    PRODUCT_SRC table to load PRODUCT dimension:
    PR_GROUP_NAME PR_GROUP_ID PR_CATEGORY_NAME PR_CATEGORY_ID PR_DETAIL_NAME PRODUCT_DETAIL_ID
    dairy 1000 yoghurts 1000000 yoghurt_1 1000000000
    dairy 1000 yoghurts 1000000 yoghurt_2 1000000001
    dairy 1000 yoghurts 1000000 yoghurt_3 1000000002
    candy 1001 cookies 1000001 cookies_1 1000000003
    candy 1001 cookies 1000001 cookies_2 1000000004
    candy 1001 cookies 1000001 cookies_3 1000000005
    beverages 1002 juices 1000002 juice_1 1000000006
    beverages 1002 mineral water 1000003 mineral_water_1 1000000007
    beverage 1002 energy drink 1000004 energy_drink_1 1000000008
    The cube SALES has one measure:
    - Value_of_sales (sum aggr)
    SALES_SRC table to load SALES cube:
    VALUE PROD_ID ID
    1236 1000000002 2
    115 1000000006 3
    1697 1000000005 4
    12 1000000004 5
    168 1000000008 6
    1984 1000000005 7
    9684 1000000004 8
    84 1000000002 9
    8 1000000007 10
    498 1000000006 11
    4894 1000000008 12
    4984 1000000004 13
    448 1000000003 14
    4489 1000000004 15
    13 1000000001 16
    879 1000000004 17
    896 1000000006 18
    4646 1000000007 20
    I created the dimension PRODUCT and a mapping which loaded the data into the dimension. It worked perfectly. The hierarchy was created as I expected.
    Then I created cube SALES and a mapping which should load the data into the cube. It is very very simple mapping - there were just only two items on the canvas:
    - SALES_SRC table
    and
    - SALES cube
    and two lines:
    - from SALES_SRC.VALUE to SALES.VALUE_OF_SALES
    - from SALES_SRC.PROD_ID to SALES.PRODUCT_NAME
    Then I deployed everything and ran mapping, which loaded cube. But in my opinion the cube was not populated in a proper way, because it was no aggregation performed at the lowest level of product hierarchy - there was only a value of the first occurence of certain product. I mean:
    In SALES.SRC we have for instance:
    VALUE PROD_ID ID
    1236 1000000002 2
    84 1000000002 9
    For me the the value in the cube should be 1236 + 84 = 1320, but the value in the cube at PRODUCT_DETAIL_LEVEL for yoghurt_3 is only 1236 - first occurence of this product in SALES.SRC.
    Why hasn't been the data aggregated at lowest level of PRODUCT dimension hierarchy - is it the way OWB does such things?
    Should I manually aggregate the data before loading to cube (just to use Aggregator to aggregate the data at lowest level)? If yes - what about incremental loading of data to cube (the old value value is simply replaced by new one and not summed in the cube)
    In data warehouse solutions of other vendors the cube in such situation is loaded as I expected here.
    I really don't know what to do. I do really appreciate any help from you.
    Thank you in advance
    Peter

    Hi David
    Thank you very much.
    Now I'm sure that I have to aggregate facts by myself at the lowest level of hierarchy in a dimension.
    Regards
    Peter

  • Two Dimension Hierarchys based on one Logical Table

    Is it possible to have two dimesion hierarchys based on one logical table? Suppose we have the following case:
    Accounts Table
    Code
    Name
    Category
    Subcategory
    Level 1
    Level 2
    Level 3
    I would like to have one dimension Total > Category >Subcategory > Code and one Total > Level 1 > Level 2 > Level 3 > Code, so I can drill down on both paths. Is this possible?
    Thanx

    Yes, the trick is to have the same key on the lowest level in your hierarchy.
    regards
    John
    http://obiee101.blogspot.com/

Maybe you are looking for