1.1 problem description
The target is to provide a dimension and a fact table through the capabilities of IBI to the end user. The end user should be able to make a drilldown through the complete hierarchy down to the leaf nodes.

The starting point is a dimension with the following characteristics:
- unbalanced dynamic hierarchy
- the lower levels consist of not summable kpi’s
- redundant sections in the tree

The following picture shows an example tree. Right beside a node an operator is drawned. The operator describes the rule how to build the node in scope out of the related child nodes.

The dotted line shows a special relation. The referenced child node is assigned to two parent nodes.
The kpi representing the root node of the section is reused.





The following sections describe the characteristic and the issues in more detail.
1.2 dynamic tree structure and unbalanced hierarchies
The structure of the tree is dynamic. It is possible to add new levels and assign new relations through a configuration task.
The tree represents a business formula. That’s the reason why the tree isn’t balanced and the operators are not determined through a specific level. Every path down the tree has its own structure and operators.

It is also not possible to name the different levels in an unique manner like in a time dimension (year, month, day).

The following issues have to be detected:
- how can IBI handle a dynamic number of levels in the hierarchy?
- how can IBI handle the different operators in a level?
- how to model and handle the unbalanced hierarchies?

1.3 redundant tree sections
There is a requirement to reuse calculated kpi’s.
In the tree these kpi’s are represented as tree sections.
The root node of such a section can have more than one parent. So it is not a pure tree anymore.

The following issues have to be detected:
- is IBI capable to handle such a data structure?
- are there requirements how to present such a data structure to IBI?

1.4 non summable kpi‘s
For every node there is an operator defined. These operator defines the calculation method of the node of interest out of the child nodes.
Not all of these operators are summable.
But we want these nodes to be elements of a dimension, to get the information how this node is composed and to make a drill down to get the constructing numbers.

The following issues have to be detected:
- is it possible to combine summable and not summable kpi’s in one dimension?
- is it possible to make a drill down down to the leaf nodes?
- can this drill down show the constructing numbers of the child nodes also when there is a e.g. division-operator?

This message has been edited. Last edited by: <Emily McAllister>,

You want us to work on your RFI proposal?

Yes, why not, if You can help.
You could be payed by IB-Switzerland, ask Giuseppe Scattarreggia, the local Consulting Leader.

If you want help with this, perhaps you should edit your post so that it's a bit less unreadable?

More readable (sorry for that):

1.1 problem description
The target is to provide a dimension and a fact table through the capabilities of IBI to the end user. The end user should be able to make a drilldown through the complete hierarchy down to the leaf nodes.

The starting point is a dimension with the following characteristics:
- unbalanced dynamic hierarchy
- the lower levels consist of not summable kpi’s
- redundant sections in the tree

The following picture shows an example tree. Right beside a node an operator is drawned. The operator describes the rule how to build the node in scope out of the related child nodes.

The dotted line shows a special relation. The referenced child node is assigned to two parent nodes.
The kpi representing the root node of the section is reused.




The tree represents a business formula.

The following sections describe the characteristic and the issues in more detail.
1.2 dynamic tree structure and unbalanced hierarchies
The structure of the tree is dynamic. It is possible to add new levels and assign new relations through a configuration task.
The tree represents a business formula. That’s the reason why the tree isn’t balanced and the operators are not determined through a specific level. Every path down the tree has its own structure and operators.

It is also not possible to name the different levels in an unique manner like in a time dimension (year, month, day).

The following issues have to be detected:
- how can IBI handle a dynamic number of levels in the hierarchy?
- how can IBI handle the different operators in a level?
- how to model and handle the unbalanced hierarchies?

1.3 redundant tree sections
There is a requirement to reuse calculated kpi’s.
In the tree these kpi’s are represented as tree sections.
The root node of such a section can have more than one parent. So it is not a pure tree anymore.

The following issues have to be detected:
- is IBI capable to handle such a data structure?
- are there requirements how to present such a data structure to IBI?

1.4 non summable kpi‘s
For every node there is an operator defined. These operator defines the calculation method of the node of interest out of the child nodes.
Not all of these operators are summable.
But we want these nodes to be elements of a dimension, to get the information how this node is composed and to make a drill down to get the constructing numbers.

The following issues have to be detected:
- is it possible to combine summable and not summable kpi’s in one dimension?
- is it possible to make a drill down down to the leaf nodes?
- can this drill down show the constructing numbers of the child nodes also when there is a e.g. division-operator?

TL;DNR

From a glance, it seems to me that your best option is to put that stuff in a database and let WebFOCUS (I assume that's what you mean when you say "IBI") just query that.

If that doesn't answer your question, perhaps you should put it rather more concise. At this point it's not clear to me at least what your question boils down to. Perhaps it would already help if you'd add the picture (use an outside public source to store it) that you're referencing.