dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi

On the back of Jason and others comments, I've reached the conclusion that
we cannot really live with the MD model the way it is.  Whereas I think it
is (just about) workable there are some serious optimizations we can and
should do.  I am going to put my other work back a day or two and propose
some changes in a branch.

I think central to the inefficiency is the many-many relation between
categories and categoryoptions.  This strikes me as illogical as well as
being cumbersome in the UI.  Do we really want to be able to make categories
with options like {'0<5','6-10','Male','Out of stock','35-40'}.  Reducing
the relation between categories and category options to 1-n cuts two tables,
should make sql queries more efficient and grokkable and also matches other
models such as sdmx better.

The other possiible inefficiency is the dimensionset.  It can be useful in
some contexts but I'm guessing that when querying the data (which we want to
be fast) it is not relevant.  A dataelement can have dimensions.  The fact
that some dataelements have the same combinations of dimensions is very
useful to know for some purposes, but it should be possible to get from the
dataelement to the dimension directly.

On the other side of the road is the hierarchical dimensionality idea I see
Ola and Jason have been discussing, where dimensions are composed (perhaps
post-facto) of uni-dimensional dataelements rather than decomposed into
pre-structured dimensional elements.  I suspect that:
1.  we need both; and
2.  from the API, user and reporting perspective they should look the same
(ie a dataelement can have dimensions - how they come about should not be a
concern at the end point).

I'll try out some of these ideas and point you to the branch.

Regards
Bob

2009/9/29 Lars Helge Øverland <larshelge@xxxxxxxxx>

>
>
>> Thanks for the explanations Jason. The multidimensional model is quite
>> complicated, is poorly documented, and as you say is DHIS-centric in the way
>> that it is built around the DHIS notion of a Data Element.
>>
>>
> Could we assemble and put some of the text being written on the list to
> docbook?
>
>
>> That said, and I think Jason already has made a strong case for this, also
>> in a 100% DHIS2 scenario you will need more flexibility in defining
>> dimensions to your data than what categories can provide. Being able to
>> define data dimensions independent of data collection is powerful and should
>> be supported in a better way than what data element groups provide today.
>> Given that we already have the orgunit group set code in place I would
>> assume that adding group sets to data elements could be a relatively
>> straight forward thing to do (but then again, I am not the programmer...).
>>
>
> I don't see any implications in adding this to the system, it won't require
> changes to the existing model as the association goes from the groupset to
> the groups. We can prioritize this for the 2.0.3 release.
>
>
> _______________________________________________
> 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
>
>