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

On 2 mai, 18:16, "Brian Selzer" <b..._at_selzer-software.com> wrote:
> "Brian Selzer" <b..._at_selzer-software.com> wrote in message
>
> news:JJ0_h.6944$rO7.6898_at_newssvr25.news.prodigy.net...
>
>
>
>
>
> > "Jon Heggland" <jon.heggl..._at_idi.ntnu.no> wrote in message
> >news:f19oki$v63$1_at_orkan.itea.ntnu.no...
> >> Brian Selzer wrote:
> >>> "Cimode" <cim..._at_hotmail.com> wrote in message
> >>>news:1178044184.315215.167590_at_p77g2000hsh.googlegroups.com...
> >>>> 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?)
>
> >>> The term "database" is pretty loaded. Most of the time a database is a
> >>> value, a set of relations conforming to a particular schema--a
> >>> representation of a collection of facts at a particular instant. In the
> >>> context of modification, on the other hand, a database is a mutable
> >>> entity
> >>> whose state transitions from value to value as a result of a series of
> >>> events. I use the phrases "database value" and "database state" to
> >>> forestall any confusion.
>
> >>> A set is a value. A database (in the first sense) is a set of named
> >>> sets
> >>> (relations) of sets (tuples) of named values (attribute values) that
> >>> conforms to a particular schema. Therefore it is a single value.
>
> >> Or, if you want to simplify the above by avoiding "state" and "mutable",
> >> you could say (as D&D do) that a database is a variable---a
> >> dbvar---which has a db value. Which is a tuple.
>
> > I think not. A variable permits assignment. You can't compare the value
> > being replaced with the value being assigned because (1) the values belong
> > to different frames of reference, and (2) a relation is a named set of
> > sets, not a named set of named sets. The different frames of reference
> > prevent the use of even logical identity. As a consequence, either a
> > mapping between the elements in each relation in each value must be
> > specified during the transformation, which is not possible with
> > assignment, or a mapping must be interpretable from the content of each
> > relation, which is only possible if at least one determinant in each tuple
> > of each relation is invariant (able to survive any transformation). Once
> > that mapping has been established, logical identity can again be used
> > because domains are invariant. (Even though domains are invariant, the
> > combinations of values from those domains aren't. The mapping, when
> > combined with the invariant domains and names, provides a frame of
> > reference under which each pair of elements can be compared.) Since key
> > updates have been part of the model since its inception, and since
> > surrogates aren't, assignment would permit certain constraints to be
> > bypassed--a clear violation of one of Codd's rules.
>
> Clarification. In a closed world, the assignment itself provides a frame of
> reference for comparison, so it *can* be determined whether or not the
> values are identical, or whether or not one or more corresponding relations
> within each value are identical. As often is the case, I'm wrong: logical
> identity can be used. On the other hand, it can only be determined that a
> tuple in a relation in one value is identical to a tuple in a relation in
> the other. If a relation in the replaced value is neither a superset nor a
> subset of the relation with the same name in the assigned value, and if more
> than one element is different, then a mapping is required for comparison.
> And again, since key updates have been part of the model since its
> inception, and since surrogates aren't, assignment would permit certain
> constraints to be bypassed--a clear violation of one of Codd's rules.
>
> >> --
> >> Jon
Brian,

Don't you think you are overcomplicating things? Received on Wed May 02 2007 - 20:27:10 CEST