| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
Home -> Community -> Usenet -> comp.databases.theory -> Re: Relational vs network vs hierarchic databases
"Laconic2" <laconic2_at_comcast.net> wrote in message
news:I-Wdne2w-sDxMQLcRVn-1Q_at_comcast.com...
>
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message
> news:cnib1t$l0l$1_at_news.netins.net...
>
> > > Not really - why does Pick have files, then, rather than a single
> > > graph?
> >
> > From the users perspective, they view everything they are looking for
> > through a single file at a time. The graph of data looks to the
end-user
> as
> > a single file and to the developer as a node through which you can
> traverse
> > to any other node of interest. The Pick approach to a graph definitely
> has
> > flaws, but performance definitely isn't one of them.
>
> Did "users" not mean "end-users" in the above?
> [snip]
Yes that was my intent, but "the person interacting with the computer (the IT professional modeling the data)" below was not the end-user.
> > Agreed. I'm interested in the interface between the machine and the
> person
> > being useful and easy to use for the person. The machine itself can
think
> > like a machine, and the person can adapt to think more like a machine,
but
> > to minimize errors we can present a user interface that is as intuitive
> for
> > the human as feasible. So, if relations are something the computer
likes
> > for implementing an organization chart, that's fine, but does the person
> > interacting with the computer (the IT professional modeling the data)
need
> > to think like the computer?
>
>
> Did "person" not mean "end-user" in the above?
No -- it was the developer, which is the reason for the parenthetical comment in an attempt (failed, apparently ;-) to make it clear.
My questions and point were directed toward the following argument related to data modeling and database design:
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? 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?
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.
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".
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 Received on Sat Nov 20 2004 - 18:53:40 CST
![]() |
![]() |