Re: In an RDBMS, what does "Data" mean?

From: Eric Kaun <>
Date: Wed, 16 Jun 2004 14:56:17 GMT
Message-ID: <lcZzc.1825$>

"Dawn M. Wolthuis" <> wrote in message news:cal2mk$e5k$
> "Eric Kaun" <> wrote in message
> news:pgkzc.25517$
> > How is this useful? I've seen this in COBOL layouts, and was
> > it always seemed to cause more problems (and invite even others) than it
> > appeared to solve. How is this more effective than a view, for example?
> Logically that is what it is, I guess, but it can be nested.
> Take all of the nouns you want to consider and look at their
> Month, Day, and Year are three such nouns and you might want another that
> made up of exactly these three -- so you can derive Date as Month | Day |
> Year or derive month, for example, using a function as Month(Date). Now,
> you are looking at a list of dates, you can do the same thing, performing
> functions to group or separate various data.
> I'm not sure that answered your concern. I think being underwhelmed
> regarding derived data is appropriate in 2004. smiles. --dawn

I don't think any of the above represents derivation; it looks more to me like operations over types. I think of Date as a type, as well as Day, Month, and Year.

So I'd set up equivalences like these:

Month(Date(Y, M, D)) = M
Day(Date(Y, M, D)) = D
Year(Date(Y, M, D)) = Y

which assumes only that you have a selector (constructor) Date(Y,M,D). You could set up others, of course, and you'd need domain specifiers over M and Y, and then a constructor for Day that took Month into account.

And then the individual types would have other semantics. In particular, you'd have to introduce the notion of calendars (the above is GregorianDate), and the base type all of them rely on (not "derived from") is something like Timestamp, an instant in time.

But I think I've gone far afield of your original points...

  • erk
Received on Wed Jun 16 2004 - 16:56:17 CEST

Original text of this message