Re: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpolation

From: Cimode <cimode_at_hotmail.com>
Date: 1 May 2007 11:29:45 -0700
Message-ID: <1178044184.315215.167590_at_p77g2000hsh.googlegroups.com>


On 1 mai, 20:10, "Brian Selzer" <b..._at_selzer-software.com> wrote:
> "Cimode" <cim..._at_hotmail.com> wrote in message
>
> news:1178028682.007857.36200_at_p77g2000hsh.googlegroups.com...
>
> > On 1 mai, 15:55, "Brian Selzer" <b..._at_selzer-software.com> wrote:
> >> "Cimode" <cim..._at_hotmail.com> wrote in message
>
> >>news:1178005261.553981.294010_at_y80g2000hsf.googlegroups.com...
>
> >> > On 30 avr, 18:08, "Brian Selzer" <b..._at_selzer-software.com> wrote:
> >> >> "Cimode" <cim..._at_hotmail.com> wrote in message
>
> >> >>news:1177938789.949723.62480_at_h2g2000hsg.googlegroups.com...
> >> >> [snip]
>
> >> >> > I am aware of that article but thank you for reminding it. It
> >> >> > simply
> >> >> > a negation of previous work and has been demonstrated since as wrong
> >> >> > by Codd's disciples (Date, Darwen). The induction of NULL 3VL
> >> >> > simply
> >> >> > breaks the POCW (Principle of Closed World) redefining the meaning
> >> >> > of
> >> >> > a database as a collection of facts. I think of this tolerance as
> >> >> > one
> >> >> > of Codd's errors.
>
> >> >> In a closed world, there is no such thing as "missing information."
> >> >> Can
> >> >> you
> >> >> provide a reference that states that Codd adopted the closed world
> >> >> assumption? I've never read that he did, and in light of his views on
> >> >> missing information, I would be surprised if he had. In an open
> >> >> world,
> >> >> the
> >> >> focus is on what has been stated, and the contents of a database is a
> >> >> collection of recorded facts, not a collection of all of the facts.
> >> >> D&D's
> >> >> interpretation of the RM differs from Codd's in several substantive
> >> >> ways.
> >> >> Aside from missing information, Codd never described a database as a
> >> >> collection of relvars.
> >> > I have to admit that I neither agree with *all* of what either Codd or
> >> > D&D wrote as I found some unclear areas in both their writings. For
> >> > instance, I disagree with Codd's choice of table/attribute based
> >> > structuralism to caracterize relations (I do not either agree with
> >> > definition of database as a collection of relvars).
>
> >> > In case of doubt I prefer to get back to fundamental set theory who
> >> > necessarily tends to support better the closed world assumption.
> >> > I suggest you take a closer look at this. It is the heart of the
> >> > subject we are discussing.
>
> >> >http://www.amazon.com/dp/0486669807?tag=databasede095-20&camp=14573&c...
>
> >> >> In everything I've read, he has always referred to
> >> >> database modifications as inserts, updates and deletes. This would
> >> >> follow,
> >> >> since inserts, updates and deletes are statements that specify how
> >> >> what
> >> >> is
> >> >> known about the universe now differs from what has already been
> >> >> recorded.
> >> >> D&D's interpretation posits that insert, update and delete are simply
> >> >> instances of relational assignment, blissfully ignoring their inherent
> >> >> dependency on the current state.
> >> > I see your point. But keep in mind that RM is an application of a
> >> > mathematical set theory. As soon as it starts loosing touch with
> >> > math, lots of confusion arises.
>
> >> True. But even from a mathematical standpoint a closed world has its
> >> drawbacks. A closed world is great for describing and manipulating a
> >> single
> >> database state, whether you're issuing a query or verifying the
> >> consistency
> >> of a proposed state, but falls apart when trying to deal with more than
> >> one
> >> state at a time. In a closed world, a database modification is not so
> >> much
> >> a modification as it is a replacement. The entire content of the
> >> database
> >> must be stated during each transition because in a closed world there is
> >> no
> >> dependency on what is already known. This limits the granularity of a
> >> transition constraint to an entire relation, because a relation is a
> >> named
> >> set of sets of named values where each element of the relation is
> >> distinguishible from all others only by its component values. As a
> >> consequence, the number of possible mappings between the elements in one
> >> state and the elements in another can be huge. In fact, for a pair of
> >> relations (R, R'), the number of possible mappings is greater than |R| *
> >> |R'|. This makes it impractical if not impossible to define a transition
> >> constraint with a granularity smaller than an entire relation. The only
> >> solution I can think of that is in accord with the closed world
> >> assumption
> >> is to introduce surrogates. A surrogate transforms a relation into a
> >> named
> >> set of named sets of named values, where the surrogate value becomes the
> >> name for a tuple, and where all names are invariant. Those names can
> >> then
> >> be used to provide the 1:1 mapping between the elements in each state
> >> during
> >> a transition that is required to define a transition constraint with a
> >> granularity smaller than an entire relation. So either transition
> >> constraints must be enforced within the application that proposes a new
> >> database state, or surrogates must be defined on each relation schema so
> >> constrained. In an open world, this problem doesn't exist, because a
> >> database modification is a statement that describes the difference
> >> between
> >> what is known now and what has already been recorded. In effect, the
> >> user
> >> selects which of the possible mappings between states applies, and
> >> conveys
> >> that information in the modification statement.
> > I am sorry but I do not understand you anymore. What exactly is a
> > *database state*?
>
> A database value.
What is a *database value* ? What do you mean that a database (collection of facts) is one single value? Do you mean a relation value? (the database being perceived as one single complex relation?) Received on Tue May 01 2007 - 20:29:45 CEST

Original text of this message