Re: foundations of relational theory?
Date: Wed, 22 Oct 2003 13:10:56 -0400
Message-ID: <K5mdnVW6QOnLJwuiU-KYuA_at_golden.net>
"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
news:bn62u5$1gv4$1_at_gazette.almaden.ibm.com...
> "Dawn M. Wolthuis" <dwolt_at_iserv.net> wrote in message
> news:6db906b2.0310211141.7daf437e_at_posting.google.com...
> > "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> news:<bn33eu$12j0$1_at_gazette.almaden.ibm.com>...
> > > "Dawn M. Wolthuis" <dwolt_at_iserv.net> wrote in message
> > > news:6db906b2.0310202027.58324c36_at_posting.google.com...
> > > > "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> > > news:<bn15ap$g1a$1_at_gazette.almaden.ibm.com>...
> > > > > "Dawn M. Wolthuis" <dwolt_at_iserv.net> wrote in message
> > > > > news:6db906b2.0310191644.13b47642_at_posting.google.com...
> > > > > [snip]
> > >
> > > Because a MV system is more complex (contains more constructs), for no
> extra
> > > power than a relational system.
> >
> > If you were to take a set of metadata and load up DB2 or Oracle and
> > Universe or UniData, I suspect you would be able to "feel" just how
> > much simpler it actually is.
Paul, there are reasons I observed long ago that Dawn is an idiot. Dawn substitutes irrational emotive criteria for rational objective criteria. One can measure and quantify simplicity and complexity. Feeling plays no part in forming a valid conclusion.
> > Perhaps the fact that types and lengths
> > of fields need not be declared helps with the simplicity.
As I said earlier, Dawn is an idiot. Dawn has drawn conclusions regarding the relational model in apparent total ignorance of the model.
> > So, yes,
> > the added attribute of identifying whether an attribute may be
> > MultiValued or is just SingleValued could be seen as more complex, but
> > the overall model surely is not.
I pointed out that Dawn is an idiot because Dawn lacks the cognitive ability to comprehend simple concepts like complexity. The overall model of Pick, if one can really call it that, is vastly more complicated than the relational model. It hardly takes a genius to comprehend the concept. Overall, Dawn surely is an idiot.
> Can you list all the parts of the MV model?
>
> The relational model has relations and relational algebra. You equivalent
of
> relations, FILEs, are more complex than relations. So unless your
> manipulative part is a lot less complex, I think you will find that our
> whole is less complex than yours.
Pick's manipulative part, AQL, is both more complex and less expressive.
> > > [snip]
> >
> > > Dawn, 'Forms' are mearly one interface into your data. You probably
> should
> > > not try to define your data in the terms of a single interface into
it.
> You
> > > data sould 'stand alone' so to speak.
> >
> > My point is that data doesn't really stand alone -- it has a context.
> > I recognize that data could be collected by means of x, y, and z and
> > then could be viewed by way of different mechanisms. There is meaning
> > that is lost when exploding the propositions that are encoded in the
> > data entry "forms" (whatever mechanisms) that gets lost if the data is
> > exploded in some democratic fashion. Sure we can add information to
> > identify that Jane Doe is our important customer and Sara Doe is but
> > the child of a customer, but that still adds complexity just to
> > getting our original propositions back out.
>
> It's just a view (aka relational query), one of many that can be formed
from
> the democratically represented data.
Paul, all Dawn is saying is that Pick requires one to encode information as structure. Dawn is an idiot who lacks the cognitive ability to comprehend the advantages of encoding all information as data values one can directly manipulate using the same mechanisms as any other data value.
> > > > Relational databases
> > > > have a skewed perspective on political correctness. Jane's children
> > > > are important as they relate to Jane, but we don't have any reason
to
> > > > believe at this point that they have importance (to our org) on
their
> > > > own. If or when we do, then they can have their own forms filled
out,
> > > > but until then, keep the original proposition together.
> > >
> > > And in the latter case, the relatinal model fits best. In the former,
> use
> > > relation valued attributes.
> > >
> >
> > It is the case where we change our view of this data that interests me
> > most. If we start with an understanding of our data that has us
> > believing that Jane's children are only important to us as they relate
> > to Jane and there is no more information we need on them, we could
> > very well end up next year wanting to also collect their birthdates.
> > Then the following year, we might have new business functions that
> > require that we treat all children as prospective customers in their
> > own right. Starting in an RDBMS with relation-valued attributes will
> > not be nearly as easy to migrate from as staring in an MV, from what I
> > have experienced.
>
> There do not exist any relational database systems that properly support
> RAVs [well there are no real relational database systems (SQL does not
> count), but that's another matter] so I don't know where you experience
> comes from.
>
> Fundamentally Dawn, you confuse personal experience with implementations
> with knowledge of what benefits/limitations different logical models
impose
> on any possible implementations that are built upon them.
>
> [snip]
> > > The database IS the application(s). ;-)
> >
> > Yes, I'm definitely catching that angle and will try to be open to
> > this approach. My first impression is that I don't like it, however.
> > The fact that it doesn't feel good to me is likely not a convincing
> > argument, eh? If I were to research an industry-backed language for
> > building applications, the language you would then suggest is
> > a particular flavor of SQL or SQL-92 (I'm reasonably well-versed in
> > the SQL-92, but not in various extensions of a lot of different
> > vendors) or SQL-99 (not as well-versed, but have read more on it than
> > most people, I'm guessing) or something else? It seems to me that you
> > are suggesting some proprietary database-specific language should be
> > used to declare an application when declaring the data definitions,
> > perhaps?
>
> I'm not really interested (here) in what the industry currently backs.
>
> I'm looking forward, maybe to a time a long way off. For that, Tutorial-D
is
> one possible beginning.
The data is so much more than an application. It is the fundament upon which all applications rest. Dawn prefers to build castles in the sky. Received on Wed Oct 22 2003 - 19:10:56 CEST