Re: One-To-One Relationships

"paul c" <toledobythesea_at_ooyah.ac> wrote in message news:CIE3j.71657$cD.40518_at_pd7urf2no...
> Bob Badour wrote:
> > David Cressey wrote:
> >> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
> >> news:474dd64a$0$5285$9a566e8b_at_news.aliant.net...
> >>
> ...
> >>> 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?

>

>

>

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.

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 - 13:45:21 CET