Re: On Formal IS-A definition

On 11 mei, 19:02, paul c <toledobythe..._at_oohay.ac> wrote:
> Erwin wrote:
> > On 7 mei, 19:55, paul c <toledobythe..._at_oohay.ac> wrote:
> >> Erwin wrote:
> ...
> >>>> 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 ?
>
> Nothing questionable that I can express at the moment, I was just a
> little taken aback that the question about two specific values being
> equivalent might depend on design/constraints but perhaps that is what
> it comes down to

I'm uncomfortable with "Values that are equivalent". I spoke of "designs being equivalent". Equivalence, in my book, refers to "having equal meaning". And meaning can only come through a relvar's external predicate, which is only included in some given database design. Database designs include predicates, relation values don't.

The examples are equivalent if the predicate is 'Supplier S# supplies part P#' resp. 'Supplier S# supplies each of the set of parts PS#'.

In the first design, two tuples represent the proposition 'Supplier S1 supplies part P1 AND Supplier S1 supplies part P2", in the second design, a single tuple represents the proposition 'Supplier S1 supplies parts P1 and P2'.

But if the predicate is 'Supplier S# supplies parts PS#, all of them in a single packaging', then the situation is different. The non-RVA design will then require two relvars, one to list the possible packagings, and another to list the involved parts per distinct packaging.

> (I didn't have RVA's in mind, more what you might call
> Set-Valued-Attributes and those certainly do need some basis for
> interpretation, eg., perhaps a tuple with an empty set of parts would
> need to be meaningless in the face of the closed-world-assumption.

Not always.

Suppliers who supply packagings of no parts at all are pretty insane.

But relvar keys that consist of no attributes at all are not. Thus a catalog tuple describing a relvar key with an empty set of attributes most certainly will not "need to be meaningless in the face of the CWA". Quite the contrary, in fact.

And if you want a suppliers-and-parts example, you might consider how you would go about explicitly stating (in a relational form) that 'supplier S1 supplies no purple parts' (which can be done by matching your RVA to the set of purple parts, possibly yielding an empty set). Received on Wed May 12 2010 - 00:15:15 CEST