Input in a cube with continuous time dimension
Posted: Sat Sep 12, 2020 12:23 am
I am investigating PAW and data input in a cube that contains a continuous time dimension.
This investigation is actually broader in that it will pertain to any data input in a cube where we cross 2 hierarchies of the same dimension.
The case is as follows: the dimension month contains 36 level 0 elements (2018-2019-2020 and each time their 12 children).
There is a hierarchy for the years (2018 is the sum of 2018_01, 2018_02, 2018_03, ..., 2018_12, and so on).
There is a hierarchy for the months (01 for January is the sum of 2018_01, 2018_02, 2018_03, and so on).
If we cross both hierarchies, input can be done in a grid, even though we only have 1 dimension:
This works fine. Every cell in the grid (36 cells) is each time the result of only 1 valid underlying cell, even though 36 cells are underneath it: 1 combination is valid.
But by choosing this approach, C-level rules are out of the question. We get into a conflict between data input and a rules-calculation:
This means that the user is restricted to a view at level 0, 36 periods in the rows, or in the columns, but not 3*12 or 12*3.
Likewise, prohibiting data spreading is not possible anymore. Once we do that (it's a server-wide setting, the user cannot do data input any more !
I haven't looked at security yet.
This investigation is actually broader in that it will pertain to any data input in a cube where we cross 2 hierarchies of the same dimension.
The case is as follows: the dimension month contains 36 level 0 elements (2018-2019-2020 and each time their 12 children).
There is a hierarchy for the years (2018 is the sum of 2018_01, 2018_02, 2018_03, ..., 2018_12, and so on).
There is a hierarchy for the months (01 for January is the sum of 2018_01, 2018_02, 2018_03, and so on).
If we cross both hierarchies, input can be done in a grid, even though we only have 1 dimension:
This works fine. Every cell in the grid (36 cells) is each time the result of only 1 valid underlying cell, even though 36 cells are underneath it: 1 combination is valid.
But by choosing this approach, C-level rules are out of the question. We get into a conflict between data input and a rules-calculation:
This means that the user is restricted to a view at level 0, 36 periods in the rows, or in the columns, but not 3*12 or 12*3.
Likewise, prohibiting data spreading is not possible anymore. Once we do that (it's a server-wide setting, the user cannot do data input any more !
I haven't looked at security yet.