Re: Terminology for composite attributes

vldm10 wrote:
> 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

This with Address is wrong, sorry about this.

> 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

Vladimir Odrljin Received on Mon Mar 28 2005 - 06:46:44 CEST