Re: Relational vs network vs hierarchic databases

"Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message news:cnqsmk$j3t$1_at_news.netins.net...

> I know that I need to have clearer terms here, however, many people who
> think that an ERD is a good means at modeling the conceptual design
believe
> that then you "must" move that to a relational model. It is that step
where
> I am not in agreement. I do need to get my terminology very precise in
> order to make clear to what processes and/or data/metadata I am referring.
> Is there a good term for the step between conceptual data modeling and
> database schema design that would help?

I am not in agreement, either. And IIRC, neither was Peter Chen. Chen invented the ER model so as to enable design and implementation in more than one kind of data environment. A relational database was one choice, and there were others.

I think there are two bodies of opinion among the group you cite. The first is that ERD is only useful when you intend to do relational design. The second is that logical data base design should always use the relational model, regardless of what came before or what the implementation environment is going to be. I think it would be useful if you would deal with these two separately.

> By logical level are you meaning the interface between the software and a
> human and by the physical level are you referring to the interface between
> the software and the machine? Is it the "no reason" statement that is the
> problem since I have only tackled it from a few angles? Can you state
your
> objection?
>

To the first, No. I mean the interface between the database server and a client process.

To the second, not immediately, I'll mull it over.

> That's fine, especially since "natural thinking" is a very fuzzy term.
When
> I put the content behind the "how we think", I'll likely refer more to
> language -- we don't all think alike but the interface from one person's
> thinking to another is via language.

You have to extend the notion of "language" to iconography, or whatever the word is. The GUI would never have been as popular as it is if people did not think in images.

> > It's not clear that the examples you cite are "successful". What is
> > success?
>
> At least this -- that if SQL were able to ask the question and retrieve a
> result set, then these languages could do so as well, so they are at least
> as complete as SQL.

Again, what is "Well"?

BTW, if there were a relational interface language that were better than SQL, how would that influence your thinking.
> > Simplicity, power and demonstrated worth are reasons to stick to one
> > compound.
>
> Other models had demonstrated worth prior to "relational theory".
Although
> think it is good to standardize, the problem I'm addressing is that the
cost
> of ownership for enterprise level software has skyrocketed during my
tenure
> in this industry, in spite of the cost of hardware plummeting.

This is certainly true. But I am yet to be convinced that the relational model is the culprit.

> maintaining information systems. There is no proof that relational theory
> is the simplest approach for this activity.

> > Again, I'm not prepared to abandon the relational model, until there is
> > something demonstrably better.
>
> Nor I. It works for me to "make new friends, but keep the old" in this
> case.

Agreed.

> Once I cover logic and intuition, the key thing that I have no clue how to
> get (although I considered many options) is empirical data that would be
> accepted by even a fraction of those working in the database world as
being
> useful. For professionals who have only worked with RDBMS products (a
> significant percentage, I'm guessing), what data would be convincing IF
> there really were better models? How could we come up with an experiment,
> survey, or whatever, that would test out different data models? There are
> too many other factors to which any conclusions would be subject.
>

I think that history shows that major improvement go through a long period of acceptance and refinement by the pioneers followed by rapid acceptance by the mainstream. e.g. "Object Oriented Programming". For a quarter of a century, from 1964 to 1989, OO was being practiced by a few, but was all but ignored in the mainstream. Then, in the 1990s, the mainstream went OO.

Separating out variables is one of the major problems, I agree. Received on Mon Nov 22 2004 - 13:32:26 CET