Perhaps it is a bad example but it raises a good point, and we might should move this to a new thread if it continues to balloon.
My understanding was the category options would be used for data entry. This is not really an issue about 1.4, it is really an issue about whether people will enter totals or not. There is nothing to prevent people from defining a category , Gender, with three (or more) options, "Male" "Female" and "Total", and it may be necessary. Let me explain. On the paper tools used here in Zambia, there is a separate column "Total" which is the sum of three age groups (Under 1, 1-5 and Over 5). If I was going to implement the multidimensional data elements here, if I wanted to replicate the paper tool exactly, I would need a separate column for totals. This is what we have now, and it serves a good purpose, as the data entry personnel can see if the totals provided by the facility actually match the calculated totals. No idea if this is how the categories work in DHIS2. But from the analysis standpoint, it would seem that you would need some calculated data element as well that would calculate the total from the multidimensional components of the data element, unless as you say, you are going to rely on OLAP or PivotTables to always do this aggregation for you. I would think that actually having the ability to persist and store the data value, as a calculated data element (Save calculated) and assign it a Category option of "Total" (which might be implicit anyway in the system) would make sense, since you might need it directly in a report or something and do not want to have to revert to OLAP or custom SQL to get this. But again, I am looking at this from the perspective of a bunch of data elements which do not use category options. You would get the totals as you state, but only by using OLAP. What about if I want to create an Excel report with only Totals? Now if the new model will automatically give me the totals from the component dimensions, great, but I did not see this in the blueprint. I was assuming that I would need explicitly define a separate, calculated element for this. Regards, Jason On Fri, Oct 30, 2009 at 5:34 PM, Ola Hodne Titlestad <olati...@gmail.com> wrote: > 2009/10/30 Jason Pickering <jason.p.picker...@gmail.com> >> >> 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 <larshe...@gmail.com>: >> > >> > >> > On Fri, Oct 30, 2009 at 2:43 PM, Jason Pickering >> > <jason.p.picker...@gmail.com> 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 >> Post to : dhis2-devs@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~dhis2-devs >> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
