dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

On Fri, Oct 30, 2009 at 3:19 PM, Ola Hodne Titlestad <olatitle@xxxxxxxxx>wrote:

> 2009/10/30 Jason Pickering <jason.p.pickering@xxxxxxxxx>
>
> Could some one remind me once again what the point of having a
>> category option in two separate categories is? is there a use case
>> here? It does not seem totally obvious, but maybe I am missing
>> something.
>>
>>
> I'll give it a try:
>
> Here are two categorycombos and their options:
>
> CategoryCombo EPI Age Group + Gender
> Category1: EPI Age Group
> Options: (<1, >1)
> Category2: Gender
> Options (Female, Male)
>
> CategoryCombo Morbidity Age Group + Gender
> Category1: Morbidity Age Group
> Options: (<1, 1-5, 5-15, >15)
> Category2: Gender
> Options (Female, Male)
>
> The categoryoption name  '<1' is used in two different categories.
>
> That said, I am not sure how useful it is to programatically know that <1
> in Morbidity is the same as <1 in EPI (in the sense that you will use it in
> data analysis), even though they share the same name.
>
> I find it useful to be able to do analysis on a random set of data elements
> across multiple dimensions (cetegories) independent of their categorycombos,
> e.g. in this example look at the gender dimenion across data elements from
> EPI and Morbidity. (although gender in EPI might not be a good real life
> example of something useful)
>
> BUT I am not sure we need to support analysing data elements across a
> random set of categoryoptions independent of their categories, as in looking
> at the categoryoption '<1' across EPI and Morbidity data elements. I find
> this to complex and far fetched to support.
>
> As stated in that multidimensional datamart blueprint, we need to support
> e.g. report tables where the user can pick categoryoptions to use as
> columns, but I guess then we need to restrict it to a selection of
> categoryoptions within 1 categorycombo.
>
> What I am saying is that although the same name is used in for options in
> two different categories it might not be necessary to actually link these
> two categoryoptions to the same master object or whatever you would call it.
> This means that the name is not the unique identifier for categoryoptions,
> but rather the name + the category it belongs to.
>
> Does this make sense?
>
> Ola
> -----------
>

To clarify: We are not reverting the 1-n association between category and
category option. We are just putting back the uniqueness constraint on
category option name to be backwards compatible. If we did not have to cater
for that it wouldn't be necessary to have that name constraint.