# Re: Is a function a relation?

Date: Fri, 26 Jun 2009 14:22:06 -0400

Message-ID: <il81m.5711$iz2.2237_at_nlpi070.nbdc.sbc.com>

"David BL" <davidbl_at_iinet.net.au> wrote in message
news:49f1d816-747a-46c7-84b7-14eb0b1fc04e_at_y10g2000prc.googlegroups.com...

> On Jun 25, 5:32 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:

*>>
**>> But a database relation is not the same thing as a mathematical relation.
**>> The difference may not be immediately obvious--and I'm not referring to
**>> the
**>> fact that components of tuples in a database relation are named whereas
**>> components of tuples in a mathematical relation are indexed. The
**>> difference
**>> is in how the relations are arrived at, and the extent to which they
**>> endure.
**>> In the case of a database relation, the predicate is extended and each
**>> atomic formula is judged to be either true or false at the instant of
**>> interpretation, but in the case of a mathematical relation, the predicate
**>> is
**>> extended and there is no need to judge whether each atomic formula is
**>> true
**>> or false because owing to the fact that whenever there is a particular
**>> abstract object, it is necessary that there is that particular abstract
**>> object, each atomic formula in the extension of a mathematical relation
**>> is
**>> true necessarily. So for mathematical relations, one can safely dispense
**>> with judging the truths of the atomic formulae represented by tuples.
**>> Also,
**>> the assignment of meaning to terms in the atomic formulae in the
**>> extension
**>> of mathematical relations can be deferred because abstract objects
**>> neither
**>> come into existence, change in appearance nor cease to exist. It is
**>> tempting, therefore, to treat database relations as mathematical
**>> relations,
**>> and one safely can for activities or specifications that involve just one
**>> instance at a time, such as queries or the specification of referential
**>> constraints, but the danger in expanding the scope of activities or
**>> specifications so that they involve more than one instance at a time, as
**>> is
**>> the case for updates, is that there would be more than one assignment of
**>> meaning and more than one judgement of truth for the same activity.
**>
**> I don't know what that means, so I'll ask some questions to try to
**> establish a common point of reference!
**>
**> * Do you draw a distinction between a relation variable and a
**> relation value?
*

Of course, but I think in terms of relation schemata instead of relation variables. Date and Darwen's databases_as_collections_of_relvars paradigm presupposes assignment as the only mechanism for implementing database updates. Relation schemata serve the same purpose as relation variables but without the baggage of assuming an implementation methodology.

> * Do you think it's possible to talk about the relation value

*> recorded in a relation variable in a particular database at a
**> particular time?
*

I'm not sure what you're asking here. A database is a set of relations that conforms to the database schema. The state constraints specified on the schema determine the set of all possible databases. Only one possible database can actually be /the database/ at any given point in time. It should be possible to talk about any relation in any database at any time. That's why I don't understand your question.

> * Is a relation value necessarily associated with some external

*> predicate?
*

> * What is the definition of equivalent relation values?

In what context?

> * Do you think it's possible to say that distinct relation variables

*> (possibly in distinct databases) happen to have recorded the same
**> relation value at particular times - even though the relation
**> variables have distinct external predicates?
*

A relation is a named set of sets of named values. The name of a relation is significant and should, I think, preclude it from being recorded in distinct relation variables. Also, one cannot assume that the name given to a domain defined in one database schema would be identical to the name given to the same domain in another database schema, so there is no common frame of reference in order to compare relations in databases that conform to different database schemata. In the case of ETL applications, the frame of reference is supplied in the form of a schema mapping between systems. Received on Fri Jun 26 2009 - 20:22:06 CEST