Re: On Formal IS-A definition

On 12 mei, 07:12, paul c <toledobythe..._at_oohay.ac> wrote:
> Bob Badour wrote:
> > paul c wrote:
>
> >> Erwin wrote:
>
> >>> On 11 mei, 19:02, paul c <toledobythe..._at_oohay.ac> wrote:
>
> >> ...
>
> >>>> (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.
> >>> ...
>
> >> But why record it?  Another case might be the combinations of parts
> >> that have ever been shipped by each supplier.  Is there a good reason
> >> to record every supplier for whom the combination is an empty set.
>
> > /paul's/Erwin's/
>
> > Oops, make that "re-read Erwin's post with greater care."
>
> I'm guessing that you mean the utility of keys with no attributes.  But
> what if there's another way to specify them that doesn't involve empty
> sets (or RVA's if you like)?  Not saying there is an easy way given the
> conventional approaches.  I think Erwin hinted at one problem earlier,
> how can the empty set of parts co-exist with a non-empty set (his case
> 'b' where no key is specified), eg., a supplier has no parts and some
> parts simultaneously.

I think you are making certain assumptions about the external predicates in your design and these assumptions are prohibiting you to see the broader picture.

'Supplier S# supplies parts in a packaging that consists of parts PS#'.

Now if it is true that supplier S1 supplies parts in a packaging that contains the parts P1 and P2, then following the CWA, the tuple {S1 {P1 P2}} must appear.

And if it is true that supplier S1 supplies parts in a packaging that contains the part P1 alone, then following the CWA, the tuple {S1 {P1}} must also appear.

Same for the possible appearance of empty sets in a design. Whether empty sets can or cannot appear in a design, should be dictated by the requirements. When it is conceivable that requirements require a representation for the emptiness of a set, the model must offer a way to do that. "List all the suppliers that exist plus for each, the set of purple parts he supplies" is one such conceivable requirement. "Record all the keys that exist plus for each, the set of attributes it consists of" is another one such. This last example is also the answer to your question "Why record it" : because the requirements tell you to.

About the "easy way to represent emptiness using conventional approaches" : there _is_ one. I use it in SIRA_PRISE. There is one catalog relvar {relvarname keyid} listing all keys, and another one {relvarname keyid attributename} listing all the key attributes. Easy as one and one make two. The first one defines existence of key, the second one might imply absence of attribute.

However, there are mamba's and kraits just under the surface itching to bite you with this design. If I want the keys and their attributes in RVA form, then I just join these two relvars and then group that on {relvarname keyid}, right ? Well, if I had been given a dollar each time I made that mistake I'd be Croesus now.

I admit that it is very difficult to imagine a more "real-business- world-like" example where there is also a requirement to "kind-of explicitly" state absence. But that is not really relevant. Received on Wed May 12 2010 - 14:18:29 CEST