Re: Is a function a relation?

On Jun 27, 2:23 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "David BL" <davi..._at_iinet.net.au> wrote in message
>
>
> > If a database system records relations, then there are relation
> > variables. I fail to see how you can deny that. It follows from the
> > definition of 'variable'. Also when a variable changes then by
> > definition it has been reassigned. I don't see how that assumes any
> > implementation methodology. Definitions in themselves don't imply
> > anything at all.
>
> I think you are afflicted with tunnel vision. A database system does not
> just record relations in isolation. If anything it records entire
> databases, one at a time, each of which just happens to be a set of
> relations. But a database system need not even record databases at all: it
> could instead record just the differences between successive databases,
> which when accumulated can be presented as a set of relations. None of
> these implementation methodologies involve the use of relation variables.
> The latter does not even hint at assignment, since it involves appending to
> and accumulating a stream of assertions to arrive at the current set of
> relations, though it is conceivable that intermediate results could be
> cached under the covers in order to improve query performance.

You're ignoring the idea of physical independence.

The definition of 'variable' (relevant to this discussion) doesn't constrain physical implementation choices in any way. The sense in which a variable is deemed to hold a value can be arbitrarily indirect, and for example may involve physical storage of deltas.

Here are some other aspects of physical independence:

• Both base relvars and derived relvars are variables. This distinction (which is a curious one because it doesn't generally represent determinant versus dependent) is only made in the model, and doesn't constrain the implementation.
• A possrep is part of the model and doesn't dictate options for the implementation. In other words the DBMS is free to select an implementation that doesn't resemble any of the possreps and yet it could be said that it faithfully implements all of them.

By its very nature this usage of 'variable' is always an abstraction over the physical (whereas values are instead pure mathematical abstractions divorced from the physical). For example in order to say that an area of computer memory encodes a value it is necessary to make assumptions about many things including address lines, data buses and the interpretation of voltage levels. This should be a reminder that one cannot readily draw an absolute distinction between "direct" and "indirect" encodings of values.

> > I find many things you say very confusing. A database... all possible
> > databases...one possible database...the database...any database. What
> > do you mean by the word 'database'?
>
> A database is a set of relations that conforms to a given database schema.

Do you mean set as in formal set theory? If a database is a set, then it's a pure mathematical object that doesn't exist in time and space. That seems to contradict your prior post "... database values can exist in time and space ..."

> Don't you agree that the database schema defines the set of all valid
> databases? Don't you also agree that of all valid databases, only one
> database at a time can be the current database? Is it my use of the terms
> 'possible' and 'actual' that has you confused?

Actually I'm finding many things you're saying confusing.

> > We have different definitions of the term 'value'. I use it (only) to
> > mean an abstract, well defined mathematical object like a particular
> > integer, completely divorced from any appearance of that value (such
> > as being used to record someone's age).
>
> Abstract, well defined mathematical objects cannot change, so a formalism
> that admits only abstract, well defined mathematical objects cannot be used
> to model things that can change.

I already pointed out the flaw in that statement. Physical database systems are variables not values.

> > When you say a value means different things at different times it
> > seems like you're thinking a value is what C.Date calls an appearance
> > of a value, which actually has more to do with a variable that exists
> > in time and space.
>
> Please don't misrepresent me: I didn't say that a value means different
> things at different times; I said that a term in a formal language can mean
> different things at different times.
>
> Also, a variable is a container for a value. How can it exist in time and
> space?

You're going to have to expand on that.

> > I don't consider relation values to have names.
>
> That doesn't surprise me. I suppose that you would attribute the same
> meaning to a relation that is constructed by explicitly stating the heading
> and tuples, as a relation consisting of the exact same set of tuples that is
> the result of a union of two relations in the database?

Relation values aren't constructed (rather they are selected). You make it sound like they can suddenly spring into existence.

Since relation values don't exist in space or time it doesn't make sense to think that they in themselves record facts about the real world. They only do that when they appear as encoded values in a physical database (as the current value of a relation variable). Received on Mon Jun 29 2009 - 06:10:32 CEST