Re: What is analysis?

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)

 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