dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olati@xxxxxxxxxx>]

On 7 December 2010 09:02, Knut Staring <knutst@xxxxxxxxx> wrote:

> On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen <thuy.hispvietnam@xxxxxxxxx>
> wrote:
> > Dear Johan,
> > Thank you for your suggestions. Please scroll down to see my mail
> >
> >
> >
> > On Tue, Dec 7, 2010 at 1:59 AM, <johansa@xxxxxxxxxx> wrote:
> >>
> >> Dear Thuy,
> >>
> >> I'm not very familiar with the requirements in Sri Lanka, but I have a
> few
> >> general comments. First, the categories and combinations should be used
> >> when we want to aggregate them into a data element that is a natural
> total
> >> of these categories. For stock, this is usually not the case, as we do
> not
> >> want to add start balance, received, issued, and monthly requirement (in
> >> this case).
> >
> > About the total meaning of categories and categories options. I got the
> > lesson from my mistake in Vietnam. So I didn't want to repeat again by
> > explanation people here. But again because of the instant benefit of
> > category data elements such as the defaul entry form will generate
> > automatically with good form which DHIS provided. And the shorting of
> > creating data elements,... So the person who do this project decided to
> use
> > categories for this report as well as other reports for equipments like
> > beds, tables,... I knew it is wrong for the meaning of categories which
> > developers in DHIS wish to use. But I don't know serious reason for
> defense
> > on this. That's why I consult you to know what will happen in the future
> > when data base become huge if we use category options like this for data
> > elements? Is it affecting to retrieving information later?
>
> Hi Thuy,
>
> I personally think one has to weight these things against each other.
> I understand very well the desire to have nice autogenerated forms,
> and I don't really see the big problem with using categories this way
> AS LONG AS one bears in mind that the total will not work. I think the
> major downside to doing it like this is that Pivot tables will not
> work well on these dataelements, since the whole point of pivot tables
> is to easily sum up - and if some of the sums are meaningless, that
> restricts the usefulness of the pivot tables.
>
>
I have previously been very defensive of the "must add up to a total" rule,
but over the last months I have changed my mind here.
There are some use cases, and we keep seeing more and more of these,
especially with stock, where you will quickly end up with 500+ data elements
in a flat data element model for just one form, which might be more than all
the other data elements together. Your list of data elements will get
polluted, all browsing that involves data elements will be more difficult.
And of course being able to automatically get that nice tabular form is a
major bonus, although I tend to think of the very long data element lists as
a worse effect of this than the extra one-off work of designing the form.

I have discussed this with Lars in the past and I think many of us agree
that the current use of the model is not ideal, we should not tie the model
this closely to the presentation layer and we have said before on this list
that we should look at a better data entry form model in the future. But
this will take time and is not realistic to get in place for another 6
months at least.

While waiting for a better model I agree with Knut that we can use the
categories to reduce the number of data elements and to get the
auto-generated form even though the options don't add up to a meaningful
total. Of course then we must make sure that this total is never used in a
report, validation rule, or indicator expression etc. One way to do this is
to add a property on the category that says "non-aggregatable" or similar,
to indicate that we never want to use the aggregated total. This way we can
filter away the totals in indicator formula editors etc. (Lars implemented
the use of totals there yesterday).

Pivot tables is another issue I guess, since we cannot control the
aggregation in the same way, since the users can zoom in and out as they
want. But if we always provide the catoptioncombo field in the pivot tables,
as we do today, the users will easily see, if they want, the raw data below
the total. There are other dimensions in the pivot table that are not
aggregatable (I think Lars googled this word and found it to be existing..),
like DataElement and Indicator, and the totals for these do not make sense
either. Of course the pivots will be a lot better and easier to use when the
totals for data elements actually are useful, so that we don't have to show
all the options all the time. We can create filters so that stock data (or
non-aggregatable data) is not part of the core pivot tables and create
separate special tables for these, or just trust that the users will do this
filtering themselves, and understand what the totals mean and not mean.

Ola
---------



> It would be nice if it were possible to easily generate good looking
> forms without violating the semantics of the aggregation model, though
> I suppose that would require a decoupling of the form section
> generating machinery from the data element model. One would then be
> able to assign categorycombos to a section, but also group data
> elements in sections external to the disaggregation model.
>
> Knut
>