Re: One-To-One Relationships

From: paul c <toledobythesea_at_ooyah.ac>
Date: Fri, 30 Nov 2007 17:23:04 GMT
Message-ID: <YFX3j.7704$UQ1.5644_at_pd7urf1no>


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

No big argument with that, although I'm sure some technocrats would love to embellish your words, parse them to death and say "bound" as often as possible for more logical "cred". As you hint, maybe there were influences in those times that made it appealing (eg.,to maintainers of organization charts), like the structured movement and all those passive dictionaries and those woolly social engineering consultants who were coming into fashion.

I'd like to add that I've always found logical modelling much more laborious, not to mention necessary. Always seemed that it wasn't until one delved into what operators were applied to the ER data that one was really sure what data was needed. Some outfits then wanted to re-visit their ER pics, don't ask me why, just a way to postpone the inevitable it seemed. Received on Fri Nov 30 2007 - 18:23:04 CET

Original text of this message