Re: foundations of relational theory?

"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. Perhaps the fact that types and lengths of fields need not be declared helps with the simplicity. 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.

> > Also, since IBM has the top-selling MV databases, I hope there are
> > some good IBM discussions on the relative merits of the various data
> > persistence approaches that IBM now sells. I would LOVE to see a
> > breakdown of cost and revenue for IBM on each of its databases. Where
> > would DB2 be compared to Universe, for example? How about IMS?
> > Informix? Is the better bang for the buck for IBM in the relational
> > model or in the non-RDBMS?
>
> I don't know the figures. I know IMS is still non trivial revenue, but DB2
> is where it's really at.

I'll figure that the "it" is marketing ;-) If I were a gambling man, I might bet that the revenue taken in per dollar spent on U2 (which is MV/PICK for those who are unaware of those two databases) when compared with the same for DB2 might actually show up favorably.

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

>
> > 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. Often existing data entry screens, existing analytical or operational reports, etc need no changes at all, except for the one we are focussed on to make our changes for the new business functionality within the MV model. Maintenance of data over time is one of the key merits of the MV/PICK model, along with ease in querying data.

> [snip]

> Otherwise, tell Fabin that you commit (on my suggestion) to answering
> Chris's questions in the MV appendix, and he may let you have a free copy.

Thanks for the tip. They've gotten money from me before, so maybe I'll bite the bullet.

[snip]
>
> Thanks, that's good stuff.
>
> Pick only allows two levels of nesting yes? And that is not seen as a bad
> limitation?

It is the query language that only provides constructs for retrieving "multivalued sub-values" while Don Nelson (of the Nelson-Pick data model) did go on to build a system with 16 levels, as I understand it.  There are pickies who come up with their own delimiters and embed more than 2 layers into PICK, but they need to define virtual fields (like user-defined functions) to access values that are beyond 2 levels using the standard query language. So, the data model, per se, doesn't really have such a limitation, but the associated languages have constructs for dealing with multivalues and sub-values out of the box.

[snip]
>
> > When selling products in product line XYZ, then all sales must be to
> > people in the US so assume that is the country and validate the postal
> > code against US zip codes (and, good deal, our database permits us to
> > identify the table against which to edit this attribute)
>
> >, but when
> > selling new product line ABC, we can take in a country code too and
> > the postal code should now not be constrained to just the US, although
> > in the first application it should be.
>
> > Now just how should we change
> > the database and how should we change the first application?
>
> WHEN Application = 'First App' THEN Product_Line = 'XYZ'
> WHEN Application = 'Second App' THEN Product_Line = 'ABC'
>
> And if all applications were simply generated from the database schema, the
> this is just a schema evoloution problem.

I have not seen this construct in use, but I like it. Your statement "if all applications were simply ..." gets us back to the selection of a single language for developing software. I'd rather work with Java than any DBMS language I've seen but that might be a matter of liking what I know. I'll try to learn more about the extended uses of dbms declaratives. My actual hands-on experiences date back to, well, the mid-80's, although I have more recent not-as-hands-on project management experience.

>
> Dawn you need to widen you perspective slightly. 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?

Maybe a comparison of the language you think we should use to write software with Java would provide some more factual clues on what my intuition says.
Cheers! --dawn Received on Tue Oct 21 2003 - 21:41:38 CEST