Re: Relation or attribute and why

dawn wrote:
> 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

Presumably if Name were a built-in type then one might use it. However, it is no surprise that Name is not a built-in type since (a) there is no clear, agreed answer to what comprises a name, and (b) there are no clear and agreed operators or "methods" associated with names. A built-in Date type is very useful, because everyone agrees that 31-Feb-2006 is not a valid date, and everyone agrees that 31-Mar-2006 plus 1 day = 01-Apr-2006. Of course, not everyone would like to see those dates written in that form, which is another useful feature of a built-in Date type: it can display dates in various different formats, including different languages.

If you didn't use the built-in Date type then you would take on yourself the responsibility of rejecting (31, 'Feb', 2006) as a valid date value, and so on.

You could of course (where the DBMS permits) define your own Name datatype with associated attributes and operators, so that Name becomes a single column in your table. But you might decide it wasn't worth the effort. Received on Tue May 23 2006 - 22:25:15 CEST