Re: Relation or attribute and why

Gene Wirchenko wrote:
> On 23 May 2006 03:41:44 -0700, "Tony Andrews" <andrewst_at_onetel.com>
> wrote:
>
> [snip]
>
> >Occam's razor? There is no gain (that I can think of) in separating a
> >person's name into a separate table Name that has a 1:1 relationship
> >with the table Person, while there is a cost in terms of complexity.
>
> A person's name? Which one? I have two: Eugene Michael
> Wirchenko and Chen Jin Bai.

Is it a set of names or is there a priority ordering you would give to the list. I have seen formerNames as a list-valued attribute (in systems which have such), with the ordering being relevant. This is an expansion of what many might have as a maidenName attribute.

In response to Tony, I agree that other than collecting multiple names, there is nothing to be gained. So we derive the name and store the parts (first, last, middle), whereas with the date, we store the date and derive the parts (month, day, year).

What is practice that we used to decide to produce a logical data model in this way, sometimes dumping nouns that are collectives from the CDM, sometimes dumping the parts, when preparing the LDM?

If the rule of thumb has to do with "the simplest" then is there a logical distinction for why deriving the name is simplest in the one case and deriving the date parts is simplest in the other or is this based on the tools used (having date as a built-in type, but not name, for example)? --dawn Received on Tue May 23 2006 - 19:37:04 CEST