Re: What is analysis?

From: David Cressey <cressey73_at_verizon.net>
Date: Wed, 05 Dec 2007 19:34:09 GMT
Message-ID: <R2D5j.8150$VJ.959@trndny05>

"paul c" <toledobythesea_at_ooyah.ac> wrote in message news:OoB5j.1365$sg.1361_at_pd7urf1no...
> David Cressey wrote:
> > "Jon Heggland" <jon.heggland_at_ntnu.no> wrote in message
> > news:fj641f$m36$1_at_orkan.itea.ntnu.no...
> >
> >> Bob Badour answered this; I'll just add a quote from Date's
Introduction
> >> to Database Systems (2004):
> >>
> >> In his [1970] paper, Codd uses the term /time-varying relations/ in
> >> place of our preferred /relation variables/ (relvars). But
/time-varying
> >> relations/ is not really a very good term. First, relations as such are
> >> /values/ and simply do not "vary with time" (there is no notion in
> >> mathematics of a relation having different values at different times).
> >> Second, if we say in some programming language, for example, DECLARE N
> >> INTEGER ; we do not call N a "time-varying integer", we call it an
> >> /integer variable/.
> >>
> >> (End quote)
> >
> > Thanks for the above I'm going to try to incorporate "relvar" into my
> > vocabulary, at the expense of misusing it several times in public. Be
> > forgiving, while correcting me.
> >
> > So far, I see at least one way in which the terminology can help my
> > thinking.
> >
> > There is no particular reason why a relvar has to be either persistent
or
> > stored in a database.
> > This allows one to discuss the logical features of data that is shared,
> > whether or not that sharing is mediated by a database and a DBMS. It's
> > always seemed to me that much of "database theory" has really been
about
> > "the theory of data sharing" rather than about storage, retrieval, and
> > persistence as such. Many of the more interesting discussions in this
> > newsgroup would still be interesting even if the data were transferred
from
> > one partner to another over some kind of "message bus" and never stored
in
> > a database at all!
> > ...

>

> From what I've read, both sets of comments above are accurate, maybe
> even profound. I suspect even the original implementers who had some
> access to Codd were prone to bring conventional implementation issues to
> the table that he wasn't addressing, concurrency being the one that they
> usually meant to have to do with "data sharing". There's a shorter more
> inclusive word for that, ie., "time". The passing of time encourages
> confusion in other ways besides relation values, such as integrity, let
> alone the behaviour of procedural/imperative languages. One of my pet
> peeves is how concurrency theorists often mention "time" and "locks" in
> the same breath and don't talk about a relational way, such as
> constraints, to eliminate time in the first place, at least
> conceptually. I'm pretty sure that not much of a fundamental nature has
> changed in that area since Gray's papers of more than twenty years ago,
> every so often a new technique will crop up that is just a form of what
> I think of as application locking, eg., escrow locks. Some apps I've
> seen spent almost as much code to deal with system exceptions as they
> would have if they addressed specific concurrency requirements in the
> app design.

>

> Just trying to say how I think dealing with time could be a more
> flexible vantage point to analyze an app from than data sharing,
> especially with regard to constraints. When people talk of
> transactions, it seems implicit that constraints, or assertions if you
> will, are logically "committed" even if they are not necessarily stored
> with tuple changes. Escrow locks are just one flavour of application
lock.

>

> Sorry for thread drift, couldn't resist. At least you've all been
> spared from several posts I made about analysis. They seem to have
> fallen into a bath of ether acid as my news feed has been broken for a
> couple of days.

I'm just about talked out concerning analysis, anyway.

The next guy who wanders in here and suggests using ER in place of RM will get the short version from me: "if you aren't doing analysis, and you can use RM, and your target is a relational implementation, don't use ER." Received on Wed Dec 05 2007 - 13:34:09 CST