Re: temporary databases

Ruud de Koter <ruud_dekoter_at_hp.com> wrote in message news:<3CF3434A.A322A939_at_hp.com>...
> Just think about one example: a baby being born. You send around lots of cards,
> and whom do you forget: the pension fund. Only when you receive your annual
> summary of pension rights, you realize your kid 's not on it. And then, only a
> hypothetical eight months later, you let the fund know you have a child.
>
> Now, it seems pension funds have long ago realized this is the way people go
> about their lives. They insist that their application allow them to register the
> fact that they were informed on November,8 that a child was born on February,
> 15. They will register that the child was born in February, and grant it
> whatever rights are appropriate from that date on. They will also register they
> only knew this in November.
>
> This is important because only this kind of registration will allow them to come
> up with a good bookkeeping overview regarding the past. Say you want to know the
> fund's oblivgation as they were July, 1. In this computation the hypothetical
> child should not turn up, as its existence was only known to the fund in
> November. This also applies when the computation is executed in December.
>
> So, in short, this kind of registration is useful for important real life
> issues. It might not be your way of looking at life (nor is it mine), but these
> things are important for insurance companies and institutions like that.

Both times make sence in the retirement fund world? Fine:

table BirthCertificates (

    person varchar2,
    DOB date,
    received date
)

and "received" could be called "transaction time" if you like. Still, I don't quite understand how this concept can be leveraged. Query like

TRANSACTIONTIME
SELECT * FROM BirthCertificates;

seems like a joke rather than improvement to me. (AFAIK even more "orthogonal" time dimensions were proposed).

In
http://www.timeconsult.com/Literature/diss.pdf Vertical Temporal Anomaly and Coalescing are mentioned:

<quote>
A user wants to view all data about an employee as a unit, for example, in a single tuple. As we
have seen, the vertical temporal anomaly cannot be omitted in 1NF temporal data models. The
consequence is that the overall time a real world entity plays a specifc role, for example, when the
entity is an employee, is split up in several smaller time periods, due to the changes in attribute
values. Often, however, it is of interest during which time period or how long an employee was
working in a company. In order to calculate maximal time intervals for such tuples, a special
operation { coalescing { was proposed [NA93, Sar93, Boh94, Sno95b, SBJS96b].
</quote>  

Is the author aware of grouping and transitive closure?

select max(enddate)-min(startdate) from emp where ename = 'SCOTT' connect by startdate= prior enddate -- navigating from 'future' back to 'past'
start with enddate between SYSDATE and '1-JAN-9999'

In short, I agree that the real world (and especially accounting practices;-) seems to be too complicated to fit into a simplistic model. But temporal databases look not as a solution, but rather as a speculative metascience to me. Received on Mon Jun 03 2002 - 00:25:33 CEST