The ORM Foundation

Hi Ken, We are in full agreement with respect to gravity. It's not a fact, which can easily be shown since it is a noun. Gravity makes the Earth rotate around the Sun, is a fact, just as a falling Apple made Newton contemplate about gravity, is a fact. Whether an apple actually fell on his head may be an untrue fact. Now to your definition ...

Hello Ken, We're getting really philosophical here. Does there exist something like a "naked" fact? Even if we say that a fact and its existence are one and the same, we already have to introduce an additional fact to express the knowledge of that fact. It is even debatable whether a fact can exist without someone knowing about it. ...

Hello Ken, Many things stored in databases are beliefs.This is why update functionality exists in the first place. There are a few examples where a database is the primary fact holder, general ledger comes to mind, and in such cases update functionality is prohibited. Instead of changing a line in a general ledger we create a new entry negating ...

Exactly because of the points you mention, the range types as present in PostgreSQL, are defined as having a lower and an upper bound. These bounds can be either exclusive or inclusive, and can also be infinite.  To store periods, a built in datatype exists called tstzrange, which stands for "time stamp with time zone range". ...

Thank you Terry, I see how indeed the valid time, transaction time example I gave should indeed in ORM be modelled using elementary fact types, using external unicity constraints. I guess I am still a little bit too much trying to derive a conceptual model from a desired implementation instead of the other way around. Niels 

I realized I made a wrong assumption that in order to define validity period (previously erroneously called validity duration) and transaction period, I would have to define period twice. This of course is not necessary. Period can be defined only once and used twice in a relation, once in the role of validity and once in the role of ...

Hello Ken, Thanks for the model. I am afraid I didn't use the correct terminology in my response to Terry. I used the term duration, where I should have used the term period.  Let me give an example of the usage of those two periods. Suppose we want to record the employment of persons, and we don't want to lose any information we ...

Hi Clifford, I by an large agree with what you say, although I would tend to see your final statement in a different light. First of all, the range type, which has been so important to the discussion so far, is not only a compound data type, it is also an abstract data type. A range type can be defined as having a start, an end, and some ...

Hi Terry, Thank you for your explanation, although I don't fully understand how to use compound value types as entity types. Suppose we have a model with two durations, for example by having a relation that contains a validity duration and a transaction duration, as is a scenario found in some temporal databases.   I understand we can ...

Thank you Terry, That completely answered my original question. Would it be feasible to have compound value types, such as range, point, line, circle, polygon etc., such that phrases like "Reservation1.end <= Reservation2.start or Reservation1.start >= Reservation2.end" can be replaced by something like Reservation1 does not ...