Ideal quantity of dimensions?

Hi,
Is there an ideal number of dimensions for BI Beans?
I have an OLAP cube (made in oracle warehouse builder) with 15 dimensions. No problem migrating from OWB to OLAP Cube.
In the OEM everything seems to be OK, I have my cube with all the dimensions and measures.
When I try to create my BI Bean and I get to the Step #7 (graphic bean, last step), I have the "Next" button enabled even when it is the final step. Either if I press the "Next" or "Finish" button the BI Bean gots stucked and it does nothing.
This happens for all types of Beans (crosstabs, graphs), I don't know what else to check.
Does anyone know what could be happening here? I am a little desesperated and it is pretty urgent...
Tks a lot.
Regards,
XS

There is no limit on the number of dimensions for a cube within an OLAP application. However, you should consider the implication of this many dimensions from a UI perspective. Personally, I find in these types of situations users are forced to play find the data, as cubes created from base 15 dimensions tend to be extremely sparse. There are other ways of achieving this which provide a much simpler UI to you your used community.
Try using the BICheckCOnfig utility to ensure all your metadata is correct. There is a '-q' option which forces a query on each object registered in your OLAP catalog. This can be downloaded from the BI Beans page on OTN.
http://otn.oracle.com/products/bib/htdocs/tech_notes/bi_checkconfig_tn.html
Hope this helps
Business Intelligence Beans Product Management Team
Oracle Corporation

Similar Messages

  • Work around

    Hi gurus,
    We have an extremely large model with about 500,000 discrete variables. We have found that most of them are from Transport Lot Size profile as we need to deliver lot sizes multiples.
    Does anyone know a work around to this issue?... we think the best idea is to delete the discrete restriction, but the issue is how to deliver this lot size multiples? .
    Any idea would be appreciated.
    -Italo

    Hi there
    I agree that this is a large discretisation problem, however I think the solution will depend on your exact requirements.
    My first question would be, do you need the final result coming from the Optimiser? By this, I mean would it be okay fo rthe Optimiser to run without discrete lot sizes and suggest the ideal quantity. Then using Deployment Heuristic to round the final values to required Lot Size? This will cause a few stock issues where there is insufficient stocks to round all values, this is where your particular requirements kick in as to the answer.
    We have a similar issue and think that the manual corrections following the Deployment Heuristic would be of a manageable size. By running this way we can have a Linear Optimisation run followed by a Deployment Heuristic running in far less time than a Discrete Optimisation model (by a fair few hours too).
    Hope this helps and Good Luck.
    Ian

  • Extract part of .indd file

    Hi everyone,
    I would like to know if it is somehow possible to extract (export) a small part of a larger template. Specifically, I have a template for a book of articles, which is set up exactly as I want it to be. Is it possible to extract only one article from it (i.e., 6 pages from 200).
    I have tried several things, but neither worked.
    Thank you in advance.

    Make a new document with 1 page and ideally same page dimensions. Also open the source document.
    In the source document, select the 6 pages in the PAGES panel and from the mini menu chose "Move pages" and in the dialog select the new document.
    In the new document delete the one blank page that was created with the new document.
    Save new document.

  • Experienced web developers

    I've made it a goal of mine to be able to program with Flex.
    There's a little bit of a problem though. While I have a ton of
    drive and desire to get this done.................... I have very
    little to no experience except for some experience with visual
    basic and some earlier experience with FrontPage.
    For those of you who haven't clicked away, I realize that I
    may be in over my head on this but I'm going to do it one way or
    another. But where to start and which path to take to get there is
    the hard part to figure out. I would really appreciate it if any of
    you could give me some direction that I should take to get to that
    goal. Eg. Should I start by reading materials on Flash CS3? Or
    Action Script? Or Flex or ............ go back and learn HTML and
    XML first?
    Any help is appreciated.
    Thanks,
    Dan

    Thanks for the replies and the recommended reading. I should
    have given some more detail. I'd like to be able to harness the
    ability to make a highly user interactive website.
    Eg. Imagine a website for a cardboard box manufacturer that
    makes thousands of boxes a day for all different types of
    businesses. All of these boxes are custom tailored for the
    individual companies. The user/business could go to this box manf.
    website and see an assortment of different types of boxes in the
    form of 3D renderings (flash) in some basic styles. These
    renderings would have dimensions on them such as W x D x H and
    there would be variables on the side of the image (in the form of
    lets say text boxes or radio buttons) in which you could enter and
    therefore alter the configuration or dimensions of the basic box
    design. When clicking on a certain variable, the graphic would
    highlight the corresponding dimension or feature that is being
    affected by the variable and this way the customer would have a
    visual of how this box will end up. Ideally, when a dimension is
    entered, the graphic would change accordingly. From there the
    customer could order, pay for the boxes and get a estimated
    delivery date without ever having to speak to a cust. service rep.
    I've given myself 1 to maybe 2 years of using all of my time
    outside of my 40 hr. work week to be able to do something like
    this. I'm willing to deal with length of time and it isn't such an
    issue as much as wasting time would be..........if that makes
    sense. I guess a better question would be,
    a) Is there an easier or better way to accomplish this?
    b) From AndyWW's post, it seems as though AS3 is harder to
    learn than C#/Java. I'm probably misinterpreting that somehow. So
    lets say if you completely forgot everything you know and had to
    start fresh with this same goal of ultimately learning Flex, would
    you start by building a foundation in C# or Java to then be able to
    comprehend and learn AS3? Or jump directly into AS3 since it would
    be just as difficult to start learning AS3 as it would be to start
    C# or Java?
    Thanks again,
    Dan

  • Managing variable sized items for planning and purchase

    Dear All,
    We have the following situation, kindly help in resolving the same:
    Some of the raw materials are variable sized (for example plates). These items come in the Semi-finished/finished BOM as Raw Materials. Now whenver the requirement for SFG/FG is there MRP creates requirement for the variable sized items as well.
    We have defined the unit of measure for variable sized items as M2 (meter square). Stock for these items display total area present in the Storage Location. Since these items are cut and used it might be possible that the requirement generated by MRP can be theoretically satisfied against the available stock but cant be practically satisfied against the actual physical stock.
    For example in stock we have a sheet of 4m X 5m = 20 M2. The requirement from MRP comes to be 10 M2 but with dimensions 1mX10M. The stock shows available qtty as 20M2, required qtty as 10M2 and hence No PR is generated. But in actual we need to create a PR as dimensions are different.
    So to manage this we are giving MRP type of raw materials as ND (No planning). Therefore the system is not creating any PR (even if requirements exceed available stock) it only creates DepReq for the RM. Now we create manual PRs after studying the DepReq. But it seems that it is easy to loose track and difficult to know that for which DepReq the PRs are already created.
    Is there any way to relate the manual PRs to the DepReq created by MRP?
    If yes, then whenever DepReq will be converted to OrdRes will the above relation still be valid?
    Is there any other way of resolving/mapping the above scenario?
    Thanks
    Vineet

    We cant maintain separate material codes as the sheet required varies in size and shape. Right now I have come up with the following solution:
    1. SAP: Materials which are variable sized will have MRP Type: ND (No Planning)
    2. SAP: These items will be in the BOM of FG/SFG with their dimension details
    3. SAP: The requirements for the Variable Sized items will be created by the MRP although no planning will be done, i.e.  Dependent Requirement against sales order(through FG/SFG) will be created but no PRs/Planned Orders will be generated for these items
    4. SAP: List of Requirements in the form of Dependent Requirements and Order reservations can be seen through T-Code MD04.
    5. MANUAL: Manual PR is to be created against dependent requirements after checking the quantity and dimensions of the stocks available.
    6. MANUAL: Maintain an excel sheet to record the materials and PR numbers created for them with quantity and dimensions. Also keep a record of sales order number from which the requirement has come. Sales order number for a requirement can be viewed through the MD04 T-Code itself. Also the dimensions required can be easily seen by navigating from MD04 to the corresponding production order component list. (Instead of Excel an SAP Table can be developed to maintain the data, the only advantage would be central maintenance of data)
    7. For PRs created manually above dimensions will be  manually entered in PR as "PO Text".
    8. Whenver PRs are created manually the records maintained in point number 6 will have to be checked to avoid duplication of creation of PRs
    9. A separate column in excel sheet (refer point 6) can be maintained for the POs created against each PR.
    Dependent requirements will automatically be converted to Order Reservations in MD04 view once the Planned order of assembly is converted to a Production Order.
    10. Order reservations will automatically be removed from MD04 view once the GI of variable sized material is done to Production Orders.
    Do we have a better alternative to this?
    Thanks
    Geravine

  • Is having large no. of child in dense dimension ideal?

    we have a BSO application in which some of the dense dimension have over 1500 members in them, is it ideal?
    the hierarchy is not too flat but still there are some parents which have over 200 children.. i read somewhere that BSO throws error if the no. of children exceed 100.. is that statement true?

    It doesn't throw an error, it throws a 'warning', which you can ignore.  In a dense dimension it is unlikely be a performance problem (sparse is a bigger deal), but it might be hard for users to navigate.
    A dense dimension with 1500 members is not problem in itself.  Whether it's ideal or not is pretty hard to answer from what you've posted.  How did you decide which dimensions to make dense?  Do you actually have a performance problem or are you asking out of curiosity (not that there's anything wrong with that)?

  • Formula  variable  replacemnt path    quantity     as the dimension

    formula  variable  replacemnt path    quantity  as the dimension  then  what  are the changes in my report in quary designer

    Try to be clearer in your question, and I guess you'll have some help.

  • Ideal drive quantity in a RAID3

    I'm reinstalling my computer and will install CS6 update this week (when I receive it from Adobe). I took the opportunity to update my Asus P9X79WS and Areca 1880ix-16 (installed in PCI slot 6 with the most recent versions. I have 12x 500GB WD RE4 drives. I had them configured as 8x RAID3 for media, and 4x RAID0 for cache and pagefile. (using an SSD for boot drive)
    I was wondering if there was an ideal drive quantity in a RAID3 set. Example: 9 drives, 8 for data and 1 for parity. A byte being 8 bit... my thinking was if I separated the drives in a logical byte divisable fashion, it would perform slightly better. (other then the fact that there would be an extra drive in the set)
    Also, to all you Areaca geniuses out there. Are there optimal settings for me to use in setting up the card in the system configuration page?

    I think you have to balance the need to run cooler against running the fans so fast you wear out the motors quickly. In general, it's probably best, at least for prolonged periods, not to run them any higher than maybe ~400 rpms above the defaults. But that's just my own guess. I don't have any statistics on what fan speeds are ideal for attaining that balance.
    Then again, fans are much cheaper to replace than drives, logic boards, or power supplies.
    I have maybe 5 or 6 pre-sets, including the defaults. This is one setting I often use in summer, but I may sometimes go a bit higher in very hot weather. I also have a fan running at the back, which helps keep the internal temps lower and allows me to run the internal fans slower than I would otherwise. In extremely hot weather, it's pointless to blow hot air around faster. When it's like that I sleep the computer more often.
    These are the defaults on my 21.5

  • Quantity Conversion warnining: different dimensions, no calculations

    Hello BI experts,
    I have defined a quanity conversion type to convert any weight units to Kgs based on T006 table.
    source is from data record. target is fixed to KG.
    my record contain data in KG and GM ( gram )
    in the output KG records are displayed correct. But the gram records are displayed as 0.000
    with a warning message: Quantity unit of measures have different dimensions --> no calculations.
    Please advice.
    Regards,
    BWer

    Very trivial.. Was using units from different dimensions
    Message was edited by:
            BWer

  • Quantity Conversion from different dimensions

    Hi,
    I am facing one problem regarding the quantity conversion.
    In my report, I have a field for quantity which contains different units like Kg, L, etc
    Now, i want to convert these quantity into Kg -> MT and L -> KL. which I tried from RSUOM by creating the conversion type but it is not helping as the field contains different units.
    Please guide me how I achieve this.
    Thanks,
    Nitesh.....

    HI,
    It should work through RSUOM....What setting di dyou select?
    You should select input currency from data record...
    And then target currency you can select from variable...

  • What are the ideal dimensions

    Hi. I have just wasted a whole weekend making an animated menu for my DVD. I made it in Livetype and FCP with the dimensions of 1024 x 567 thinking this would be ok for a 16 by 9 pal menu. Unfortunately the animated captions once in DVD SP looked scaggy because I think that I should have made everything 720 x 576 (anamorphic). Is this the case?
    Considering I'll be encoding the menu seq in compressor when I've finished making it, what should the dimensions be when I originally start making it?

    No I think you should be OK with a 1024 x 576 starting point. You could then export that from FCP as a 720x576 Quicktime and encode it as 16x9 Anamorphic... the fact it looks scaggy could be for other reasons... Codec used to export Quicktime, encoding settings in Compressor etc

  • Query selected levels of multiple hierarchies of one dimension

    Hi to all.
    I have created through AWM 11 a customer dimension with two hierarchies as follows.
    SLM_HIER: All Customers -> Salesman -> Customer
    GEO_HIER: All Customers -> State -> City -> Customer
    I have also created a SALES_CUBE (measures: QUANTITY, VALUE, aggregation: SUM) that is dimensioned with Customer dim.
    I'm using OBIEE to query the OLAP engine (through the relational views that AWM created automatically). I have followed the OTN OBE tutorials.
    I would like to have the following query on the cube:
    Give me QUANTITY where SALESMAN=S1 and CITY in ('Athens','Rome').
    Is it possible to have such a query? As far as I understand there are no ready aggregated data for selected levels of both hierarchies.
    Thank you very much.
    Chris

    I think OBIEE would also give you your answer from OLAP.
    This query has filters defined from both the hierarchies and hence OBIEE would (should) automatically service this query from the highest common level b/w the hierarchies (in this case: base/leaf level - Customer). As a result of this, if CUST is your Customer dimension, OBIEE (at least, the older style of obiee modeling with olap) would introduce the security filter CUST_LEVEL = 'Customer'. Granularity of the resultset returned would be per individual Customer. 1 record per Customer satisfying the criteria SALESMAN='S1' and CITY in ('Athens','Rome').
    Ideally you should include the Cust Id, Quantity columns in your obiee answers report and use an internal answers object/view like a Pivot View to hide Customer details column and get a localized aggregation performed over the resultset returned from OLAP to get the consolidated Quantity. Answers table has data at Customer level, Answers Pivot can show the required result.
    Note1: The Cube cannot have this result pre-calculated since its a contradictory combination of filters across hierarchies. Level specific aggregate values calculated (or pre-calculated) in the cube for Salesman level (h1) would contain Customers from all cities (h2) and similarly City level (h2) Aggregates would contain Customers of all Salesmen (h1).
    Note2: I believe OBIEE modeling with OLAP suffers from some issues relating to multiple hierarchies (e.g: if you have filter from non-default hierarchy CITY in ('Athens','Rome') alone, i think it would still fetch the results from lowest common level Customer instead of from City level directly).
    HTH
    Shankar

  • How will u know that a dimension can b a lineitem Dim b4  loading into Cube

    Hi, Im new to this. My qury is how will u know that a dim will b a LineItem dimension bfore loading in to cube , are there anystandard to b followed. Ca u give me some realtime detailed scenarious.

    Hi,
         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.
    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.
    We recommend that you use DataStore objects, where possible, instead of InfoCubes for line items. See Creating DataStore Objects.
           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.
    Activities
    When creating dimensions in the InfoCube maintenance, flag the relevant dimension as a Line Item/ having High Cardinality.
    Define lots of small dimensions rather than a few large dimensions.
         The size of the dimension tables should account for less than 10% of the fact table.
         If the size of the dimension table amounts to more than 10% of the fact table, mark the dimension as a line item dimension.
    To attain good performance for a query on non-cumulative InfoCubes, you should take note of the following:
    Compression:
    Compress all requests in the non-cumulative InfoCube, or at least most of them.
    The performance of a query based on a non-cumulative InfoCube depends heavily on how the InfoCube is compressed. If you want to improve the performance of a query of this type, first check – in so far as this is possible - whether the data in the InfoCube should be compressed. You should always compress data when you are sure that the request affected will not need to be deleted from the InfoCube.
    Validity Table
    Use as few validity-determining characteristics as possible.
    The number and cardinality of the validity-determining characteristics heavily influences performance. Therefore, you should only define characteristics as validity-determining characteristics when it is really necessary.
    Time Restrictions in the Query
    As far as possible, restrict queries based on non-cumulative InfoCubes to time characteristics.
    The stricter the time-based restriction, the faster the query is generally executed, as the non-cumulative is reconstructed if the number of times is smaller.
    Time Drilldown in the Query
    If you no longer need the average, split a query on a non-cumulative InfoCube (which contains both key figures with LAST aggregation and key figures with AVERAGE aggregation) into two queries.
    With non-cumulative key figures with the exception aggregation LAST, the time characteristic included in the drilldown makes a difference to performance. If, for example, both Calendar Day and Calendar Month are included in the InfoCube, drilldown by month is faster than drilldown by day, because the number of times for which a non-cumulative has to be calculated is smaller.
    For the other types of exception aggregation (average, average weighted with factory calendar, minimum and maximum), this rule is not valid as in these cases, the data is always calculated on the level of the most detailed time characteristic first before exception aggregation is performed.
    Totals Rows
    Hide the totals row in the query when not required.
    Depending on the type of aggregation being used, the calculation of totals rows can be very time-consuming.
    When selecting MDC dimensions, proceed as follows:
            Select dimensions for which you often use restrictions in queries.
            Select dimensions with a low cardinality.
    The MDC dimension is created in the column with the dimension keys (DIMID). The number of different combinations in the dimension characteristics determines the cardinality. Therefore, select a dimension with either one, or few characteristics and with only a few different characteristic values.
    Line item dimensions are not usually suitable, as they normally have a characteristic with a high cardinality.
    If you specifically want to create an MDC dimension for a characteristic with a low cardinality, you can define this characteristic as a line item dimension in the InfoCube. This differs from the norm that line item dimensions contain characteristics with a very high cardinality. However, this has the advantage for multidimensional clustering that the fact table contains the SID values of the characteristic, in place of the dimension keys, and the database query can be restricted to these SID values.
            You cannot select more than three dimensions, including the time dimension.
            Assign sequence numbers, using the following criteria:
            Sort the dimensions according to how often they occur in queries (assign the lowest sequence number to the InfoObject that occurs most often in queries).
            Sort the dimensions according to selectivity (assign the lowest sequence number to the dimension with the most different data records).
    Note: At least one block is created for each value combination in the MDC dimension. This memory area is reserved independently of the number of data records that have the same value combination in the MDC dimension. If there is not a sufficient number of data records with the same value combinations to completely fill a block, the free memory remains unused. This is so that data records with a different value combination in the MDC dimension cannot be written to the block.
    If for each combination that exists in the InfoCube, only a few data records exist in the selected MDC dimension, most blocks have unused free memory. This means that the fact tables use an unnecessarily large amount of memory space. Performance of table queries also deteriorates, as many pages with not much information must be read.
    Example
    The size of a block depends on the PAGESIZE and the EXTENTSIZE of the tablespace. The standard PAGESIZE of the fact-table tablespace with the assigned data class DFACT is 16K. Up to Release SAP BW 3.5, the default EXTENTSIZE value was 16. As of Release SAP NetWeaver 2004s the new default EXTENTSIZE value is 2.
    With an EXTENTSIZE of 2 and a PAGESIZE of 16K the memory area is calculated as 2 x 16K = 32K, this is reserved for each block.
    The width of a data record depends on the number of dimensions and the number of key figures in the InfoCube. A dimension key field uses 4 bytes and a decimal key figure uses 9 bytes. If, for example an InfoCube has 3 standard dimensions, 7 customer dimensions and 30 decimal key figures, a data record needs 10 x 4 bytes + 30 x 9 bytes = 310 bytes. In a 32K block, 32768 bytes / 310 bytes could write 105 data records.
    If the time characteristic calendar month (0CALMONTH) and a customer dimension are selected as the MDC dimension for this InfoCube, at least 100 data records should exist for each InfoPackage, for each calendar month and for each dimension key of the customer dimension. This allows optimal use of the memory space in the F fact table. In the E fact table, this is valid for each calendar month and each dimension key of the customer dimension,dimension contains a characteristic whose value already uniquely determines the values of all other characteristics from a business-orientated viewpoint, then the dimension is named after this characteristic.
      The customer dimension could, for example, be made up of the customer number, the customer group and the levels of the customer hierarchy.
    The sales dimension could contain the characteristics ‘sales person’, ‘sales group’ and ‘sales office’.                                            
    The time dimension could be given using the characteristics ‘day’ (in the form YYYYMMDD), ‘week’ (in the form YYYY.WW), ‘month’ (in the form YYYY.MM), ‘year’ (in the form YYYY) and ‘period’ (in the form YYYY.PPP).
    Use
    When defining an InfoCube, characteristics for dimensions are grouped together to enable them to be stored in a star schema table (dimension table). The aforementioned business-orientated grouping can be the basis for this. With the aid of a simple foreign key dependency, dimensions are linked to one of the key fields of the fact table.
    When you create an InfoCube, the dimensions data package, time and unit are already defined by default. The data package dimension contains technical characteristics. Time characteristics and units are automatically assigned to the corresponding dimensions. When you activate the InfoCube, only those dimensions that contain InfoObjects are activated.
    From a technical viewpoint several characteristic values are mapped to an abstract dimension key (DIM ID), to which the values in the fact table refer. The characteristics chosen for an InfoCube are divided up among InfoCube-specific dimensions when creating the InfoCube.
    Also refer to the following for specific cases arising when defining dimensions:
    Line Item and High Cardinality
    The methods for setting and getting data from a named range use the separation between the description of the range and the data itself. Note that the sequence must be observed both in the range description (structure soi_range_list ) and in the data (structure soi_generic_table ). This means that you must list all data from the first range before you can insert data into the second range.
    Structure soi_range_list
    Field
    Type
    Description
    name
    C
    Name of the range
    rows
    C
    Number of rows
    columns
    C
    Number of columns
    code
    C
    Function in the range:
    SPREADSHEET->SPREADSHEET_CLEAR : Deletes range
    SPREADSHEET->SPREADSHEET_COLUMNSHIDE : Hides columns
    SPREADSHEET->SPREADSHEET_ROWSHIDE : Hides rows
    SPREADSHEET->SPREADSHEET_PROTECT : Range is protected
    SPREADSHEET->SPREADSHEET_UNPROTECT : Range is not protected
    SPREADSHEET->SPREADSHEET_COLUMNSSHOW : Columns are displayed.
    SPREADSHEET->SPREADSHEET_ROWSSHOW : Rows are displayed.
    SPREADSHEET->SPREADSHEET_INSERTALL : The entire table is inserted, regardless of the size of the area
    SPREADSHEET->SPREADSHEET_NEWRANGE : Creates a new range
    The name identifies the range in the worksheet. This is, in effect, the key with which you always access the range. The size of the range is always given in columns and rows.
    Some functions allow you to access a specific area in a worksheet. You can see from the table which functions are implemented.
    Description of Data Type soi_generic_table
    In this table, you can save data from the range and use the  Data Provider to transfer it to or retrieve it from the frontend. The data is transferred directly as a string with no type information.
    Structure soi_generic_table
    Field
    Type
    Description
    row
    C(4)
    Row
    column
    C(4)
    Column
    value
    C(256)
    Value
    The sequence of the data must correspond to the sequence of the range description, for example, range1 before range2 . The data table must then contain the data for the ranges in the sequence range1 range2 .
    Description of Data Type soi_format_table
    Use this table to specify the format of a range. The format consists of various attributes, all of which can be set in a single line. Each variable attribute corresponds to a column of the structure.
    To create a work area for this table, use the structure soi_format_item as a reference.
    The entry "-1" always indicates that the existing attribute value for the range should not be changed.
    Structure soi_format_table
    Field
    Type
    Description
    name
    C(256)
    Name of the range
    front
    I
    Font color (see color palette)
    back
    I
    Background color (see color palette)
    font
    C(256)
    Name of the font family. The following values are permitted:
    'Arial'
    'Courier New'
    'Times New Roman'
    size
    I
    Font size
    '-1' : Unchanged
    bold
    I
    '1' : Bold
    '0' : Normal
    '-1' : Unchanged
    italic
    I
    '1' : Italic
    '0' : Normal
    '-1' : Unchanged
    align
    I
    Alignment:
    '-1' : Unchanged
    '0' : Right-justified
    '1' : Centered
    '2' : Left-justified
    frametype
    I
    Control byte for setting the frame
    '-1' : Unchanged
    framecolor
    I
    Frame color (see color palette)
    '-1' : Unchanged
    currency
    C(3)
    ISO standard currency code
    number
    I
    Specifies the format of a cell in a range.
    1: Display as a simple number
    2: Scientific display
    3: Display as a percentage
    The control byte type contains the following bits. If a bit is set, its corresponding line is drawn. You can set the thickness of the line to one of four levels using bits 6 and 7.
    Bit
    Description
    0
    Sets the left margin
    1
    Sets the top margin
    2
    Sets the bottom margin
    3
    Sets the right margin
    4
    Horizontal line
    5
    Sets the left margin
    6
    Thickness
    7
    Thickness
    Description of Data Type soi_full_range_table
    Each line of a table with the type soi_full_range_table specifies the full definition of a range. The individual lines have the data type soi_full_range_item .
    Structure soi_full_range_table
    Field
    Type
    Description
    name
    C(128)
    Name of the range
    top
    I
    Top row of the range
    left
    I
    Leftmost column of the range
    rows
    I
    Number of rows in the range
    columns
    I
    Number of columns in the range
    sheets
    C(128)
    Worksheet on which the range is defined
    Description of Data Type soi_cell_table
    Each line of a table with the type soi_cell_table specifies the attributes of a range of cells. However, no range name is used. Instead, the cell area is defined by its starting position and the number of rows and columns it contains.The individual lines have the data type soi_cell_item .
    Structure soi_cell_table
    Field
    Type
    Description
    top
    I
    Top row of the range
    left
    I
    Leftmost column of the range
    rows
    I
    Number of rows in the range
    columns
    I
    Number of columns in the range
    front
    I
    Font color (see color palette)
    back
    I
    Background color (see color palette)
    font
    C(256)
    Font. The following are permitted:
    Arial
    Courier New
    Times Roman
    size
    I
    Font size
    Use -1 if the font size is to remain unchanged.
    bold
    I
    '1' : Bold
    '0' : Normal
    '-1' : Unchanged
    italic
    I
    '1' : Italic
    '0' : Normal
    '-1' : Unchanged
    align
    I
    Alignment:
    '-1' : Unchanged
    '0' : Right-justified
    '1' : Centered
    '2' : Left-justified
    frametype
    I
    Control byte for setting the frame
    '-1' : Unchanged
    framecolor
    I
    Frame color (see color palette)
    '-1' : Unchanged
    currency
    C(3)
    ISO standard currency code
    number
    I
    Specifies the format of a cell in a range.
    1: Display as a simple number
    2: Scientific display
    3: Display as a percentage
    decimals
    I
    Number of decimal places
    input
    I
    '0' : Input off
    '1' : Input on
    Description of Data Type soi_dimension_table
    You can use an internal table with this type to identify a range by specifying the coordinates of its top left-hand corner, its length, and its width. The lines of soi_dimension_table have the line type soi_dimension_item .
    Structure soi_dimension_item
    Field
    Type
    Decription
    top
    I
    Topmost row of the range
    left
    I
    Leftmost column of the range
    rows
    I
    Number of rows
    columns
    I
    Number of columns
    Term
    Definition
    Board
    A tabbed area in the workspace used to manipulate the model and its elements: Design board, Layout board and Source board.
    Characteristic
    A type of InfoObject in SAP BI systems that provides a classification such as company code, product, customer group, fiscal year, period, or region. Related to the OLAP-standard term dimension.
    Component
    A reusable model element, such as a UI component or a data service.
    Cube
    A set of data organized as a multidimensional structure defined according to dimensions and measures.
    Related SAP BI terms include InfoCube and query.
    Data binding
    A connection between two UI components (or between a web service and a UI component) that channels identical data from the output port of one UI component to the input port of the other UI component.
    Data flow
    The means by which data is channeled between a data service and connected UI components, or between two UI components whose connection was changed from Data binding to Data flow.
    Data mapping
    Connection between two model elements, describing, for example, the data that is input to an element or the fields that are output from another element.
    Data service
    Any function call, business object or query imported into the model. At runtime, the data service is called and returns results.
    Data store
    A central data container where data of a model can be temporarily stored for future use.
    Dimension
    In OLAP-standard systems:
    A collection of similar data which, together with other such collections, forms the structure of a cube. Typical dimensions include time, product, and geography. Each dimension may be organized into a basic parent-child hierarchy or, if supported by the data source, a hierarchy of levels.  For example, a geography dimension might include levels for continent, country, state, and city.
    The related term in SAP BI systems is characteristic.
    In SAP BI systems:
    A grouping of those evaluation groups (characteristics) that belong together under a common superordinate term.
    With the definition of an InfoCube, characteristics are grouped together into dimensions in order to store them in a star schema table (dimension table).
    Element
    A general term indicating any item used to create a model, including: components, connectors and operators.
    Enterprise service
    A Web service defined to perform functions of an SAP system. Web services are published to and stored within a repository.
    Field
    An element of a table that contains a single piece of data. Fields are organized into rows, which contain all the data relevant for one specific entry in the table.  In some databases, field is a synonym for column.
    Filter
    A set of criteria that restricts the set of records returned as the result of a query. With filters, you define which subset of data appears in the result set.
    Hierarchy
    A logical tree structure that organizes the members of a dimension into a parent-child relationship. If supported by the data source, the hierarchy consists of levels, where the top level is an aggregate of all members and each subsequent level has zero or more child members.
    InfoArea
    An element for grouping meta-objects in the Business Information Warehouse. Each InfoProvider is assigned to an InfoArea. The resulting hierarchy is displayed in the Administrator Workbench.
    InfoCube
    An SAP BI system that consists of a quantity of relational tables created according to the star schema: a large fact table in the center, with several dimension tables surrounding it. It provides a self-contained dataset which can be used for analysis and reporting.
    Similar to the OLAP-standard term cube.
    InfoObject
    A business evaluation object (for example, customer or quantity) in SAP BI systems. Types of InfoObjects include characteristics, key figures, units, time characteristics, and technical characteristics (such as request numbers).
    JDBC
    Java Database Connectivity, which provides an API that lets you access relational databases using the Java programming language. This enables connectivity to a wide range of SQL databases, and also provides access to tabular data sources such as spreadsheets or flat files. The BI JDBC Connector accesses data from JDBC-compliant systems.
    Join
    A relationship between two tables that produces a result set that combines their contents. You create a join by indicating how selected fields in one table are related to selected fields in the other table.
    Key figure
    A value or quantity in SAP BI systems. Related to the OLAP-standard term measure. You may also define calculated key figures, which are derived using a formula.
    Layer
    A collection of UI elements that are all visible at the same time at runtime.
    Level
    A set of nodes (members) in a tree hierarchy in supporting data sources that are at the same distance from the root of the tree. For example, in a geography hierarchy, the top level might be all places, the second level might be continents, the third level might be countries, and the fourth level might be cities.
    MDX
    Multidimensional Expressions, a query language used to retrieve and manipulate multidimensional data.
    Measure
    One category of values – usually numeric – used to define a cube. These values are derived from one or more columns in the cube's fact table and are the basis for aggregation and analysis.
    Related SAP BI terms include key figure and structure element.
    Member
    An element of a dimension that represents one or more occurrences of data. A member can be unique (it occurs only once) or non-unique (it may occur more than once in its dimension).  For example, in a geography dimension that includes cities in the US, the member Portland could be non-unique, since there is a city called Portland in the state of Oregon and in the state of Maine.
    In SAP BI systems, members are referred to as instances of characteristics.
    Model
    An object created in Storyboard. Models may contain packages, pages, iViews and any other model elements.
    Multidimensional data
    Data in dimensional models suitable for business analytics. In this documentation, we use the term multidimensional data synonymously with OLAP data.
    Navigation line
    A connection that provides event annotation, running between model layers. The source element raises the event that can be handled by the connected element. By default, a navigation line is curved.
    ODBO
    OLE DB for OLAP – Microsoft’s set of objects and interfaces that extend the ability of OLE DB to provide access to multidimensional data sources on the Windows platform. Providers of OLAP data can implement the interfaces described with OLE DB for OLAP to allow all OLAP clients to access their data. The BI ODBO Connector accesses data from ODBO-compliant systems.
    OLAP
    Online analytical processing – a system of organizing data in a multidimensional model that is suitable for decision support. SAP BI systems are OLAP systems.
    Operation
    A functionality provided by a Web service.
    Operator
    A mechanism used to manipulate data returned from the data service before it is displayed in the iView.
    Package
    A high-level “container”; it can contain any number of pages, iViews or other packages.
    Port
    A defined point of interface into and out of a component.
    Query
    In SAP BI systems, a collection of selected characteristics and key figures (InfoObjects) used together to analyze the data of an InfoProvider. A query always refers exactly to one InfoProvider, whereas you can define as many queries as you like for each InfoProvider.
    Query view
    In SAP BI systems, a view of a query after navigation, saved in an InfoCube. You can use this saved query view as a basis for data analysis and reporting.
    Relational database
    A repository for typically large amounts of information, structured in accordance with the relational model, in tables with columns. A relational database is created and administered by a relational database management system (RDBMS).
    Row
    A set of fields within a table that contains the data for one specific entry in the table. Each row in a given table has the same structure, predefined for a particular table. In some databases, row is a synonym for record.
    SAP Query
    A component that allows you to create custom reports without any ABAP programming knowledge. The BI SAP Query Connector uses SAP Query to access data from such SAP operational applications.
    Storyboard
    The Visual Composer client from which you design models.
    Table
    A set of rows, also known as a relation. The table is the central object of the relational model.
    Task panel
    A work area of the Visual Composer Storyboard desktop that displays a specific set of tools for building a model.
    Toolbar
    The horizontal row of buttons under the main menu (main toolbar) or the vertical row of buttons in the task panel (task-panel toolbar).
    Toolbox
    A set of board-specific tools that assist in performing tasks in the Visual Composer workspace.
    Value help
    The offering, typically in a pop-up dialog box, of possible valid values for an input field. Also known as input help, selection help, or F4 help.
    Web service
    An interface between two or more software applications that is implemented with the industry standards SOAP, WSDL and UDDI.
    Workspace
    The main grid area of Visual Composer that displays the model as it is built and modified. The workspace consists of boards.
    XMLA
    XML for Analysis, an XML-messaging-based protocol specified by Microsoft for exchanging analytical data between client applications and servers (for example, OLAP providers) using HTTP and SOAP as a service on the Web. The BI XMLA Connector accesses data from XMLA-compliant systems.
    Clustering allows you to save sorted data records in the fact table of an InfoCube. Data records with the same dimension keys are saved in the same extents (related database storage unit). This means that same data records are not spread across a large memory area and thereby reduces the number of extents that the system has to read when it accesses tables. This greatly accelerates read, write and delete access to the fact table.
    Prerequisites
    Currently the function is only supported by the database platform DB2 for Linux, UNIX, and Windows. You can use partitioning to improve the performance of other databases. For more information, see Partitioning.
    Features
    Two types of clustering are available: Index clustering and multidimensional clustering (MDC).
    Index Clustering
    Index clustering organizes the data records of a fact table according to the sort sequence of an index. Organization is linear and corresponds to the values of the index field.
    If a data record cannot be inserted in accordance with the sort sequence because the relevant extent is already full, the data record is inserted into an empty extent at the end of the table. For this reason, the system cannot guarantee that the sort sequence is always correct, particularly if you perform many insert and delete operations. Reorganizing the table restores the sort sequence and frees up memory space that is no longer required.
    The clustering index of an F fact table is, by default, the secondary index in the time dimension. The clustering index of an E fact table is, by default, the acting primary index (P index).
    As of release SAP BW 2.0, index clustering is standard for all InfoCubes and aggregates.
    Multidimensional Clustering (MDC)
    Multidimensional clustering organizes the data records of a fact table in accordance with one or more fields that you define freely. The selected fields are also marked as MDC dimensions. Only data records that have the same values in the MDC dimensions are saved in an extent. In the context of MDC, an extent is called a block. The system can always guarantee that the sort sequence is correct. Reorganizing the table is not necessary, even with many insert and delete operations.
    Block indexes from within the database, instead of the default secondary indexes, are created for the selected fields. Block indexes link to extents instead of data record numbers and are therefore much smaller. They save memory space and the system can search through them more quickly. This accelerates table requests that are restricted to these fields.
    You can select the key fields of the time dimension or any customer-defined dimensions of an InfoCube as an MDC dimension. You cannot select the key field of the package dimension; it is automatically added to the MDC dimensions in the F fact table.
    You can also select a time characteristic instead of the time dimension. In this case, the fact table has an extra field. This contains the SID values of the time characteristic. Currently only the time characteristics Calendar Month (0CALMONTH) and Fiscal Year/Period (0FISCPER) are supported. The time characteristic must be contained in the InfoCube. If you select the Fiscal Year/Period (0FISCPER) characteristic, a constant must be set for the Fiscal Year Variant (0FISCVARNT) characteristic.
    Clustering is applied to all the aggregates of the InfoCube. If an aggregate does not contain an MDC dimension of the InfoCube, or if all the InfoObjects of an MDC dimension are created as line item dimensions in the aggregate, the aggregates are clustered using the remaining MDC dimensions. Index clustering is used for the aggregate if the aggregate does not contain any MDC dimensions of the InfoCube, or if it only contains MDC dimensions.
    Multidimensional clustering was introduced in Release SAP NetWeaver 2004s and can be set up separately for each InfoCube.
    For procedures, see Definition of Clustering.
    Screen capture input to SAP Business Graphics must adhere to certain format rules in order to be recognized correctly.
    SAP Business Graphics assumes that your screen data resembles the basic SAP table structure. This structure is somewhat flexible, but the table must obey the format rules listed in this section.
    Restrictions on the Format of the Data
    If you use the screen capture facility to input graphics data, the input table can contain either a single list of values, or rows and columns. If the data is a single list, you can include the values themselves and labels for each value. If the data has rows and columns, you can include a label for each row, a label for each column, and the table values themselves.
    You cannot use the screen capture facility to input data in multiple tables. If you want to graph data occurring in multiple tables, you must write the input values to a file using ABAP programming tools. See SAP Graphics: Programming Interfaces for more information.
    Format Rules for Numerical Values
    Numerical values must obey the following rules:
    Within a numerical value, the screen capture recognizes only the minus sign (hyphen), the comma, and the decimal point (period) as legitimate punctuation. Exponential notation and other variations are not recognized.
    Note that the functions of the period and the comma in the English system are exactly opposite to their functions in some European systems. If your numbers are not being interpreted correctly, check with the system administrator to determine how these characters should be used.
    The minus sign must occur after the number, with no intervening spaces.
    All numbers in a row must be separated by spaces.
    A column of numbers is right-justified and identified by the position of its right-most character. Each number belonging to this column must have its right-most character in the correct position.
    If you have values partially or entirely out of alignment with the given right-most character position, they will not be interpreted as belonging to the proper column. In most cases, the screen capture program assumes these are values for an entirely new column.
    You may leave out values for a given row or column.
    Format Rules for Text Strings
    You can include labels in the table to name the rows and columns. You can also provide a title for the set of rows, for the set of columns, and for the graph as a whole.
    SAP Business Graphics does not accept more than 32 elements per dimension. As a result, you cannot have more than 32 rows or 32 columns in your table.
    Any string of characters not identifiable as a number is assumed to be a label. Labels may occur at the beginnings of a row, at the head of a column, as a title for the rows or columns, or as the graph main title. A non-numeric item placed in among the data values is ignored by the graphics program.
    A legitimate number occurring where a label should be is interpreted as a number. If you want to use labels that look like numbers, you must modify them to contain at least one non-numeric character.
    Placement of labels for row-names or column-names:
    Row-names can occur only at the beginning (left side) of a row.
    Column-names should line up above the columns they are heading, but do not necessarily need to begin in the same column. They should be separated by at least two spaces.
    If you don't adhere to these requirements, the screen capture program attempts to pick out the labels anyway. However, the results may not be what you expect. (Check the selection bars in the Selection view to see if your headers were correctly identified.)
    Placement of titles for rows or columns as a set:
    The title for the rows as a set should be placed directly above the column of row-names.
    The title for the columns as a set should occur directly above the first of the column-names, and begin in exactly the same position.
    The main title for the graph should occur in the very first line of the highlighted area. If you have more text there than just the title, the screen capture program attempts to pick out the string in the center of the line. The longest string in the center of the line separated from other text by double spaces is assumed to be the title.
    The maximum length for a text string cannot be specified exactly since this depends on the size of your window, the resolution of your monitor, and other factors.
    Many strings too long for a small window are displayed correctly when you enlarge the window to full-screen size. In general, you must experiment to find the optimal length for text strings.

  • Use one dimension to feed 2 other dimensions

    Is there a way to use one dimension to push data into two other dimensions using push logic?  The client has one dimension in App1 that is a combination of 2 dimensions in App2 ie the Costcenter dimension in App1 is a combination of Plant and Account in App2.
    Now they want to push data from App1 into App2 using the Costcenter dimension to populate the Plant and Account.
    I have Plant and Acct properties in the Costcenter dimension for mapping.
    I tried to use *Rename_dim CC= CC.Plant and *Rename_dim CC=CC.Acct but would get errors when validating the logic script.
    Any help would be greatly appreciated.

    Parameters
    COSTCENTER: 70101014
    When I test the logic using the logic debugger, I get the error:
    Validate member failed:
    70101014
    70101014
    70101014
    70101014 on COSTCENTER dimension
    When I run the logic thru data manager, the package is successful but the end of the detail status log is 'No records to process'
    The push logic should ideally take the Costcenter 70101014 from App1 and take the first 4 char (7010) and record to the Plant dimension in App2 then take the last 4 char (1014) and record to the Account dimension in App2
    Logic script:
    *DESTINATION_APP= APP2
    *RENAME_DIM CC = ACCOUNT
    *RENAME_DIM CC= PLANT
    *WHEN CATEGORY
    *IS "AOP"
    *REC(CC=CC.RPT_A,CC=CC.PLANT,CATEGORY=AOP)
    *ENDWHEN     
    *COMMIT

  • Aggregating Slowly Changing Dimension

    Hi All:
    I have a problem with whole lot of changes in the dimension values (SCD), need to create a view or stored procedure:
    Two Tables within the Oracle db are joined
    Tbl1: Store Summary consisting of Store ID, SUM(Sales Qty)
    Tbl2(View): Store View created which consists of Store ID, Name, Store_Latest_ID
    Join Relationship: Store_summary.Store_ID = Store_View.Store_ID
    If I’m pulling up the report its giving me this info
    Ex:
    Store ID: Name, Sales_Qty , Store_Latest_ID
    121, Kansas, $1200, 1101
    1101, Dallas, $1400, 1200
    1200, Irvine, $ 1800, Null
    141, Gering, $500, 1462
    1462, Scott, $1500, Null
    1346,Calif,$1500,0
    There is no effective date within the store view, but can be added if requested.
    Constraints in the Output:
    1)     If the Store Latest ID = 0 that means the store id is hasn’t been shifted (Ex: Store ID = 1346)
    2)     If the Store Latest ID = ‘XXXX’ then that replaces the old Store ID and the next records will be added to the db to the new Store ID ( Ex: 121 to 1101, 1101 to 1200, 141 to 1462)
    3)     Output Needed: Everything rolled up to the New Store ID irrespective of the # of records or within the view or store procedure whenever there is a Store Latest ID that should be assigned to the Store ID (Ex: the Max Latest Store ID Record for all the changing Store ID Values) and if the value of Latest Store ID is 0 then no change of the record.
    I need the output to look like
    Store ID: Name, Sales_Qty , Store_Latest_ID
    1200,Irvine,$4400,Null
    1462,Scott,$2000,Null
    1346,Calif,$1500,Null or 0
    The Query I wrote for the view creation:
    Select ss.Store_ID, ss.Sales_Qty, 0 as Store_Latest_ID
    From Store_Summary ss, Store_Details sd
    Where ss.Store_ID=sd.Store_ID and sd.Store_Latest_ID is null
    union
    Select sd.Store_Latest_ID, ss.Sales_Qty, null
    From Store_Summary ss, Store_Details sd
    Where ss.Store_ID=sd.Store_Latest_ID and sd.Store_Latest_ID is not null
    And placing a join to the created view to Store Summary ended up getting the aggreagation values without rolling up and also the Store ID's which are not having latest ids are ending up with a value 0 and the ss quantity aggregated, and if there are changes within store id for more than two times then its not aggreagating the ss quatity to the latest and also its not giving the store name of the latest store id.
    I need help to create a view or stored procedure
    Please let me know if you have any questions, Thanks.
    Any suggestions would be really Grateful.
    Thanks
    Vamsi

    Hi
    Please see the following example
    ID- Name -Dependants
    100 - Tom - 5
    101 - Rick -2
    102 - Sunil -2
    See the above contents...assume the ID represents employee ID and the dependants include parents, spouse and kids....
    After sometime, dependants may increase over a period of time but noone is sure when exactly it will increase.....assume in case of a single get married and increase in dependants
    So the attributes of the Employee had a slow chance of changing over the time
    This kind of dimensions are called slowly changing dimensions
    Regards
    N Ganesh

Maybe you are looking for