Re: Terminology for composite attributes

vldm10 wrote:
> Because you seem a bit critical of the conceptual model,

I am absolutely fascinated with conceptual models, and didn't mean to imply otherwise. But my question was in what I'm caling the logical model, although I might not be using the terms properly. The example I gave distracted from, rather than enhancing the question so that David replied regarding the means of getting to the conceptual model in the first place. I liked his response too, even though off topic (I think) from what I intended to ask, so I addressed it in another branch of the topic.

> 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".

The classifications I'm using are conceptual model, logical model, and physical model, where the relational model could be a logical model as long as you are not talking about tables declared to a dbms, but about relations aside from the specifics of what tables are implemented.

> We should start with the Conceptual Model.

With this example, I'm starting at a point where there is a "completed" logical model. That is, whatever reality was being mapped for the work has been done (conceptual model) and a logical data model has then been derived by whatever means (for example, by normalizing). I am then adding a requirement that forces a change to the conceptual model, forcing also a change to the logical model. I agree that the requirement needs to be added to the conceptual model, but then one or more changes need to be made to the logical model to accomodate.

> 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.

The change to the conceptual model can drive a change to the logical model, if there already is one, and that logical model might or might not be a "relational model". I work with the logical model being more of an XML data model, for example (to yank a few chains).

> 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.).

and the XML data model is also ... (getting away from the point, I'll pull myself back)

> How can we define an entity's attributes, considering that an entity
> is not clearly defined?

the modeling process is not an algorithm -- there are many ways to model the same set of nouns, each of which might fit a different use for having such a model.

> 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.

Jan suggested "composite value" was often used and perhaps that clarifies a little bit?

> 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.

I think of it as a function mapping one proposition (or set of) to another.

Conceptual:
Entity: Person
I(PK) have a dog named Monte(FK).
Entity: Pet
Monte(PK) is a Bischon Frise.

This would be altered for a logical model given that there could be more than one Pet named Monte, of course.

> 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

I think I'm still missing your point and I apologize for that. By tossing in a new requirement for a existing scenario that has an existing data model, I need to change the existing logical data model. If I have just, conceptually, turned a PostalCode that was modeled as an attribute of Location into a PostalCode that includes what I modeled as PostalCode previously plus a new sometimes optional extension of 4 digits, then I have had a change to the conceptual model that (likely) drives a change to the logical model -- right?

Would you go along with the idea that I have now changed the arity of PostalCode from 1 to 2? It did have one "part" and now it has two "parts" to it? In the final logical model, there are many options so that the term "PostalCode" is an attribute that does not have arity > 1, but until I make the changes to the logical model, that is what I have, based on this change to the conceptual model. Does that work for you? Where am I using terms inappropriately or otherwise misconstruing it?

Thanks. --dawn Received on Thu Mar 24 2005 - 22:48:56 CET