Re: Terminology for composite attributes

vldm10 wrote:
> dawn wrote:
> > vldm10 wrote:

<snip>
> My point was to see if there is "mapping" between the Conceptual
> Model (CM) and the Relational Model (RM) in the sense that, if you
made
> changes in the existing RM, can you, in any case, come back and make
> those changes in the CM. I gave an example of mapping between XML and
> Relational data models (which works). I had previously said that I
> prefer to make structural changes staring with the CM. I had also
> quoted C.J. Date that some of the main concepts of the CM are not
> defined well enough.
> You work with changes in the RM with composite attributes, but
> "composite attributes" is a term from the CM.

Ah, I think I see the gap here -- the logical model I typically work with is not the RM, so I am not restricted to terms used there, although I want to be clear with my terminology.

In my example, the conceptual model included a mapping of Phone Types as being in a relationship with PhoneNumber, with these together applying to a Person (whether correctly or incorrectly -- any questions about whether this mapping is correct belong, in my use of terms, to conceptual modeling). Coming into the logical modeling arena is now a "change request" for entity "A" to have an attribute composed of "B" (which was already declared an attribute of A) plus "C" (which is new on the scene). So my question was entirely in the logical model realm, whether that logical model be relational or not.

> Additionally,
> entities and attributes can be better observed in the CM. So my idea
> was that the changes in the RM should be mapped back into the CM, and
> then to think about what names to assign them.

I agree that thinking about the naming starts in the conceptual model and is only brushed up (in whatever ways Celko will describe in his new book ;-) in the logical model.

> Normalization is
> allowed, but it should be done correctly. For example, if you do
> normalization with existing data, then it is ok. If you add a new
> attribute (or more than one) to your existing DB and put that
attribute
> directly into the RM (skipping the CM)

I always first model conceptually -- in fact, I would think that whether in their heads or "on paper" everyone does. That is where the meaning of the terms gets mapping to something.

> and apply normalization, then,
> you don't need the CM. But then we can apply C.J. Date's question,
> "how did you arrive here?" Another interesting example can be the
> addition of a multivalued attribute to the existing database,

Yes, this is something I do regularly, with little effort, as do all those working with XML or older models. The model that is specified for the dbms is also a logical model -- the "final" logical model, on the one hand (it is not the physical layout of the data) but might include changes to THE logical model based on tradeoffs related to the implementation environment. I typically call that one that the physical model or the implementation model -- what do you call that model? Is that what you are calling the logical model?

> considering that it causes two new relations.

in your logical model of choice, but not in mine. Date's new def of 1NF might also lead one to model multivalues in the same relation, but most sql-dbms implementations would discourage it due to lack of support in odbc/sql-92, for example

> So my point was, in
> general, about "mapping" from the RM to the CM.

I might go that direction when trying to understand an existing dbms implementation, otherwise I go from "reality" business domain to CM to LM to IM (or PM) which the dbms software changes to a PM.

> Hope that my point
> is now more clear. Just want to clerify this.

Yes, that helps me understand how you use the terms. Did my explanation help or does this way of talking about it sound way off the beaten path?

Thanks for your time on this -- it is definitely helpful. --dawn Received on Fri Mar 25 2005 - 18:13:55 CET