Removing a dimension

Hi,
Our company is revamping COA, as part of this they will replace OU in Dept dim and merge them with Entity dimension. So we need to remove Dept dim and merge its members with Entity dim. To accomplish, we need to create new application, remove any reference to Dept dim from forms/grids/reports/rules/task lists etc. Have to change mappings in FDM/ERPi accordingly. Also make relevant changes in the new entity members, which moved from Dept dim. I need inputs on:
1. Are there any other strategy, which we can use?
2. Can we migrate the application with Dept dim and remove all its members and just have none member in it. In such a situation, we do not have to change a lot of things, as mentioned above. Any harm in having this dim forever in the application.
Any other inputs will be appreciated.

Hi,
The main question is whether you have data in this application that you need to preserve. Otherwise all strategies that you have already suggested are fine, however creating a fresh application with only the new structure in mind would be the best option.
--Kostas                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

Similar Messages

  • Hide / remove a dimension  (urgent)

    I want to hide / remove a dimension from an existing Crosstab programmatically,
    I used this code in the JSP file
    int toEdge = DataDirector.max_edge + 1;
    DataDirector dataDirector = crosstab.getModel().getDataDirector();
    try
    dataDirector.pivot(fromEdge, toEdge, fromLayer, toLayer, flags);
    catch (Exception e)
    but pivot method used to swap the dimension(which I need to hide) with another in the hidden dimensions list .
    I need to hide it (making invisible) NOT swapping.
    Crosstab Class has method setInvisibleColumn(), but I don´t know the way how to use it.
    please help me
    thanks
    Sana

    My list doesn't show up whenever I use the (AND grafoiid is null) inside of my WHERE statement. My code is below...
    <cfquery name="student" datasource="master">
    SELECT name.foiid, gradelt, gradelt.graltid, CONCAT(name.fname,' ',name.xholy,' ',name.slave) AS student, grafoiid
    FROM gradereport
    LEFT JOIN  name  ON foiid = grafoiid
    LEFT JOIN gradelt ON graltid = ltid
    WHERE 0=0
    AND type = '1stG'
    AND gradelt = '#session.user_id#'
    AND ltid = '#session.user_id#'
    AND CITY = 'richmond'
    AND STATUS <> 'd'
    AND STATUS <> 'T'
    AND grafoiid is null
    AND Form4Complete = 'yes'
    GROUP BY student
    ORDER BY student
    </cfquery>
    If it replace the (AND grafoiid is null) with (AND grafoiid is not null), it will only list the students who are already in grade table. I would like to tweak this to only show the list of students who have not been inserted into the grade table yet. Am I missing something in my code?

  • How do I 'remove' a dimension from a cube when creating a crosstab?

    I have a CUBE with 9 dimensions and one measure, This is based of a fact table that has a Materialized View with just 4 dimensions.
    In JDeveloper I used the wizard to create a new crosstab using just the four dimensions that exist in the MV (removing the others).
    ....eventually the page was generated but it takes minutes....
    Q. Is there a way to 'DROP' a dimension from JDeveloper crosstab when you query a CUBE?
    [It looks like Oracle is internally using all 9 dimensions when some are "Hidden"  or not required!]
    The only solution I have found is to create an extra CUBE using just the 4 dimensions (this works within couple of seconds)! But I will end up with 6 CUBES holding different dimensions combination, this feels wrong?
    Q2. Is it bad practice to have multiple CUBES all based on one fact table, just to improve performace?
    I hope you can help.
    Steve

    i think this question is more for the technical teams at the olap forum ;)
    nevertheless: if you have a cube defined with 9 dimensions,all of them are necessary for retrieving the data, "hiding" some of them is possible by the means of "hidden dimensions"
    nevertheless you have to specify which dimension, value gets substitued for those dimensions: usually it is a TOTAL level.
    otherwise your results may be misleading or wrong, so specifying a dimension value for those hidden dimensions is the only choice to be consistent with the OLAP data model
    btw: you can easily use a materialized view in this environment as well, when using the concept of a TOTAL dimension value
    regards,
    thomas

  • Planning - Possible to Remove Period Dimension?

    Hi,
    Client doesn't need Period as everything they do is at year only.  Can I remove Period and just use the Year as the 'Time' dimension in a Classic Planning application?  Or am I required to have period?

    Period is one of the required dimensions.  At best, you'll have to include a Period dimension with at least one member.  (I've never tried it with just one member.  I THINK that will work but I'm not certain.)
    - Jake

  • How to remove dimension from report

    Dear All,
    I have created a report using Drag and Drop option as explained in the following link with 2 dimensions in rows and 1 dimension in column. Now I would like to remove one of the dimension from existing report. As explained in the below link I could not able to see the option called Remove Dim from design mode as well as preview mode.
    http://help.sap.com/saphelp_bpc70/helpdata/en/32/5facaf79c14163b3ae976733d4ae65/content.htm
    SAP Help: To remove a dimension, right-click on the dimension name block and select Remove Dim. You can remove dimensions only when more that one exists on either your columns or rows.
    Please, can anybody shed some light on this issue.
    thanks in advance..
    regards,
    Raju

    Dear Pravin,
    Thanks for the reply.
    I have tried this drag and drop option. But the problem with this option is existing format is getting disturbed and some junk values appearing in place of removed dimension.
    thanks and regards,
    Raju

  • Remove Dimension Member

    Hi
    I want to remove a dimension member from a dimension.
    To do this, I create a maintenance script with only one step.
    This step includes a OLAP DML command in witch the following code is written (General tab):
    call remove_dimension_member('1', 'DIM_2', NA, NO) In the Measures tab I selected only one measure, because you have to select at least one.
    In the Status tab I leave the default selections.
    After running this maintenance script, the following Error occurs:
    <font color="red">INI: error creating a definition manager, Generic at TxsOqConnection::generic<BuildProcess>INI: XOQ-00703: error executing OLAP DML command "(call remove_dimension_member('1', 'DIM_2', NA, NO) : ORA-37162: OLAP error
    XOQ-01706: An unexpected condition occurred during the build: "xsoqBuildRecursive DBMS_CUBE.BUILD not supported".
    ORA-06512: at "SYS.DBMS_CUBE";, line 234
    ORA-06512: at "SYS.DBMS_CUBE";, line 287
    ORA-06512: at line 1
    )", Generic at TxsOqAWManager::executeCommand
    </font>
    When I run the same DML-Command in OLAP-Worksheet, it works.
    Do I something wrong?
    Thank you for any help.
    Markus

    The OLAP DML program, remove_dimension_member, is implemented using DBMS_CUBE.BUILD. So by calling it within a build script you are effectively calling DBMS_CUBE.BUILD from within DBMS_CUBE.BUILD, which is not supported. This is why you get the error message "xsoqBuildRecursive DBMS_CUBE.BUILD not supported".
    The obvious workaround is to execute the call outside of the contents of a maintenance script, but here is a (non AWM) workaround if you really need to integrate with DBMS_CUBE.BUILD.
    If you execute the remove_dimension_member in OLAP Worksheet, you can then look at the contents of the CUBE_BUILD_LOG for the latest build to see how it all connects. Here is an example I ran from SQL*Plus
    SQL > execute dbms_aw.execute(q'!
    call remove_dimension_member('APR-2011', 'TIME', NA, NO)!')
    IMPORTANT: Analytic workspace TEST_AW is read-only. Therefore, you will not be
    able to use the UPDATE command to save changes to it.
    PL/SQL procedure successfully completed.
    SQL > select command, status
         2 from cube_build_log
         3 where build_id = 10
         4 order by time;
    COMMAND             STATUS
    BUILD                 STARTED
    DELETE DIMENSION MEMBER   STARTED
    DELETE DIMENSION MEMBER   COMPLETED
    REBUILD FREEPOOLS       STARTED
    REBUILD FREEPOOLS       COMPLETED
    BUILD                 COMPLETED
    SQL> select build_script
         2 from cube_build_log
         3 where build_id = 10  and command = 'BUILD' and status = 'STARTED';
    BUILD_SCRIPT
    BUILD NO COMMIT "TIME" USING (DELETE FROM DIMENSION WHERE MEMBER = 'APR-2011')This means that you can delete a member directly using DBMS_CUBE.BUILD as follows. Note I removed the keyword BUILD when running this through DBMS_CUBE.BUILD.
    begin
    dbms_cube.build(q'!
      NO COMMIT "TIME" USING (DELETE FROM DIMENSION WHERE MEMBER = 'APR-2011')
    end;
    /Remove the NO COMMIT if you want the build to commit your change (as opposed to keeping in a READ ONLY session).

  • Retrieval time unchanged even after extra dimensions removed from ASO app

    We have an ASO application on which HFR reports are running. The application has 18 dimensions. The HFR reports running were taking a long time to get generated so we created a duplicate of that application and removed 5 dimensions which were not being used. Even after running the reports out of the duplicate application the generation time has not reduced.
    Please advice.

    Do you know how the report generation time relates to the Essbase query time (check the Essbase application log)? It might be that you're doing a lot of work on the FR side.
    If the problem really is on the ASO side, did the number of input data cells and / or key length change significantly when you removed the dimensions? If not, removing dimensions (which I am assuming were not referenced in the report in the first place) might not get you very much in terms of query performance. Have you created any aggregate views on the ASO cube?
    If you have a particular 'problem' report it's possible to use query tracking to create some aggregations directly to support that one query, particularly if the report always retrieves at the same level in each dimension.

  • Export file - fixed columns and remove dimensions

    Hello Experts
    I wan't to use the standard export package ang get dimensions fixed in specific columns and also remove some dimensions.
    The problem is that i always get the dimensions randomly in columns and when i am able to remove dimensions, the dimensions are removed randomly, please see *MAPPING and result below, does anyone know how to do this? Or have an example? I have used the standard example files but they have not helped....
    *OPTIONS
    FORMAT = DELIMITED
    HEADER = YES
    DELIMITER=
    VALIDATERECORDS=NO
    ROUNDAMOUNT = 7
    OUTPUTHEADER=
    OUTPUTDELIMITER=
    SPECIFICMAPPING=YES
    *MAPPING
    ENTITY=*COL(1)
    TIME=*COL(2)
    ACCOUNT=*COL(3)
    RPTCURRENCY=*COL(4)
    AMOUNT=*COL(5)
    ACCOUNT,ENTITY,RPTCURRENCY,TIME,AMOUNT
    NON_FLOW,ADT5_E,ACTUAL,ANA_TONS,TOTALADJ
    NON_FLOW,568U_E,ACTUAL,ANA_TONS,TOTALADJ
    Best regards
    Jonas

    Given the nature of OLAP and FACT tables, I do not beleive that you are able to disassociate a dimension from the export process.  So, I don't think that you may choose the dimensions to export, plus there method of being written to a file may just be alphabetical. I would export the complete details and then manipulate the details during an import process. The only other alternative that I can think of is to write a custom SSIS SQL script, to allow for FACT member aggregation if you choose to remove a dimension.
    But I would need to test further. Hope this helps.

  • Adding a New Dimension to a CUBE

    Hello
    Being in new at Oracle OLAP...
    If I need to add a new dimension, SHOULD I RECREATE the cube entirely again??
    Is not there any other way??
    Regards

    Each cell in a cube is referenced by a dimension. Think of it as pointers to cells in a multi-dimensional array.
    So when you add or remove a dimension, what should happen to all those cells.
    In a way you are breaking the cube.
    Since cube data is loaded from a table, you can always re-load your cube after adding or removing a dimension.
    Dimensions are not added/removed frequently, once the design is finalized. You may add a new hierarchy to existing dimensions, which is done more frequently compared to adding a dimension. After adding a new hierarchy, you just have to re-aggregate cube data and not re-load from relational source.
    Cubes are created for reporting, and can be deleted/recreated or truncated - monthly, quarterly or yearly - for various reasons.
    Your source transactional detailed data should be in one (or more) fact tables and should never be deleted.
    Is there any "operational" concern in a Production environment, because of which you are asking this question?
    One trick could be: to create the new cube (with more dimensions or less dimensions than the original cube) and then COPY DATA from original cube into that new cube.
    But it may take the same amount of time as re-loading the new cube from the relational source.

  • 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

  • Web Analysis Studio. Error in report that uses dimension that was deleted.

    Hi, everyone.
    Firstly I created a web analysis document.
    Then i deleted one dimension from the cube outline.
    And when I run the report I ve got an error like this:
    [1033] Native: 502 Invalid object file specified
    App\TEST\Cube\TST_C\Category
    Please advise, how can I delete the dimension from the report.
    Thanks.

    Thanks for your answer.
    Does the report open without the dimension?It opens blank.
    If the report opens then you can navigate to data source (dimension browser) and remove the dimension.How can I do this? This dimension is not in rows, nor columns, nor pages - it is in filter.
    Open the report, remove the dimension from report and saveHow can I do this? Please help, I think this is the way to move further.
    Actually, I have hundred of reports which rely on one cube, from which one dimension was deleted.
    So, I really need an approach to make reports automatically reflect changes in outline (I mean deleting of one dimension).

  • A bug in the warehouse builder regarding mappings of dimensions

    Hi there
    I do not know if this is the right place to submit a possible bug. Anyways - here goes.
    Warehouse builder client: 10.1.0.2.0
    Warehouse builder repository: 10.1.0.1.0
    I'm creating a dimension, having one level attributes property as a varchar2(30). Thus it has a length of 30. Now, later on I decide this was an error. I update the property to a number, deploys, and reconcile the dimension inbound in the mapping. From now on, it will give an error, since it remembers the length. And a number has a size, not a length. If I remove the dimension from the mapping, and inserts it again, the error still occurs.
    By the way, I am able to reproduce this.
    Anyone who has experienced this, and can blame the stupid user (me) or classify this as a bug?
    Yours
    Kim Andersen

    Hi Igor
    The "error" is actually a "warning":
    Warning: VLD-1004: Column length of ASD_ASDASD is longer than the target column length.
    where ASD_ASDASD is the dimension property, which I altered. It is annoying, though, to have warnings on the list, that aren't needed. And I also spent considerable time thinking that was the error in a mapping, whereas it was a stupid mistake made by me somewhere else :)
    If it's a registered bug, do I get to win some branded Oracle candy?! :)
    Yours
    Kim

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

  • BW : Line Item Dimension

    Hii All,
    Can you plz explain what is Line Item Dimensions...with examples.I am confused.
    Plz help.
    Thanks &  Regards,
    Madhavi S Bichakal

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

  • Regarding line item dimension

    Hi all,
    what are the necessary prerequisities will u take regarding line item dimension.
    for eg., for sd cubes we r using sales doc no., i.obj as a line item dimension? why can't the other i.obj?
    plz explain me clearly?
    Thanks & Regards,
    V.Vijay.

    HI,
    Line Item and High Cardinality
    When compared to a fact table, dimensions ideally have a small cardinality. However, there is an exception to this rule. For example, there are InfoCubes in which a characteristic document is used, in which case almost every entry in the fact table is assigned to a different document. This means that the dimension (or the associated dimension table) has almost as many entries as the fact table itself. We refer here to a degenerated dimension. In BW 2.0, this was also known as a line item dimension, in which case the characteristic responsible for the high cardinality was seen as a line item. Generally, relational and multi-dimensional database systems have problems to efficiently process such dimensions. You can use the indicators line item and high cardinality to execute the following optimizations:
    Line Item Dimensions
    Line item: This means the dimension contains precisely one characteristic. This means that the system does not create a dimension table. Instead, the SID table of the characteristic takes on the role of dimension table. Removing the dimension table has the following advantages:
    ¡        When loading transaction data, no IDs are generated for the entries in the dimension table. This number range operation can compromise performance precisely in the case where a degenerated dimension is involved.
    ¡        A table- having a very large cardinality- is removed from the star schema. As a result, the SQL-based queries are simpler. In many cases, the database optimizer can choose better execution plans.
    Nevertheless, it also has a disadvantage: A dimension marked as a line item cannot subsequently include additional characteristics. This is only possible with normal dimensions.
    High Cardinality
    If your dim table size exceeds the 20% of your fact table then you can say it as high cardinality, for ex: your fact table contains 100 records and your customer dimension contains 25 records means this dim is with high cardinality. you can check with your client for the expected records for those dimensions or for the info objects which you define in one dimension. to know the sizes of the dimension tables and fact tables you can runa a program in SE37 SAP_INFOCUBE_DESIGNS, it displays all your info cubes fact and dimension tables with sizes, if any dimension exceeds the more than 10% to 20% it will be in RED.
    It means that the dimension is to have a large number of instances (that is, a high cardinality). This information is used to carry out optimizations on a physical level in depending on the database platform. Different index types are used than is normally the case. A general rule is that a dimension has a high cardinality when the number of dimension entries is at least 20% of the fact table entries. If you are unsure, do not select a dimension having high cardinality.
    http://help.sap.com/saphelp_nw04/helpdata/en/b2/fbb859c64611d295dd00a0c929b3c3/frameset.htm
    http://help.sap.com/saphelp_nw70/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
    http://help.sap.com/saphelp_nw04/helpdata/en/5c/d14d3c306f090ae10000000a11405a/frameset.htm
    Note: In SAP BW 3.0, the term line item dimension from SAP BW 2.0 must a) have precisely one characteristic and b) this characteristic must have a high cardinality. Before, the term line item dimension was often only associated with a). Hence the inclusion of this property in the above. Be aware that a line item dimension has a different meaning now than in SAP BW2.0.
    SAP recommends that you use ODS objects, where possible, instead of InfoCubes for line items.
    Tarak

Maybe you are looking for