Re: Terminology for composite attributes

"vldm10" <vldm10_at_yahoo.com> wrote in message news:1111693343.157087.95750_at_f14g2000cwb.googlegroups.com...

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

In my opinion, reality is objective, but ontology is subjective.

It think the conceptual data model is also subjective, and that's probably why it irritates some of the more logical thinkers in this forum. Alfredo might be an example of someone who has little use for the conceptual model, or at least the ER model.

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

I'm in agreement with you.

In particular, with regard to the case that Dawn outlines: "the requirements have changed", my plan is this: to recapitulate (quickly and inexpensively) the entire process by which the original concept was turned into a reality.

Thus, at one stage, one revisits the conceptual model, to see if the revised requirements should cause any alteration to the conceptual model or not. If not, fine. But, if so, it's worth udpating the conceptual data model (e.g. ER) so that it's current.

The idea of brininging the DB as implemented into conformance with revised requirements without updating a conceptual model reminds me of patching executable files without maintaining the source.

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

Yes, but...

When I'm "thinking relationally" I'm tempted to view "invoice headers" and "invoice details" as belonging in different relations, with different keys. In the ER model, I'm inclined to to say: "An invoice has one or more detail lines" and let it go at that.

One could argue that "has" is a relationship between invoices and invoice details. In a way, this is no different from my argument that "Phone Number" is not an attrubute of "Person" but an attribute of a related entity. Such an argument would be true, but not useful, in most contexts.

The context I'm thinking about is communication between several people who are going to be impacted by the design and implementation that follows. This includes:

People who deal with invoices on a daily basis, rarely if ever deal with data modeling, and never deal with "ontology" (at least at the verbal level).

People who model data and design databases.

Programmers who build applications that use databases to store and retrieve values.

DBAs who administer the database on a daily basis.

Customers who pay for all of the above.

If you want to preserve communication among all these stakeholders, then "composite attributes" MIGHT be a less confusing concept that "foreign keys and simple attributes". I say "might" because I'm not convinced. But I'm open to that discussion. Received on Fri Mar 25 2005 - 14:50:01 CET