Re: What is analysis?

From: paul c <>
Date: Wed, 05 Dec 2007 17:41:02 GMT
Message-ID: <OoB5j.1365$sg.1361_at_pd7urf1no>

David Cressey wrote:
> "Jon Heggland" <> wrote in message
> news:fj641f$m36$

>> 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. Received on Wed Dec 05 2007 - 18:41:02 CET

Original text of this message