Re: Terminology for composite attributes

From: vldm10 <vldm10_at_yahoo.com>
Date: 26 Mar 2005 12:16:58 -0800
Message-ID: <1111868218.778158.200470_at_g14g2000cwa.googlegroups.com>

David Cressey wrote:
> "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.

Just a few words on this topic.
The author of E/R Model, P.P.S. Chen, in his paper, explains what an entity is,
"An entity is a "thing" which can be distinctly identified." In addition to this sentence, in the introduction of this paper there is another sentence which somewhat involves what an entity is: "The entity-relationship model adopts the more natural view that the real world consists of entities and relationships" If we go back 60 years, we find that the mathematician Alonzo Church wrote about a theory of another mathematician Gottlob Frege from the 19th century. Here, a definition of a thing is given: "The word thing in its widest sense is used in short for anything nameable."

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

Here is one ad-hoc solution. I have two entities and a Relationship between them, linked using PersonName:
Person (PersonName,....)
Phone (Phone_ID, PersonName, PhoneNumber, PhoneType, DateStart, DateEnd)

Here are few tuples for some possible situations for a person named Paul Jones;
The first three tuples are installations of home, computer and cell phone/lines.
The fourth and fifth cancel one phone number and open a new one. The sixth is because the phone line was broken for some random reasons and the seventh tuple starts to use the same number again.

(51, Paul Jones, 333-4444, Home,       3/6/04,   0)
(52, Paul Jones, 333-5555, Computer,   3/6/04,   0)
(53, Paul Jones, 333-6666, Cell,       3/6/04,   0)
.   .   .
(74, Paul Jones, 333-4444, Home,       3/6/04,   4/10/04)
.   .   .
(81, Paul Jones, 333-7777, Home,       4/11/04,   0)
.   .   .
(86, Paul Jones, 333-7777, Home,       4/11/04,   8/8/04)
.   .   .
(97, Paul Jones, 333-7777, Home,       16/8/04,   0)

. . .
If we want, we can add a new entity
Address (Address_ID, PersonName, StreetNumber, Street, ...) instead of a second composite attribute in Person. This solution can easily support a change of StreetName or of another attribute. I can find the Person if he changes his address, etc. It is easier to protect display,... these data.
So your comment that a relationship has been modeled as an attribute is ok.
Dawn's question was only about the best name for composite attributes.
But if she had asked for a DB solution and if the DB were not a simple one, I would prefer to do things this way. It seems to me that it's more like a Relational DB than Relational Storage.

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.

Vladimir Odrljin Received on Sat Mar 26 2005 - 21:16:58 CET