Re: Terminology for composite attributes

Because you seem a bit critical of the conceptual model, my previous question: "how did you arrive here" was motivated by C.J. Date's "The normalization discipline involves reducing large relations to smaller ones... But the normalization discipline has absolutely nothing to say about how we arrive at those large relations in the first place."
There are people (sometimes including myself) who have the habit of presenting the design of a db with only the Relational Model (tables, etc) with the idea that "I know that people know that I know about the Conceptual Model".
We should start with the Conceptual Model. But again, according to C.J. Date: "it is impossible to state with any precision exactly what an entity is and what it is not".
Obviously, C.J. Date illustrates a state of the DB science. So my question is, in fact, where one should begin making changes to an existing DB - in the Relational Model or in the Conceptual Model. I prefer to make structural changes starting with the Conceptual Model. (However, for example there is mapping between XML and Relational data models and this mapping supports changes of schema. This, for example, enables the use of XML as cheaper data storage.). How can we define an entity's attributes, considering that an entity is not clearly defined? It seems to me that the names "composite attributes" and "multivalued attributes" can be confusing because of the fact that the concept of an attribute isn't clear enough. Maybe there are more meaningful terms? One way to work with Multi-valued and Composite Attributes is by using a pair (primary key, foreign key). In E/R there is no explanation about what the meaning of this pair in the "real world" is. In the Relational Model this pair is a link between information stored in two relations - some kind of possibility to go in to the details.

Vladimir Odrljin Received on Thu Mar 24 2005 - 20:42:23 CET