Re: Terminology for composite attributes

vldm10 wrote:
> dawn wrote:
> > I was a bit concerned that the map from reality to conceptual model
> > might prompt responses such as this. I'd like to discuss your
point
> > too, but my question is really about terms that would work for
> > describing the move from a scalar value to a struct (multiple
scalar
> > values of possibly different types), given a particular logical
> model.
> >
>
> I still think David Cressey's message provides a pretty good
> explanation. And I also think that the term "composite attributes" is
> confusing.
> >

David was going back to conceptual modeling -- the mapping of some subset of "reality" to an initial data model. My example is working with an existing model where one noun has been made an attribute name for some entity. So, for the purposes of my question, I could name the attribute "B" and the entity for which it is an attribute "A".

>
> > So, replace "Person" with "A" and "Phone" with "B" and so on so
that
> > the reality mapping doesn't interfere. Using a relational model,
> both
> > multivalued attributes and composite attributes
>
> It is unclear how you arrived here.

The scenario is that there is somehow a change in requirements after the data model is designed or in production. Attribute B now has another value associated with it -- one that is not dependent on the key, the whole key, and nothing but the key, but is related to B in such a way that the combination of B & C IS still dependent on the key, the whole key, and nothing but the key.

If the Phone doesn't work for you, feel free to pick another example that illustrates what I indicated -- a requirement for a new attribute "C" where "B" & "C" together have the same relationship to "A" that "B" once had alone -- that of an "attribute", but now a composite one. I realize that in a relational model this composite value would have to be normalized out -- I'm just looking for a term that describes what the data modeler observes prior to redesigning. [Also, I'm guessing most of us has seen such cases where the new attribute "C" is simply tossed in as an attribute of "A", leading to denormalization, but then not requiring a new table for B & C.]

> Can you, in more detail, tell us
> how you arrived at these relations - with "composite attributes" -
> before splitting them out.

Did my previous response explain that? I started with a normalized data model and then the requirements changed.

> get split out into
> > separate relations before the logical modeling is completed, but
> before
> > that happens there is a recognition by the modeler that what was a
> > single value must now hold multivalues (in the one case) or what
was
> a
> > single value must now hold a "composite value."
> >
> > Does that terminology work or is there a better way to say it?
> >
> > Then we can chat about your point and the mapping from reality that
> > might put HairColor as an attribute of Person even though it is
> clearly
> > an attribute of Hair.
>
> As far as I know, in Biology the hair color of a person is determined
> by his or her DNA. And DNA is a "person-level".

You must be assuming that the person is not wearing a wig, eh? ;-) And maybe natural hair color is determined by DNA, but my hair color is determined by Barb about every 6 weeks.

> I am also confused by why you decided to compare David's Person-Phone
> relationship to Person-Haircolor; there is a big difference between
the
> two.

I was giving another example where one person might associate an attribute with a person when another might model it somewhere else.

<snip>
Does that explain better or is it still unclear what I'm asking? Thanks.
--dawn Received on Thu Mar 24 2005 - 01:04:34 CET