Re: Full Name as Composite Attribute

David Cressey wrote:
> Recently a discussion came up in another thread about whether the
term
> "composite attribute" is acceptable and meaningful terminology. I
think
> that other thread answered that question in the affirmative, to most
> peoples' satisfaction.
>
> This thread is an attempt to provide an illustration of why
"Composite
> Attribute" might or might not be a useful (!) concept to add to the
> fundamental data modeling tools one uses.
>
> I'd like to suggest that "Full Name" is a good candidate for such a
> discussion. My "Full Name" as it appears on my credit card is the
same as
> my name in this NG, except that I have a middle initial.
>
> "Full Name", as one attribute of a person, even though it is
composed of
> smaller attributes, makes a lot of sense.

It definitely makes sense to me that in the "data catalog" there be an attribute for "Full Name" as well as "First Name" and "Last Name".

I'm not sure just where in the conceptual to logical to implementation to physical modeling spectrum a data modeler identifies what should be "stored" compared to "derived" data, but I would expect that would be in the implementation model (the one specified to a particular dbms). I would (in fact I do) model "Full Name" as a derived attribute rather than modeling the component parts as derived, but would like to retain information

My need for the "composite attribute" terminology was in describing what prompts changes to existing data models. In the case of your example, if only a first name were modeled as a "name" in a particular situation and then a new requirement were made for a last name, this would be an example of an attribute (name) modeled as one attribute and then growing "horizontally" into a composite of first name and last name. If, on the other hand, a first name were stored and then there were a requirement for all names that the person uses as a first name (e.g. Nicknames) rather than just one First Name, that would be a way for First Name to grow "vertically" into multivalues, rather than composite values.

> When would you want to decompose the name into subcomponents?

In your scenario, it sounds like you are starting with an attribute of "Full Name" and working to determine whether to model it with one attribute or more than one. In the conceptual model, you can certainly do both -- include Full Name as an attribute composed of attributes First Name and Last Name (& middle and other parts as desired). It is not until you are determining what will be stored as data values and what will be derived from those that are stored that you need to make the decision on which will be attributes of "base tables" (for example).

> Well, for example, if your were alphabetizing a list of authors,
you might
> want to sort "Samuel Clemens" under
> "Clemens, Samuel". In order to compute the sort key from the full
name,
> you have to know a little bit about the
> components of the full name.
>
> When you go multicultural, it gets more complicated. Some cultures
include
> mother's maiden name, others put the family name first etc. I'm not
really
> interested in such complexities. I'm interested in whether the
concept of
> "Composite attribute" as illustrated by "full name" in fact
simplifies
> data analysis or in fact makes things more difficult by hiding
complexity
> that should not be hidden.

I don't "get it", David. What is your concern?

> I realize that this is a subjective judgement. But I'm interested in
> responses.

I suspect that only talking about "Full Name" during conceptual modeling is good, while you would want to identify the component parts during logical modeling and then decide what will be "stored" compared to "derived" attributes. But I think you have a question here that I'm not tapping into, so feel free to pass along more clues on just what concerns you about "composite attributes". I'm very interested. Thanks. --dawn Received on Tue Mar 29 2005 - 01:14:44 CEST