Re: Implications of Relation-Valued Attributes

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:unKMa.1369$I8.543_at_rwcrnsc53...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
news:kIwMa.165$2q3.21361772_at_mantis.golden.net...
> > The relational model does not have any constructors. A constructor is an
> > entirely physical artifact.
>
> Sure; I agree. I perhaps should have called them "type generators" instead
> of "type constructors" but I'm more used to the latter term.
>
>
> > > Once we allow these to be used recursively, we get allow some
complicated
> > > structures. That is, we may have relations with attributes that are
> > relations
> > > with attributes that are tuples that contain lists, etc. (The kind of
> > thing I did
> > > in C in college :-)
> >
> > First, we do not get complicated structures. The only structures we have
> > remain relations with single-valued attributes. Of course, the simplest
> > possible representation for these single-valued attributes can become
quite
> > complicated.
>
> I have a hard time understanding the distinction being drawn here. If the
> type of an attribute is 'set of tuple of (int, set of tuple of (string,
float, int))'
> then it does not seem out of line of me to say we have a complicated
structure,
> even if what we have at the top is still a relation with single-valued
attributes.

From the perspective of the relational model, the internal structure is irrelevant even for the tuple attribute. For instance, one possible representation of a 64-bit integer is a tuple with 64 named booleans. The relational model can use that possible representation or any other possible representation for integers, and ultimately the relational model does not care which possible representation gets used. It's still just dealing with a single integer value.

The tuple attibute contains just a single value with defined operations. An operation is different from a structure.

> > Second, as designers, we need to know there is often a difference
between
> > "can" and "should".
>
> That's an excellent point! It may be that what I'm worrying about is
simply
> not an issue, or only an issue for the sophomore.

Design is as much art as science. The key skill that separates good designers--especially object oriented or type designers--from average designers is knowing when to stop. (For some reason, that observation is tied in my mind to Thomas Cargill, but I could not find the reference.) Received on Fri Jul 04 2003 - 01:28:11 CEST