Re: Is a function a relation?

From: Cimode <cimode_at_hotmail.com>
Date: Thu, 25 Jun 2009 04:59:00 -0700 (PDT)
Message-ID: <2175cb5b-700d-44d3-8a1d-e55deb135a18_at_l28g2000vba.googlegroups.com>


On 25 juin, 11:32, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "David BL" <davi..._at_iinet.net.au> wrote in message
>
> news:197cd07f-2821-436f-97d7-7d5d1ed82cfa_at_f38g2000pra.googlegroups.com...
>
>
>
>
>
> > On Jun 25, 3:15 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> >> "David BL" <davi..._at_iinet.net.au> wrote in message
>
> >> > I prefer to consider the RM as a pure mathematical formalism divorced
> >> > from "interpretations" (i.e. external predicates and so forth).
>
> >> I can't see how that is even possible, since the extension of a
> >> predicate,
> >> regardless of whether it is internal or external, is a collection of
> >> atomic
> >> formulae, each of which must be judged to be true or false under an
> >> interpretation.  Under the Closed World Interpretation, only those atomic
> >> formulae that are judged to be true are represented, but the judgement
> >> must
> >> still be made, and that requires the assignment of meaning to each term
> >> in
> >> each atomic formula.  I am not saying that the assignment of meaning and
> >> the
> >> judgement of truth which are the constituents of interpretation should
> >> not
> >> be isolated, but I think it is a gross oversimplification to deny that
> >> they
> >> play a part altogether in relational database theory.
>
> > What I mean is that one shouldn't confuse pure mathematical systems
> > such as set theory with how they are applied in the real world.
>
> > A mathematical relation as just a set of tuples.
>
> 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 agree that the topic of interpretation is relevant to database
> > theory.
IMHO, the use of mathematical relations by database relational theorist has allowed to establish a fundamental link between set theory and algebra. Unfortunately, the established formalization remains limitative to the expressive power of mathematical relations: they did not even bother establish valid quantifiers. In that perspective, relational formalization is to revised while keeping its axiomatic definitions and get back to its mathetical fundamentals. Received on Thu Jun 25 2009 - 13:59:00 CEST

Original text of this message