Re: In an RDBMS, what does "Data" mean?
Date: Wed, 16 Jun 2004 10:35:23 -0500
Message-ID: <cappc2$4re$1_at_news.netins.net>
"Eric Kaun" <ekaun_at_yahoo.com> wrote in message
news:lcZzc.1825$Pt.1467_at_newssvr19.news.prodigy.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:cal2mk$e5k$1_at_news.netins.net...
> > "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> > news:pgkzc.25517$_g6.23406_at_newssvr31.news.prodigy.com...
> > > How is this useful? I've seen this in COBOL layouts, and was
> underwhelmed;
> > > 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
> relationships.
> > Month, Day, and Year are three such nouns and you might want another
that
> is
> > 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,
> if
> > 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.
Well, see now, I knew that about you (and your type ;-) and so I poked. Derived data is just applying operations to stored data, whether a "type operation" or any other function one wants to write or that comes with the licenesed toolset. There remain these two things: data and functions and the coolest of these is derived data (applying functions, by whatever name, to data).
> 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.
yup, or use something like number-of-days-since-D-day and then functions on that to view it in whatever way is desired
> 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...
No problem - we've wandered a ways from Wol's original point, so I'll summarize with it. Now that we've determined that relational modeling/theory is NOT mathematics, we can get back to the science of it, which is where experience comes in. Since we all have different experiences and there are not enough good studies (if any) to validate industry best practices, I think we do well to learn from the experiences of others.
cheers! --dawn Received on Wed Jun 16 2004 - 17:35:23 CEST