Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Terminology for composite attributes

Re: Terminology for composite attributes

From: vldm10 <vldm10_at_yahoo.com>
Date: 25 Mar 2005 08:19:24 -0800
Message-ID: <1111767564.057047.39710@g14g2000cwa.googlegroups.com>


dawn wrote:
> 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.

My point was to see if there is "mapping" between the Conceptual Model (CM) and the Relational Model (RM) in the sense that, if you made changes in the existing RM, can you, in any case, come back and make those changes in the CM. I gave an example of mapping between XML and Relational data models (which works). I had previously said that I prefer to make structural changes staring with the CM. I had also quoted C.J. Date that some of the main concepts of the CM are not defined well enough.
You work with changes in the RM with composite attributes, but "composite attributes" is a term from the CM. Additionally, entities and attributes can be better observed in the CM. So my idea was that the changes in the RM should be mapped back into the CM, and then to think about what names to assign them. Normalization is allowed, but it should be done correctly. For example, if you do normalization with existing data, then it is ok. If you add a new attribute (or more than one) to your existing DB and put that attribute directly into the RM (skipping the CM) and apply normalization, then, you don't need the CM. But then we can apply C.J. Date's question, "how did you arrive here?" Another interesting example can be the addition of a multivalued attribute to the existing database, considering that it causes two new relations. So my point was, in general, about "mapping" from the RM to the CM. Hope that my point is now more clear. Just want to clerify this.

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

Vladimir Odrljin Received on Fri Mar 25 2005 - 10:19:24 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US