Re: On Formal IS-A definition
Date: Fri, 07 May 2010 17:55:09 GMT
Message-ID: <1uYEn.3535$z%6.421_at_edtnps83>
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"? Received on Fri May 07 2010 - 19:55:09 CEST