Re: Relational vs network vs hierarchic databases

"Laconic2" <laconic2_at_comcast.net> wrote in message news:O4CdncuGUdSw6T3cRVn-uw_at_comcast.com...
>
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message
> news:cnooup$puq$1_at_news.netins.net...
>
> > My questions and point were directed toward the following argument
related
> > to data modeling and database design:
> >
> > 1. A human being at least sometimes will find it easier thnk in terms
of
> a
> > variety of structures for stored data rather than use relations as the
> only
> > compound structure. There are times when a person might want to think of
> the
> > data in terms of a tree or graph. Do you agree?
>
> Agreed, with one caveat. Easier thinking is not always better thinking.
> Design is not necessarily a natural act.

Agreed & Agreed.

>
> > 2. Developers, data modelers, and DBAs (and any other roles interacting
> > with a database or DBMS) are human beings (I won't ask for agreement on
> > that one)
>
> I disagree. There are roles that have become part of the system's
> responsibility.

I suppose one can call a piece of software by these names too. OK, how 'bout this -- the developers, data modelers, and DBAs about whom I am concerned are the people with whom the DBMS software interfaces (they are not, themselves, software).

> > 3. Computers are sophisticated enough that they could provide an
> interface
> > for the data model that is more natural for the IT professionals who are
> > users (developers, data modelers, DBAs, for example). Is that correct?
>
> Again, natural may or may not be better.

Agreed.

> > 4. Therefore, there is no reason to insist that in the interface
between
> > human being and DBMS for the purposes of modeling an designing
databases,
> > relations should be the only compound structure (that would have to be
> > defined for this to be a rigourous argument, but bear with me).
> >
>
> No problem about rigor, as long as I know, or think I know, what you're
> talking about. This is a discussion, not an oral exam.

Yes, indeed.

> I am not sure that I agree with "no reason". You might argue that there
is
> "insufficient reason".

Fair enough.

> You may want to add "conceptual design", where even I don't insist that
the
> relational model is the only sucessful model, or even the best model.

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?

>
> > Then my second line of questions is this:
> > 1. The relational model is intended at the logical level and does not
say
> > HOW a DBMS should be implemented. Is that correct?
>
> I think the word "logical" has become overloaded in the c.d.t. Many years
> ago, the term "logical layer" was used to mean approximately "exposed to
> the programmer", and the term "physical layer" was used to mean
"unexposed
> to the programmer". Now, I think it's used to mean much more, although
I'm
> sometimes mystified as to exactly what it's supposed to mean.

I agree -- I will need to be more precise before writing this up more formally.

>
> > 2. Therefore, relations need not be the only compound construct used in
> the
> > interface between the DBMS or any database-related software and the
> machine.
> > Agreed?
> >
> > Therefore, for the purposes of data modeling and data(base) design,
there
> is
> > no reason for relations to be the only compound construct at the logical
> nor
> > the physical level. Do you agree?
>
> I don't agree at the logical level. At the physical level certainly
agreed.

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?

>
> I am not sure that logical thinking and natural thinking are all that
> similar.

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.

> >
> > On the query side, relations provide us a means to stick to a subset of
> 1st
> > order predicate logic (which I've been reading up on a bit), so some
> suggest
> > a need for only relations as compound structures for querying. However,
> > there are examples, such as XQuery and the old MultiValue query language
> > that demonstrate the ability to query data that has compound structures
> > other than relations nested within relations. So, even if the theory is
> > simplified with only relations as our compound structures, it is proven
> that
> > is isn't necessary to stick to relations as the only compound structure
in
> > order to be successful with a query language.
> >
>
> 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.

> > This is just a high level outline of the arguments that are shaping up
for
> > me, but it is not hard to state these points more rigorously (requiring
a
> > glossary, thus my request for the current version). And then the
> conclusion
> > might be something like this:
> >
> > Since relations are not necessary for either the machine nor the human
> being
> > as the sole compound structure for data, there is no reason for us to
> stick
> > to what is current termed "the relational model".
> >
>
> 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. "Relational theory" provide simplicity in having only one compound construct (that is also not a precise term and I'm not sure how to make it precise other than working wtih the terms "scalar" or "atomic" with respect to built-in functions). However, they MIGHT NOT (this is still a educated-guess or unproven theory be the simplest from the perspective of building and maintaining information systems. There is no proof that relational theory is the simplest approach for this activity.

> Whether they are sufficient reasons is something you might want
> to argue.

Yup.

> 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.

> "Demonstrably" doesn't quite mean
> "proveably". The Wright brothers demonstrated that their flyer could fly.
> (Well, they didn't demonstrate it in public until years after the first
> flight, but I digress).

Digression is an art form appreciated by this reader.

>
> > I'm sure there are holes in a few places here, so please don't hesitate
to
> > point them out as I do want to ensure my reasoning is tight.
> > Thanks. --dawn
>
> This is better than what you were doing before. Earlier it just seemed
like
> yet another rant against the relational model.

I really do have some rigor in front of me, though it is that for which I have no rigor that I bounce off from this audience in an effort to clean up that which is blurry. I was really quite surprised when I started reading relational model works a couple of years ago, just how big the gaps were in the logic. I cannot do better than that with what I might propose, however, I can make it clear just WHERE I am making leaps in logic based on experience, intuition, surveys, or whatever.

Once I cover logic and intuition, the key thing that I have no clue how to get (although I considered many options) is emperical 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.

Cheers! --dawn Received on Sun Nov 21 2004 - 21:09:47 CET