dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olatitle@xxxxxxxxx>]

2009/10/30 Jason Pickering <jason.p.pickering@xxxxxxxxx>

> OK, I took a walk around the block to think about this a bit more. I
> think it does, make sense, sort of. Lets look at  "Total", which might
> be defined as a calculated data element, say composed of different age
> groups. But the "Total" in this category, would not be the same as the
> "Total" that might be defined in a different category, or would it?
>
>
I thought the whole point of the category/categoryoption/categorycombo model
was that the total would be the data element itself without any
categoryoption? The "total" should then not be defined as one of the
options, but be always be derived from the sum of all the options.

Your example Jason is from a 1.4 design point of view where you are not
using this model, but normally need calculated data elements to get to a
total (since the categoryoptions are part of the data element names). With
the new data element group set model I guess you can derive the total for
e.g.  "Malaria new cases OPD" e.g. by filtering on the data element group
"Malaria" in the group set "Diseases" plus the group called "New cases" in
the group set "Patient status" and then simply sum up all the data elements
in the two groups sets "Gender" and "Morbidity age group". Would't such an
approach give you the totals you need?

As in exactly how we could accommodate that within DHIS2 e.g in a report
table GUI I am not sure. Seems complicated and something for an OLAP tool to
take care of.

Ola
-----------

 Having a single categoryoption "Total" would allow one to slice out
> particular groups of dimensional elements, which is a fairly common
> operation as Ola mentions, with a single filter statement. Otherwise,
> you would need to collect all of the "Total"s for different categories
> through another table and perform an inner join, as opposed to a
> filter. For multiple category options, I guess there would need to be
> a decision made whether to perform an inner join or loop through a
> filter, but I guess an inner join would actually be better for either
> one or many category options (have not looked at the code). If the
> uniqueness contraint is not there, the user would need to select in a
> separate step to select all "Total"s and then perform an inner join,
> as there would be no intrinsic relationship between "Total" in the
> "Age" category and the "Total" in the "Gender" category. This might be
> very tedious if there are many categories to select from. Having
> multiple category options with the same name does not make sense in
> this case, and I think this is what everyone is saying?
>
>
>
> Obviously  there should not be two category options called "Total" to
> be within a single category/data element group set. However,I am not
> sure I understand completely your point Ola. To me, the use case you
> describe is very typical. "Give me all data for the under 1 age
> group", "Give me all data on in patient discharges". Having to define
> multiple "under 1" and "IPD" for each category seems to be very
> inefficient, as well as painful.
>
> So, I guess maybe I am answering my own mail...I think.
>
>
>
>
> 2009/10/30 Lars Helge Øverland <larshelge@xxxxxxxxx>:
> >
> >
> > On Fri, Oct 30, 2009 at 2:43 PM, Jason Pickering
> > <jason.p.pickering@xxxxxxxxx> wrote:
> >>
> >> 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.
> >>
> >
> > It might be that there are none. This could be useful in the sense that
> if
> > nobody asks for removing the constraint - we won't.
> >
> >
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> More help   : https://help.launchpad.net/ListHelp
>