Re: On Formal IS-A definition

On 7 mei, 19:55, paul c <toledobythe..._at_oohay.ac> wrote:
> Erwin wrote:
> > On 6 mei, 17:32, paul c <toledobythe..._at_oohay.ac> wrote:
> >> Erwin wrote:
>
> >> ...
>
> >>> Another small point is that there is a school of thought which says
> >>> something about a connection between relation algebra and first order
> >>> logic, thereby excluding transitive closure as a possible operator of
> >>> RA because transitive closure requires recursion and recursion is
> >>> excluded by FOL.  I don't really understand their point, or why they
> >>> are trying to make that point, because imo (generalized) transitive
> >>> closure is a sine qua non for "expressive completeness".  Without
> >>> transitive closure, certain queries are provably unanswerable, and so
> >>> TC is needed.  I find that statement about the link with FOL rather
> >>> vacuous for that reason.
> >> Personally, I'd call such a 'connection' beside the point.  I would have
> >> thought that given enough variable names, FOL can recurse.  That might
> >> be impractical so if my attitude is on the point, such a 'school' is
> >> really talking about implementation.  Even apart from transitive
> >> closure, I'd have thought that any query involving a relation with more
> >> than one tuple effectively involves recursion as far as implementation
> >> is concerned.
>
> >> When looking at one of Codd's "R-tables", schoolchildren of all ages can
> >> usually identify all the transitive/derived relations even if they can't
> >> visualize the mechanization needed.  I'd say this is a patent reason to
> >> put paid on the Information Principle as far as transitive closure is
> >> concerned.
>
> >> Regarding another aspect of the Information Principle, I'd like to ask
> >> whether an SuppliersParts relation such as:
>
> >> S# P#
> >> S1 P1
> >> S1 P2
> >> S2 P3
>
> >> has the same information as one with a domain PS# that is a set of part
> >> numbers:
>
> >> S# PS#
> >> S1 {P1,P2}
> >> S2 {P3}
>
> >> If they have the same information, does that mean they are equivalent,
> >> ie., each implies the other?  If so, is there a practical need for a
> >> relational equality operator (as opposed to equality between domain values)?
>
> > Whether those designs have(/guarantee) the same information depends on
> > the constraints.  You don't mention those.
>
> > In your example, there are two cases (wrt the PS# design) :
>
> > (a) S# is declared to be a key
> > (b) S# is not declared to be a key
>
> > If (a), then the designs are equivalent.
>
> > If (b), then they are not.  For in this case, there must have been an
> > explicit reason to allow both the tuples {S1 {P1}} and {S1 {P1 P2}} to
> > appear (otherwise the designer could simply have chosen key S#).  A
> > designer explicitly opting to allow both {S1 {P1}} and {S1 {P1 P2}},
> > must therefore be assumed to attach a different meaning to those two
> > tuples, meaning the two propositions implied by those two distinct
> > tuples are unequal, meaning that there is something to the predicate
> > of this relvar in which a difference of meaning is caused by the set
> > value of the RVA attribute.
>
> > Can't explain it any better than this.  Relvar predicates when RVA's
> > are involved is pretty much an issue that's still left to be resolved,
> > as I'm sure you're very well aware.
>
> Thank you.  Regarding "If (a), then the designs are equivalent", can we
> also say that (logically) equivalent means "same information"?- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

I suppose so. Do you see a reason for this being questionable ? Received on Sat May 08 2010 - 00:03:44 CEST