Re: What is analysis?

On Dec 5, 12:28 pm, "David Cressey" <cresse..._at_verizon.net> wrote:
> "TroyK" <cs_tr..._at_juno.com> wrote in message
>
> news:093fb5b1-df05-454a-80e5-ae59dd962e9e_at_d27g2000prf.googlegroups.com...
>
>
>
>
>
> > On Dec 5, 8:25 am, "David Cressey" <cresse..._at_verizon.net> wrote:
> > > "Jon Heggland" <jon.heggl..._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!
>
> > > So adding "relvars" to my vocabulary will allow me to think, at least
> > > primitively, about logical relational models at the application level
> and
> > > not just at the database level. It seems to me that this is where the
> > > battle between relational enthusiasts and object enthusiasts is really
> being
> > > waged, anyway.
>
> > You may be interested to check out the "Dee" project here:
> >http://www.quicksort.co.uk/DeeDoc.html#relations
>
> > An in-memory Python relational implementation "Inspired by
> > Date and Darwen's Databases, Types and the Relational
> > Model (The Third Manifesto)..."
>
> Thanks.
>
> > I've used a "relations as first class programming citizens"
> > programming model to very good effect for iterative application
> > development.
>
> Did you mean "relvars as first class programming citizens"? Sorry to be so
> picky, but I really am trying to come up to speed on the term "relvars".
>

Both relvars and relations, I suppose. It would be analogous to saying "objects are first class programming citizens" when one might really mean "classes". In other words, I'm speaking rather loosely which probably isn't helping you to understand the relvar/relation distinction at all.

> Regardless of the answer, I'm interested in your expriences. Are there any
> programming languages that support relvars?
>

For programming languages that support relvars, the link I gave to the Python "Dee" project could qualify, but I perceive that as more a library "on top of" Python as opposed to native support. Not sure if that's an important distinction, though.

Alphora might qualify, but I have only a passing familiarity with the product, so I can't say for sure. I'm pretty sure there are some participants on the list with direct experience who can shed more light than I'm able.

As far as my experience goes (and to further muddy the waters, sorry), I design using relvars and relations, but implement using SQL tables. The implemenation serves as a usable prototype that allows the application programming team to see what behaviors, rules, and derivations their classes will need to support when implementing the so-called "object model" in code (say, C#, for example).

Working at a higher abstraction level (even given the pitfalls of SQL) allows me to iterate over design and implementation very quickly and arrive at a provably correct design -- at least in the context of the current problem. Then it's just a matter of converting the resulting tables (relvars) into analogous classes.

Now, what would be really cool is to not have to do that conversion (along with the 1-2 orders of magnitude more code) to the classes. In other words, some form of native support for declaring and manipulating relvars. That's why the "Dee" project is interesting to me. As Paul mentioned, it would be nice to see a similar effort on a more widely adopted dev platform (my bias being towards .NET).

HTH,
TroyK Received on Wed Dec 05 2007 - 22:12:37 CET