Re: Is a function a relation?

"David BL" <davidbl_at_iinet.net.au> wrote in message news:a42539d8-2ea1-4ff6-b40a-98ff07a4f755_at_c9g2000yqm.googlegroups.com...
> 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.

I don't think I am.

> 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.

The use of relvars does constrain physical implementation--at least indirectly. The decision to use relvars relegates delete, insert, and update to being shortcuts for assignment. As a consequence, when it comes time to enforce constraints, only the before and after images of each relvar are supplied, and it can no longer be determined whether an update was issued, or a just a delete and an insert, or if the entire relation had been replaced.

<snip>

>> > 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 ..."

Perhaps I should have used the term 'collection' instead, to avoid confusion.

>> 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.

Sorry about that.

>> > 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.

I don't think it is flawed since those variables can only contain abstract, well defined mathematical objects that cannot change.

>> > 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.

What do you want to know?

>
>> > 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.

They can in D. See <relation selector inv> on page 110 of TTM 3rd Edition.

> 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).

Not sure what you mean by this. Received on Mon Jun 29 2009 - 11:11:48 CEST