Re: foundations of relational theory?

From: Paul Vernon <paul.vernon_at_ukk.ibmm.comm>
Date: Wed, 22 Oct 2003 15:03:51 +0100
Message-ID: <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.

Quite possibly, but that would be a feeling at a product level, not at a model level. Even today I have to mentally exclude huge chucks of features in DB2 and Oracle to get a "feeling" for what a truly relational product could be. This is not to say that DB2 does not contain some "good stuff", but the whole is so much more complex than it could be if it was 'truly relational'.

> Perhaps the fact that types and lengths > of fields need not be declared helps with the simplicity.

Agreed, and I'd like to see a concrete proposal for a relational model where the type system (which, is mostly orthogonal to the relational model itself), allows for significant flexibility on type declarations. The SQL type system (if it can be called such) is pretty much broken IMO.

> 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.

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.

> > [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.

> >


> > > 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.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Wed Oct 22 2003 - 16:03:51 CEST