Re: Modelling and the element of time

I agree here. This sounds like a fascinating subject and one that I would like to get information on also.

"stevan apter" <sapter_at_earthlink.net> wrote in message news:of%r7.12825$W83.1294143_at_newsread2.prod.itd.earthlink.net...
>
> "Drago Ganic" <drago.ganic_at_in2.hr> wrote in message
news:9op6o6$3iud$1_at_as201.hinet.hr...
> 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
bookshelf,
> 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 Mon Oct 08 2001 - 18:54:12 CEST