> > 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. > > 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.
_______________________________________________ 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
