How can we improve Jedox Software?

Aggregation based on attribute values

88 votes
Vote
Sign in
Signed in as (Sign out)
You have left! (?) (thinking…)
Robert Tischler shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

4 comments

Sign in
Signed in as (Sign out)
Submitting...
  • Jens Consör commented  ·   ·  Flag as inappropriate

    The comment entered by Admin is not valid. I cannot see how this is covered by Semi Additive Measures (AVG, Last/First Child).

    Good example is real estate:
    reporting across different houses which you rent to persons -> Show monthly payments.

    Each house has a year of construction (Baujahr) and a postal code (PLZ).
    It would be great to be able to show payments by year of construction and postal Code
    without defining/updating hierarchies... in a kind of virtual dimension as already proposed.
    Hierarchies from one dimension for example cannot be combined in a matrix in paste view (one on rows and another on columns)

    Thanks!

  • Alexander Küpper commented  ·   ·  Flag as inappropriate

    I would also suggest to solve the request by attribute driven hierarchies. From my point of view there are two possibilities:

    1. Have an ETL-Load create the hierarchies dynamically based on defined attribute-structures. Example: customer elements have attributes 'Country', 'Region' and 'segment' and two hierarchical structures can be defined: (a) Country | Region | Customer and (b) Segment | Customer

    2. (preffered) the dimension structure is configured as in 1., but don't have to be physically loaded into the dimension. Rather they are computed virtually and could be even edited in the Modeller (as a hierarchy of attributes similar to consolidating elements to a hierarchy. Thereby each root defines the virtual dimensions name)

    In our opinion, this would boost flexibility in analysis of all customers that have few core dimensions with a lot of attributes that they want to explore. As of today in Jedox I have to either create all hierarchies or even create seperate dimensions from the start, giving less flexibility for later analysis and unneccesarily slowing down the system.

    virtual dimension 2.0 would then allow to decide wheter virtual dimensions can be pivoted against other virtual dimensions of the same physical dimension. In my earlier example that would allow to pivot customer by region vs. segments without having to implement two different dimensions.

Feedback and Knowledge Base