Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Modelling and the element of time

Re: Modelling and the element of time

From: amir brown <>
Date: Thu, 27 Sep 2001 06:05:33 GMT
Message-ID: <Nkzs7.22157$>

I would also like a copy of the white paper. Is there any way you can post it as a pdf or postscript file for download? I'd be willing to host is so that everyone had access to it.


"stevan apter" <> wrote in message news:of%r7.12825$
> "Drago Ganic" <> wrote in message
> Hi there,
> I'm modeling a general business system (party, product, order, shipment,
invoice, payment etc.) that will be sold as a product, but
> parts of it will also be used in other products/projects my company sells.
So, I try to solve some general and known problems that
> can be used by anybody in my company.
> The system will contain two parts: a production system (mainly for data
entry) and a data warehousing/data mart system (only for
> reporting and analysis).
> I would like to hear some opinions or get some references about modeling
the element of time. That problem is solved very nice in
> the DW concept. But I have also a need for it in the production system.
> There is also another problem - that is connected with the time problem -
Should I model the complexity of the real world ??!?
> :
> hi drago -- greetings to croatia
> several years ago a colleague and i were engaged to write an hr tracking
and query system
> which would model employees in an organization. the basic intuition was
this: an individual
> in the firm possesses various properties which vary over time. for
example, a particular
> individual occupies various offices at different moments in the course of
his employment. we
> chose to represent this as an assertion of the form 'P(i) from f-time to
t-time'. that is, as a
> state holding over an interval. events, which occur instantaneously, can
be represented as
> assertions of the form 'P(i) from x to x', where f-time = t-time.
> moreover, such assertions are themselves dated. for example, on january 3
1999 we assert of
> tom that he occupies office 17 from october 4 1998 through some unknown
future date. when,
> on february 13 2000 tom moves to a new office, we record a further
assertion to that effect.
> finally, we may occasionally need to add new properties to the system.
for example, the firm
> adopts a new savings program in which individuals may participate.
> the collection of all assertions of the form 'on a-time P(i) from f-time
to t-time' constitutes
> the raw data. notice that you never delete records. later assertions
mask (wholly or
> partially) earlier ones.
> since the time of our work on this project a considerable amount of
material on the subject
> has appeared (i have a copy of snodgrass &al's _temporal databases_ on my
> but it was published too late to be of use to us.) i wouldn't be
surprised to learn that "bi-
> temporal" extensions to commercial db systems have since arrived.
> drop me a note if you'd like to get a copy of our whitepaper describing
the design in more
> detail.
Received on Thu Sep 27 2001 - 01:05:33 CDT

Original text of this message