Re: Structuring attributed data-fields

Angus Monro wrote:
> OK. What would be your approach to incorporating the meta-data
> explicitly into the model? It seems to be that we need an entity
> that aggregates the attributes of interest i.e.
> A ManagedDatumAttributes consists of
> - date/time when most recently updated;
> - audience (public, staff, ops, ...).
> But then would I draw an association between this and *every* datum
> in the model?

I would let the other DatumAttribute classes be a subclass of ManagedDatumAttribute. Somehow I would expect that 'audience' is something that depends upon the "type of ManagedDatumAttribute". Are there maybe other attributes that depend upon the type of MDA of the attribute?

> [If I do, then I can implement this by either the original "fat"
> table approach or the other original approach of having an attributes
> table containing primary-key fields that specify the field name and
> record key of the managed value datum].

I think the first suggestion is probably the most efficient and since it's a one-to-one relation not even against any normal form.

> Actually, the cleanest model I can think of is to take a template
> approach:
> A ManagedDatum<T> consists of
> - a value of type T (accessed via a getValue()/setValue() pair)
> - date/time when most recently updated (accessed via
> getTimeOfLastUpdate(), but changed only by the setValue()
> method).
> - audience (public, staff, ops, ...).

The semantics of inheritance and templates is both well defined as far as I know. So I would use whatever you (and the people who should understand your model) are more comfortable with. I would use inheritance because it smells less of implementation :-) but that's just me.

> The rest of the model would then be defined in terms of the various
> bindings of this template e.g.
> A Flight has various attributes, including:
> departurePort: ManagedDatum<Port>,
> arrivalPort: ManagedDatum<Port>,
> etd: ManagedDatum<DateTime>,
> eta: ManagedDatum<DateTime>,
> status: ManagedDatum<FlightStatus> {FlightStatus in Set {boarding,
> locked-up, en-route, landed, ...} }
> [It seems to me that this approach would then map to having a table
> for each type T (with 4 fields: datum id, value:T, updateTime,
> audience), and the rest of the schema merely has foreign key refs to
> those tables' datum id fields].

Not neccessarily. Like I said, it's a one-to-one relationship so you can integrate the two tables. Although you might consider leaving them apart because the relationship may one day become a one-to-many relationship. But for isa-relationships such as this one this is not very likely.

Kind regards,

-- 
  Jan Hidders