 | |
#21
 
| |||
| |||
|
Re: What is analysis? -
12-05-2007
, 11:24 AM
|
"Jon Heggland" <jon.heggl... (AT) ntnu (DOT) no> wrote in message news:fj641f$m36$1 (AT) orkan (DOT) 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. |
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)..."
I've used a "relations as first class programming citizens"
programming model to very good effect for iterative application
development.
TroyK
#22
| |||
| |||
|
|
... where faculty were fooled into imagining that OO programming must have an analysis and design counterpart. |
interesting, but OOP is a waste of time.
Quote:
|
Much of that training was product-biased. Still, I met a small handful of analysts who were comfortable no matter the tools, might even write prototypes from time to time, in two or three different languages. By comfortable I mean they remained steadfastly concise in their explanations regardless of the concepts a tool or culture required them to manipulate. Whereas most practitioners I knew tended to regard a methodology as a recipe, not unlike one to cook Bouillabaisse. Also job security as unlike a chef, they didn't have to succeed every night. Not to disparage ER, but it is not a requirement for analysis. (Nor are predicates although it is notable that unlike ER, they are involved in the result.) |
once you have successfully coooked a Boullabaise, your goal is to get the
same result over and over again.
One typically applies a given methodology to problems one has never seen
before (although some patterns recur). So methodology is more like
"cooking a brand new dish, and having it come out right the first time.",
and doing that repeatably.
Quote:
|
What was really remarkable to me was that I worked with people who had as many as three math degrees who had never taken a logic course but knew only what SOL meant, not FOL! Once a database approached 1,000 columns, I found it was rare that any one person was responsible for any one aspect of its development, such as analysis of the whole system (apart from administrative functions such as change control), let alone who could explain all of its functions to a programmer as well as management. At that point, fences needed to be put up to maintain any kind of personal control, ie., to maintain the authority/peer respect needed for one to be seen as responsible for whatever aspect. I used to dream how nice and simple life would be if I could work on a system with only 300 columns. I hated mornings because the dreams ended then. |
across the fences.
And they aren't just administrative functions.
#23
| |||
| |||
|
|
On Dec 5, 8:25 am, "David Cressey" <cresse... (AT) verizon (DOT) net> wrote: "Jon Heggland" <jon.heggl... (AT) ntnu (DOT) no> wrote in message news:fj641f$m36$1 (AT) orkan (DOT) 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)..." |
Quote:
|
I've used a "relations as first class programming citizens" programming model to very good effect for iterative application development. |
picky, but I really am trying to come up to speed on the term "relvars".
Regardless of the answer, I'm interested in your expriences. Are there any
programming languages that support relvars?
Quote:
|
TroyK |
#24
| |||
| |||
|
|
David Cressey wrote: "Jon Heggland" <jon.heggland (AT) ntnu (DOT) no> wrote in message news:fj641f$m36$1 (AT) orkan (DOT) 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. |
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."
#25
| |||
| |||
|
|
"TroyK" <cs_tr... (AT) juno (DOT) com> wrote in message news:093fb5b1-df05-454a-80e5-ae59dd962e9e (AT) d27g2000prf (DOT) googlegroups.com... On Dec 5, 8:25 am, "David Cressey" <cresse... (AT) verizon (DOT) net> wrote: "Jon Heggland" <jon.heggl... (AT) ntnu (DOT) no> wrote in message news:fj641f$m36$1 (AT) orkan (DOT) 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". |
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.
Quote:
|
Regardless of the answer, I'm interested in your expriences. Are there any programming languages that support relvars? |
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
#26
| |||
| |||
|
|
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. [...] Date gives a rationale for the term at: http://www.dcs.warwick.ac.uk/~hugh/TTM/relvars.pdf |
--
Reinier
#27
| |||
| |||
|
|
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). |
object models in the .NET world, partly within the .NET languages
themselves (e.g. with C# indexers and value types you can construct
things that are basically relvars; there's ADO.NET Datasets;
there is third-party ORM software; there is LINQ).
But I don't really know how ypu can somehow make the fact "go away"
that database data reside in the database, while .NET data reside
in main memory. They have to be transported across somehow, and
the details of that often matter.
--
Reinier Post
TU Eindhoven
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.