Re: foundations of relational theory?

"Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> wrote in message news:bngh9n$c20$1_at_nyytiset.pp.htv.fi...
> Marshall Spight wrote:
>
> >"Tony Gravagno" <g6q3x9lu53001_at_sneakemail.com.invalid> wrote in message
news:dvh0pvo70vrue56jma8gkjotmnu9gm8vtu_at_4ax.com...
> >
> >
> >>This must sound horrifying to you relational guys, but again, we don't
> >>view the system primarily as a database with applications supporting
> >>it. We view the application as a having the database as one of its
> >>components - unless the application needs a reference in the
> >>dictionary it doesn't get one.
> >>
> >>
> >
> >Hypothesis: PICK systems work well for application development
> >because of excellent application development tools and tight
> >integration between the application language and the DBMS.
> >Agility is enhanced by the fact that some of the more complex
> >possibilities for data models, such as many-to-many relationships,
> >are simply excluded. In contrast, SQL DBMSs, while having a superior
> >theoretical basis and a data model that can handle arbitrarily complex
> >relationships, are hampered by having no standardized application
> >builders or tools. In addition, SQL is particularly hampered
> >by the fact that its core data structure, the multiset, has no
> >corresponding entity in popular programming languages, causing
> >a huge conceptual gap, or "impedence mismatch" between DBMS
> >and application languages.
> >
> >I'm not saying this is true or not, but it seems consistent with
> >what I've read in this thread. Anyone care to critique?
> >
> >BTW, if my hypothesis holds, it suggests (to me, anyway)
> >that the right way to respond is to try to understand the
> >best of each; the benefits of RAD that come with good
> >tools and integration in PICK land and the superior
> >theoretic foundation that relational (the
> >"inspiration for SQL" :-) has.
> >
> >Anyone care to critique?
> >
> Hey, I think you have hit the point. I can understand, that those who
> are used
> to building applications (like the PICK folks) within one conceptual
> environment
> would feel that going to SQL + [your favoring programming language] would
be
> a step backwards because of mismatch. And they would be right, in a
sense.
>
> And it is in that light that I see the complaits of SQL (and by
> implication of relational).
>
> This is also the reason for interest in OODB's: the desire to stay in
> the same environment.
>
> The other way to approch the mismatch problem is to extend the
> relational environment
> towards the app side. However, it looks like computer scientists look
> at the world
> from either a db-perspective or a programming perspective and these
> views don't
> seem to combine. Why this is, is a mystery to me. Just to quote
> Jayadev Misra in
> http://www.cs.utexas.edu/users/misra/Speeches.dir/Schlumberger.Jan02.pdf:
>
> "In this context, let me suggest a problem worthy of your attention. The
> fundamental
> structuring principle for systems is hierarchical organization. It
permeates
> the world around us; social and political systems are hierarchical. We
have
> found from experience that tree-structured file systems, hierarchical
> organization
> of large domains such as the internet, and system designs in which each
> component
> itself is regarded as a system, is convenient. Even within object-oriented
> programming, the notions of components and encapsulation impose
hierarchical
> structures.
>
> Is it time to consider a more democratic structuring principle, similar
> to what
> they have in relational databases? I am driven to these considerations
> by the need
> to view a system from different angles. I can look at this building
> floor by floor,
> or by its electrical, plumbing and computational infrastructures, or by
> the people
> who work here by their professions. I would like to slice the same
> system in a
> variety of ways depending on which aspect of it I want to study. I would
> like
> to see my file system not only as being hierarchical but also providing
> groupings
> according to other criteria: all files that constitute the chapters of a
> book ought to
> be arranged in a sequence so that I can read from Chapter 3 to 7, say. I
> would
> like to see the list of all printers in the campus, even when the campus
> network is
> organized by departments. How do we support multiple views of a system
while
> retaining the advantages of hierarchical structuring? How do we exploit
> multiple
> views during program design and evolution?"
>
> Now (as pointed out previously in this newsgroup by Paul Vernon) why does
> he say "...what *they* have in relational databases"? Does he not
consider
> db-science as part of computer science?
>
> And secondly, he is in search of something "similar to what they
> have...". Why
> do we have to reinvent the wheel? Why not use something that's there?
>
> Of course the same applies the other way a round: why don't
> db-scientists try
> to think of how they could better help in application building. They
> are, after all
> the raison d'être of databases (well, at least 99% of databases). Why
> is there
> this gap?

While I have observed the phenomenon of application developers looking at data management as foreign, I have not observed the converse. The relational answer to mismatch is to increase the level of abstraction of the application development environment to the level of the dbms. Received on Sun Oct 26 2003 - 15:22:05 CET