On 7 December 2010 11:08, Ola Hodne Titlestad <[email protected]> wrote:
> On 7 December 2010 09:02, Knut Staring <[email protected]> wrote: > >> On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen <[email protected]> >> wrote: >> > Dear Johan, >> > Thank you for your suggestions. Please scroll down to see my mail >> > >> > >> > >> > On Tue, Dec 7, 2010 at 1:59 AM, <[email protected]> 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 > --------- > > sorry, hadn't seen Bob's post when I wrote this. > > >> 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 >> > >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
