fsharp / dotnet and temporal database

Question

I am looking for a way to integrate as directly as possible a temporal awareness into my classes. I deal with data that change with time quite a lot, like share prices, so this would probably need some attention, and be dealt with in one place to ensure "separation of concerns".

Have you had similar experience with temporal data/databases ?

What could you recommend reading / knowing ?

(I am thinking of wrapping my computations around a TimeSlice(date) computation expression builder, in order to scope retrieval to the specified date which constitute the 'horizon' of my computation. like

let oldCEO = 
      historicaDate(Today() - 10 years)            {
          let! company = CompanyFinder("MSFT")
          company.CEO 
        }
let todayCEO = 
      historicaDate(Today() )            {
          let! company = CompanyFinder("MSFT")
          company.CEO 
        }

What exactly do you mean? Can you post how would you imagine the expression? — svick, Feb 26 '12 at 13:30
I would expect it to be ``(historicalDate (Today() - 10 years)) { .. }`` and ``return company.CEO``. — Ramon Snir, Feb 26 '12 at 14:01

score 1 · Answer 1 · answered Jan 02 '14 at 17:32

Reading your question I am reminded of the Datomic database from the inventor of Clojure which explicitly "is a database of flexible, time-based facts, supporting queries and joins". http://www.datomic.com/ Perhaps ideas there will stimulate your F# thinking, as they have mine.

Gene Belitski · Answer 2 · 2012-02-26T17:56:21.143

I believe that considering temporal aspect of reality captured in your data model should begin with very explicit distinction between valid time and transaction time dimensions; your example approach with CEO "at point in time" having "CEO" state accompanied by just one generic temporal dimension state "When" may be good enough as long as you do not consider multiple sources of your captured "facts" on fine grain time scales. Otherwise, if you turn to mentioned in your question matter of share prices and their relationships, like between value of S&P 500 index and prices of its constituents, you cannot get away from distinguishing these two dimensions and capturing them in your internal data state: the value of S&P 500 index have sense only with regard to some transaction time as you need to collect constituent prices at some valid time moment and perform (not instantaneous) weighting and calculations in order to come up with index value at some later transaction time moment, which, in fact, is value for the past moment of valid time.

Or, even staying within your example, imagine that you are required by some compliance regiment to audit anytime what was your response at some moment in the past. In other words, your time specificator

historicalDate(date: <time expression>)

is a particular variant of more generic case

historicalDate(date: <valid time expression>,
               asOf: <transaction time expression>)

so historicalDate(Today() - 1yr) is, in fact, historicalDate(Today() - 1yr, Now()), but, in principle, may be historicalDate(Today() - 1yr, Now() - 20days)

Dealing with data bitemporally is not a matter simple enough to give a short one-fits-all recipe on taming it through specific language mechanisms like computation expressions. It definitely would be a good idea to do some reading. If being asked what a single book I may recommend on the subject, my answer would be Managing Time in Relational Databases, otherwise if you want exhaustive research you may also consider classic Developing Time-Oriented Database Applications in SQL and Temporal Data & the Relational Model.

Maybe someone else can point you to approaches of handling temporal data state outside of relational-based persistence mechanism, but my own experience is limited only to the such.

Indeed. 'value' date and 'horizon' date are not the same. This problem is quite a fundamental one. As soon as we deal with data, we are confronted to it one way or another. Thanks for the links I am looking into it. — nicolas, Feb 26 '12 at 18:13
@nicolas: In temporal data domain 'horizon' date normally means something completely different from 'transaction' date, namely, a **future** point in time. For example, "stock target price" having usually one year horizon date is a forecasted price of the stock in a year from now. In order to avoid confusion it's always better sticking to the established terminology, which is **valid** for reality time dimension and **transaction** for model one. — Gene Belitski, Feb 26 '12 at 19:34
I did not know of this terminology. in finance i think the established idiom for it would be 'historical' date. and the stock target price would have an associated date that you'd call maturity date, term, or pillar date. For myself, I find the term horizon descriptive enough, if you think of the horizon as the place after which you can not see, because it is too far ahead. this use is a direct analogy in time of an existing concept in space. — nicolas, Feb 26 '12 at 20:37
Of course horizon pertains to the 'use' of data, and not of data themselves, but the 2 concepts are bound : for a given horizon date, you have acces to all the events whose transaction date is inferior to the horizon date — nicolas, Feb 26 '12 at 20:40

score 0 · Answer 3 · answered Feb 27 '12 at 20:52

0

I am not sure if I get enough from your description, but it sounds like your want to look into Reactive Programming, where depending values may change over time, in particular something like Functional Reactive Programming.

answered Feb 27 '12 at 20:52

lysium

331
2
5

oh no please dont give me another excuse to dig into another cool FP concept ! I have enough of those ! ;) Thank you I will look into it. – nicolas Feb 27 '12 at 21:25

fsharp / dotnet and temporal database

3 Answers3