Re: One-To-One Relationships

From: JOG <>
Date: Fri, 30 Nov 2007 07:01:10 -0800 (PST)
Message-ID: <>

On Nov 30, 12:45 pm, "David Cressey" <> wrote:
> "paul c" <> wrote in message
> news:CIE3j.71657$cD.40518_at_pd7urf2no...
> > Bob Badour wrote:
> > > David Cressey wrote:
> > >> "Bob Badour" <> wrote in message
> > >>news:474dd64a$0$5285$
> > ...
> > >>> Entities are figments of our imaginations.
> > >> You are an entity.
> > > Am I? Or am I billions of cellular entities? Or am I part of a larger
> > > community entity?
> > I can't imagine how to store an entity. When I hear of it having been
> > done, I just pretend I heard tuple instead, even though I admit I can't
> > imagine how to actually store a tuple. All I know how to do with a
> > machine is mimic assignment. I think Codd was prepared to exclude
> > pronouns, too.
> > As far as a db model goes, entities seem to have use only as
> > conversational devices, as you implied and as David C demonstrated!
> > Tuples might not seem any better, but at least we can imagine how they
> > are applied by operators.
> Your comment goes back to discussions we've had concerning modeling and
> design going back years in this newsgroup. I'm going to repeat things I've
> said before.
> When I first learned database design, the way I learned it was three level:
> conceptual modeling, logical modeling and design, and physical design.
> For historical clarity, I learned this in about 1984. I will not claim
> that it was "leading edge" at the time.
> The ER model was used for conceptual modeling. The "entities" and
> "relationships between entitities" discussed in the ER model are not (in
> this context) stored in the database. They are entities and relationships
> that exist in the real world, at least in the mind of the subject matter
> experts. The data values to be stored and delivered by the database
> describe these entities and relationships. The entire model serves to
> discuss the information requirements with SMEs, clients, even prospective
> users, without getting specific about what form they are going to take when
> stored or when presented.
> Tuples don't get mentioned in the ER and this is intentional. The database
> design is not bound, at this point in time, to a relational design.

This is interesting David. Perhaps it infers the distinction (which I christen henceforth as Jim's law):

ENTITY PROPONENT: Does not believe a particular conceptual model should not bound to a specific logical one. TUPLE PROPONENT: Does not believe a particular logical model should be bound to a single conceptual one.

Any takers?

> So far, I think this is exactly what you have pointed out.
> The logical model was relational (unless your implementation target was
> something like CODASYL). The logical design was phrased in terms of tuples
> and relations. At this point, the design and implementation have been
> bound to a relational environment but not a specific DBMS product. Although
> specific products might store rows and columns instead of tuples and
> attributes, the distinction was more one of terminology, not fundamental
> concept.
> So tuples, unlike entities, do get stored in databases, although perhaps
> under another name.
> The physical design was DBMS product specific, and includes features (like
> tablespaces) that are unique to that product. As well, the design takes
> into account such issues as volume, traffic, resources, and speed. These
> issues are typically not addressed in the logical design, although issues
> like normalization have an indirect connection to them.
> The way I learned it did not contemplate logical data independence. I
> learned what little I know about that, much later. It did contemplate
> physical data independence.
> Paul C,
> I think this largely repeats what you already know. I jsut thought I wold
> make it explicit.
> BTW, I don't think that the way I learned it in 1984 is necessarily the
> right way for a beginner to learn the same material in 2007.
Received on Fri Nov 30 2007 - 16:01:10 CET

Original text of this message