Re: Terminology for composite attributes

From: David Cressey <david.cressey_at_earthlink.net>
Date: Mon, 21 Mar 2005 07:12:56 GMT
Message-ID: <Ytu%d.58$z.17_at_newsread2.news.atl.earthlink.net>


"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1111382377.779607.231500_at_f14g2000cwb.googlegroups.com...
> I'd like to know if "composite attributes" is the best terminology or
> if there are better terms for logical data modeling in a scenario such
> as the following.
>
> The current model has a relation Person with an attribute Phone. Phone
> currently has a value of a single 10-digit phone number.
>
> If a new requirement comes along to change Phone so that there can be
> one or more Phone numbers for each Person, we have changed the
> multiplicity requirement. We could now call Phone a "multivalued
> attribute" and most software developers and data modelers would
> understand what is meant by that term.
>
> Now let's say that there is no such change to the multiplicity but
> there is instead a requirement to add a PhoneType attribute, with
> values such as "H" for "Home" or "W" for "Work". Let's say that we
> change the type of the attribute named Phone so that it is the
> composite of attributes PhoneNumber and PhoneType.
>
> In this case we might say we are changing Phone to a struct, tuple,
> relation, class, data bean, group, aggregate, composite, or even table,
> but it is one with only one "row" of values. However, several of these
> terms might lead one to think of a data structure with both multiple
> rows and multiple columns and I only want the latter.
>
> Question 1: Is "composite attribute" a good, understandable, phrase for
> this in a similar way that "multivalued attribute" is for the previous
> scenario?
>
> Phone is still an attribute with multiplicity of one, even if the
> __________ is now greater than one. I would fill in that blank with
> "degree" but that is likely to be misunderstood.
>
> Question 2: Is there a better word to use to fill in that blank?
>
> Thanks. --dawn
>

I'm going to answer this question from an "ER modeling" perspective.

"Phone Number" is really not an attribute of a person. It's really an attribute of a "phone line". In the case of a land line, it identifies a local loop that connects a point of service with the nearest switching office. In the case of a cell phone, it's the same thing only virtual.

We tend to model it as an attribute of a "telephone". That's ok unless you are modeling a phone line installation and maintenance service.

In many situations, modeling it as if it were an attribute of a person does no harm, and it serves to keep things simple. In a few situations, such as the one you outline, it's better not to treat it as an attribute of a person. What we really have here is the situation where "person X can be reached at telephone number Y".

This is a relationship. If it's many-to-many then it needs to be implemented in a way that doesn't restrict it too much.

In almost all cases where a "composite attribute" seems to exist, what has really happened is that a relationship has been modeled as an attribute.

I'm being intentionally vague about whether the right design and implementation involves using the RDM and SQL or some other scheme. Received on Mon Mar 21 2005 - 08:12:56 CET

Original text of this message