dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2009/3/20 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>
>>
>> It seems to me that adding a PeriodType to the DataElement is
>> definitely redundant.
>>
>> DataElement should always be a member of at least one DataSet - and
>> there is already be an (implicit) constraint that DataElements of a
>> DataSet will be of the same PeriodType.
>>
>> What is probably required (if it doesn't yet exist) is an application
>> enforced constraint that a DataElement can only be a member of
>> different DataSets which share the same PeriodType.  Given that some
>> of those do exist (the bad practice) then it is considerably better to
>> rename (and re-id) the dataElement.  This will anyway be necessary if
>> DataElements become directly associated with PeriodType.
>
> Yes but this is exactly why we want to do this - create the mentioned
> application enforced constraint. Firstly there is no constraint saying a
> DataElement MUST be a member of a DataSet. Secondly we are making things a
> whole lot easier by making this association explicit; think of assigning
> data elements to datasets (are the dataelement already a member of another
> DataSet with a different PeriodType?), gap analysis, regression analysis,
> datamart (which PeriodType is the DataElement associated with?), alignment
> with the lecacy DHIS 1.4 model (how do we manage import?).

> I agree that there is a slight redundancy associated with this, but I think
> what we gain in regard to simplicity and performance exceeds the minor cost
> of this association.

There is not much to be gained in terms of simplicity if you drive the
functionality down to the data model API.  The way you make the
relationship explicit is to provide the DataElement class with a
method called getPeriodType().  The detail of how it implements that
is invisible to the user of the method.  True the implementation of
getPeriodType() will be slightly less efficient, but how many times
will it be called in a data intensive operation anyway?  In most cases
you could probably call it once in the constructor and reuse the
result as much as you can.

I'm thinking that DataElements which are not members of any DataSet
should probably be considered as "inactive" or not yet assigned in the
application (I might be wrong - see below).  Assigning a DataElement
to a DataSet would involve calling getPeriodType() on it.  If it
returns NULL then the assignment will always succeed.  If it returns a
PeriodType then it will succeed if the DataSet you are assigning to is
of the same PeriodType():

DataSet::assignDataElement(DataElement de)
{
   PeriodType pt=de.getPeriodType();
   if (pt != NULL && pt!=this.getPeriodType()) {
       throw new PeriodTypeMisMatch()
   }

   etc ...
}

Of course all of this does fall apart if you are saying that it is
acceptable that active DataElements can indeed be legitimately not
part of any DataSet.  Is this the case or is it to be considered a
data integrity problem?

My fear of introducing redundancy in the datamodel is driven more by
the fear of introducing accidental complexity.  You can always make a
relational database more efficient (and arguably simpler) by removing
the relations or just using a flat file, but it is rarely a good idea.
 If what you really require is a getPeriod() method on a DataElement
and that information can already be obtained from the current schema
then I think it is better not to duplicate in the schema.

Forgive me if I am misinterpreting the rationale of having DataSets.
Its possible :-)

Regards
Bob


>
>>
>> I think the only other thing which is achieved by associating the
>> PeriodType with the DataElement is that it would allow for DataSets
>> which a heterogenous mix of DataElement PeriodTypes, which I don't
>> think is a design goal.
>
> This is definitely something we don't want to allow.
>
>