The ORM Foundation

I've been thinking of exploring temporal modeling through introducing "one at a time" uniqueness constraints. That is, where the mapping takes care of the mapping of the history of a given N-ary fact type, by internally injecting a time role into the fact type, and enforcing the time roles to model uniqueness at a point in time. The point here being that generated data access code can have a simple API to the "current" data, and another API to access the full history.

This seems to be a remarkably simply way to handle a large class of temporal modeling problems.

Does anyone see problems with this as a conceptual modeling notion?

There is obviously the need for mapping options, because it can be mapped many ways and you need to choose the most appropriate one. Perhaps we don't need to discuss the pragmatic concerns in this thread; start another if you'd like to discuss that.

 That approach might be helpful for one kind of temporal modeling pattern, so long as you allow users to choose the temporal granularity each time (which may differ for different fact types). Various other patterns are discussed in the BBB (section 10.3) and elsewhere. I take it that your main idea here is to mark the fact type in some way as temporal rather than explicitly displaying the expanded version of the fact type. This kind of UI was suggested by Falkenberg many years in one of his papers on temporal extensions to fact oriented modeling.

Cheers

Terry

Thanks for your response

I don't see this extension as being useful or necessary for recording the instant at which an event occurred. That's quite adequately handled by simply recording a simple temporal value. The construct doesn't offer any help with modeling repeated times or intervals (e.g. the last Thursday in each month) but those would generally need explicit modeling anyhow. So that leaves the remaining pattern, being for recording non-overlapping intervals, either contiguous (one at a time) or discontiguous (at most one at a time). After single events, this is the most common pattern.

A "one at a time" would record a start time (before which the main player is not allowed to exist to require the constraint to be fulfilled), and any subsequent assertion closes off that interval and must begin a new one, triggered by a simple update request. Deleting (actually retracting the validity of; soft deletion should be automatically correlated) the main player also closes off the outstanding interval. So if a Person was born into the Smith family, their surname would be asserted as Smith from the moment of their birth registration (or whatever), continuously until their name was changed by marriage or deed poll. At that point, the open validity period associated with their name being Smith would be closed off, and a new one opened with their new name. On the other hand, by implication, the use of "at most one at a time" implies that it is possible to close off an existing open interval without opening a new interval.

Some of the temporal patterns relate to different ways to map "one at a time" and "at most one at a time" patterns, rather than conceptual differences, so in most cases I'd leave the choice between patterns as a mapping option or default. Even granularity is often sub-conceptual, which is why I relegated it to a lower level. You could introduce that directly by saying "one in each day", "one in each second" as opposed to the default, which means one in each instant.

As for valid time vs transaction time, ActiveFacts already has a variable "Now" (defaulting to the system time) which can be set to the time at which the current transaction is to be considered to be processed. If it's set in the past and a change is made, there would need to be validation that the change didn't unexpectedly contradict existing accepted facts.

Because of the requirement of soft deletion if a temporal mandatory uniqueness is applied, it may be necessary to incorporate "at a time" semantics into the identifying uniqueness constraint of the main player, for example the Person in the example above. This allows a Person to be identified by past roles that currently identify a different Person, such that other facts in which the earlier Person was involved ceased being valid when or before their identification expired. The alternative to soft deletion is to disallow both deletion and closing off the mandatory fact.

A feature not obviously covered by this proposal is where the states of several facts relating to one player are anticipated to all change together, and so a mapping option is needed to group them for efficiency (even if not all must change on each such transaction). Again though, that's sub-conceptual, it's just a mapping feature.

I think this feature would provide a very effective way to hide complexity in many models, especially ones where an audit trail must be kept. Such models can be incredibly painful to build, understand and use, and a simple extension like this would be a huge boon. If necessary, a tool can allow the hidden temporal roles to be "folded" and "unfolded" so that additional constraints can be applied to those roles.

For anyone who is interested I use the following symbology for my own benefit...

I stick a 'T' inside a circle in the middle of a fact to indicate that its uniqueness is time dependent, that is, the value of a role can change over time, and a history of the change must be kept. If the role is mandatory then it is contiguous, eg the status of an entity; and if it is not mandatory then it's discontiguous, eg the registration of a vehicle.

I also use an 'X' inside a circle in the middle of a fact to indicate that the fact is locked and cannot be changed, eg a type of vehicle.

A fact with neither of these, and with no other information indicating otherwise, indicates that a role's value can change with time and no history is kept, eg the description of a product.

I use the above to build my conceptual models for compiling / portraying business rules.

cheers