Re: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpolation
From: Brian Selzer <brian_at_selzer-software.com>
Date: Tue, 01 May 2007 23:17:03 GMT
Message-ID: <PTPZh.2181$RX.2112_at_newssvr11.news.prodigy.net>
>> "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.
Date: Tue, 01 May 2007 23:17:03 GMT
Message-ID: <PTPZh.2181$RX.2112_at_newssvr11.news.prodigy.net>
"Cimode" <cimode_at_hotmail.com> wrote in message news: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?) >