Re: Stored fields ordered left to right

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Sat, 10 Jan 2004 18:41:49 -0600
Message-ID: <btq64l$ddt$1_at_news.netins.net>


"Adrian Kubala" <adrian_at_sixfingeredman.net> wrote in message news:slrnc010to.j9o.adrian_at_sixfingeredman.net...
> Dawn M. Wolthuis <dwolt_at_tincat-group.com> schrieb:
> > "Adrian Kubala" <adrian_at_sixfingeredman.net> wrote:
> >> Functions are one-way mappings. Many relationships in the world work
> >> both ways. It certainly seems useful to distinguish these two kinds of
> >> relationships, which relations + functions does but functions alone
does
> >> not.
> >
> > This must be another issue of definitions because there are no
> > functions in mathematics that are not relations. Functions are a
> > particular type of relation.
>
> I had assumed you were talking about representation. There is clearly
> some difference between, i.e. the function y = x and the relation
> {<0,0>, <1,1>, <2,2>, ...}. For example, it would be impossible to
> enumerate that relation explicitly in memory. On the other hand, some
> functions are such that if you express them implicitly as equations it
> is harder to solve for some variables than others. That's why I say both
> representations have merit, but that for the kinds of relations
> represented in a database it's usually simplest to express them
> explicitly.
>
> Since you were not talking about relations vs functions in terms of
> their representation, I don't understand your original point. All
> functions are relations but not all relations are functions, therefore a
> function-only database is strictly less expressive than a
> fully-relational one with no benefits.
>
> On the other hand, if a database allowed you to describe *some*
> relations as functions and took advantage of algebraic reasoning when
> creating derived relations from these functions, that would be really
> neat. But then you'd basically have a kind of Prolog, right?

With this discussion, I've been focussed on one specific issue, where the database model I am using has been taken to task for not employing relations. I have no problem stating that it does not 100% follow a relational database model, however, this one point -- that it does not employ relations is entirely false. Everything in the model is a function and since all functions, by definition, are relations. Chris Date asks questions about the MultiValue database model in his papers on 1NF this summer and he and Pascal are likely correct that nothing they have read is precise enough to respond to. The argument again crops up that the Nelson-Pick/MultiValue model is not based on relations and I intend to state that because it is based on functions and functions are, by definition, relations, that it is most definitely based on relations. Other arguments that it does not abide by every relational database rule are likely accurate, but this indictment is not.

So, that's my point -- the MultiValue model is based on the mathematical definition of relations, and should not be accused of not being "relational" in that regard, even if it is not based on Codd's relational database model. Cheers! --dawn Received on Sun Jan 11 2004 - 01:41:49 CET

Original text of this message