Phone Numbers, generic relationships & "white space"

From: dawn <>
Date: 23 Mar 2005 07:22:38 -0800
Message-ID: <>

David Cressey wrote:
> "dawn" <> wrote in message
> > I'd like to know if "composite attributes" is the best terminology
> > if there are better terms for logical data modeling in a scenario
> > as the following.
> >
> > The current model has a relation Person with an attribute Phone.
> > currently has a value of a single 10-digit phone number.
> 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
> 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
> switching office. In the case of a cell phone, it's the same thing
> 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
> treat it as an attribute of a person. What we really have here is
> situation where "person X can be reached at telephone number Y".
> This is a relationship.

I agree that if the business domain includes phone "lines", then it might make sense to have the phone number not be an attribute of a person, however, that same phone number might be a good key to some table in the implementation of the system, so putting in the phone number as a foreign key might make a lot of sense even in that scenario.

No noun we are modeling is an entity or an attribute by itself. Declaring one an attribute of the other is simply the declaration of a relationship between these two modeled "entities".

As you point out, the model depends on the use -- the software applications. Some theorists pretend that we can model without regard for applications -- as if there were "generic relationships" we should be modeling. The idea is that we should model "reality" and then our dbms implementation is independent of the applications that use it. This doesn't seem to pan out, resulting in unnecessarily inflated data models. Imagine if a company that is not involved in the phone business thought about how phone numbers were not attributes of people and decided to add a PhoneLines table to the mix right up front. How would this be helpful? One could speculate that someday the company might be involved in the phone business. Sure, but ...

Another way to say this is that just as with most design, what we leave out -- the white space -- is as important as what we put in.

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

With XP and other "agile" methodologies, one concept is to design for what you are implementing and not for every future possibility. This keeps your design cleaner and it works well provided that a) it is not taken to the extreme when developing a new system - it is a good idea to think past your nose when designing and b) the tools used make for "agile" changes (sometimes all clumped under the term "refactoring") when developing solutions for the next set of requirements.

This approach acknowledges the white space and doesn't clog a design with details that might never be needed. It seems counter to what are typically considered to be RDBMS "best practices", however. IMO the advent of the RDBMS along with its best practices have contributed little to our speed and flexibility in software development.

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

Declaring something an attribute is to declare a relationship.

> I'm being intentionally vague about whether the right design and
> implementation involves using the RDM and SQL or some other scheme.

I should try that sometime ;-)
smiles. --dawn Received on Wed Mar 23 2005 - 16:22:38 CET

Original text of this message