Re: foundations of relational theory?

"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]
> > > While this is not an academic statement of why PICK works nicely, it
> > > might give some hints on why folks who have put their dollars into the
> > > SQL-based RDBMS world can become born-again when they see the
> > > difference in dollars needed for a comparable PICK system.
> >
> > Mind if I take it as an academic statement?, and use it to give hints at
why
> > an MV system will be less useful than a relational system everything
else
> > being equal.
>
> I'm likely just getting old, Paul, but I'm not tracking with you on
> this question. What about my statement gives you a hint that if
> everything else is equal then an MV system will be less useful and
> just what is the everything else? You mean if someone has the same
> number of dollars to sink into an MV syste as an RDBMS system, then
> the MV system will be less useful? Why?

Because a MV system is more complex (contains more constructs), for no extra power than a relational system.

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

[snip]
> > The point of the relational model is that it is *democratic* - i.e. all
data
> > is treated equally. Cars have people, people have cars. We do not bias
> > ourselves one way or another. Children are no more (or less) important
that
> > Parents.
>
> Yup, that is definitely a good point -- the relational model does not
> retain the same value for the various pieces of propositions that the
> person stating the proposition did. It elevates less important
> information to the same status as the subject of a proposition, for
> example. If Jane Doe fills out a form, then "Jane" simply is more
> important data than the make of her third car.

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.

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

[snip]
>
> > I would urge those who wish to understand more of these issues to read
Chris
> > Date's paper "What First Normal Form Really Means" (It will cost you
> > though )
> >
> > http://www.dbdebunk.com/page/page/629796.htm
> >
>
> I would read it, but I've paid for several Date books and decided that
> instead perhaps he would like to exchange it for the opportunity to
> read my paper on "Why it Isn't Important to Persist Data in First
> Normal Form" (you're right -- it is still just in my brain)

I suspect that Fabian won't make such an exchange ;-) However, it really is worth your money (assuming you think all this is important). It's exactly on the subject that you are working on, and even includes an appendix on multi-valued systems. If you have a moral objection to paying, let them know. I suspect that ultimately they are more interested in spreading knowledge, than making money.
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.

> > One thing the relational guys might learn from the experiences of MV
> > systems, is a better idea of when relational valued attributes are OK
and
> > when they are not. I'm sure you guys know when MV attributes get misused
for
> > example.
> >
> Yes, I have seen some good dialog related to this topic. I would
> guess that XML folks might have had such discussions as well.
> However, I think that putting a relational valued attribute in an
> RDBMS has risks and costs that are different from persisting relations
> within records in an MV system. So, some tips should translate (such
> as just how deep do you want to go -- designing with relations within
> a record/row is OK and then refactoring when a change is necessary to
> permit relations within relations within a row is acceptable, but
> going deeper than that just doesn't tend to pan out well) while others
> would not (make everything single-valued until you know for certain
> that some of your data will require multiple values in that attribute
> and then just switch the cardinality with no changes to anything else,
> or with only a change to an input screen to change a single value to a
> scrollable window of values, depending on how your data entry is
> configured).

Thanks, that's good stuff.

Pick only allows two levels of nesting yes? And that is not seen as a bad limitation?

> >
> >
> > > [I understand the purpose is to be able to provide a simple language
> > > that enforces various data constraints, but I think that purpose is
> > > somewhat flawed too. Protecting data is a noble goal -- controlling
> > > data and programmers with fixed, global constraints isn't necessarily
> > > the best way to lend such protection in my opinion, but that's a
> > > tangent to this post, so later on that.]
> >
> > If a constraint is not global, then it is not, in fact, a constraint.
>
> But what I have seen when going from one use of the data to another is
> that constraints seen as global because the first application saw them
> that way, can become local -- they are still constraints for the fisrt
> application, but not for the second.

So add the 'application name' as part of the constraint.

WHEN (Used by Managers) DO (No updates allows) WHEN (Used by People Who Act) DO (Allow updates)

> If all constraints are globally
> encoded at the database level, then local constraints need to be
> encoded in the application programming language.

> Why have two separate languages for constraints?

Indeed. So all constraints are DBMS constraints.

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

> We KNOW
> that this type of scenario occurs over and over again. If all of the
> constraints about the data are in a programming language used by
> applications, then the first application can be left in tact and the
> new application can use different code than the first to handle the
> fact that what was once thought to be a global constraint is now known
> to be a local one.

Dawn you need to widen you perspective slightly. The database IS the application(s). ;-)

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Tue Oct 21 2003 - 12:54:25 CEST