Re: foundations of relational theory?

Hi,

"Mike Preece" <michael_at_preece.net> wrote in message news:1b0b566c.0310201849.7e079809_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.
> >
> > > Again, it is not that PICK is flawless (by any stretch), but as a
> > > basis for moving forward, I'd sure rather start with this big bang for
> > > the buck implementation than any SQL-based RDBMS I've seen. And, yes,
> > > I know this is a theory forum and not necessarily for opinions based
> > > on practice, so I'll go back to the claim, even though not fleshed
> > > out, that persisting data based on language -- such as modeling entire
> > > propositions together rather than piecing them apart to the extent
> > > done in an RDBMS -- makes sense because we are not trying to persist
> > > mathematical relations ultimately -- we are trying to persist
> > > propositions.
> >
> > Guess what, "trying to persit propostions" is *exactly* what the
relational
> > model is all about. A tuple (row) is a fact - a proposition.
> >
> > > For example, "Jane Doe has three kids -- John, George, & Paul -- and
> > > also three cars -- a 1967 Mustang Fastback and a 1968 VW Bug, but the
> > > car she usually drives is her other car -- a 2002 Ford Thunderbird".
> > > A lousy sentence, but easy to image on a form. This sentence/form is
> > > about a single person -- Jane Doe
> >
> > Any why, prey, is that sentence not also about the person John (or
George or
> > Paul)? Or equally it is not about 2002 Ford Thunderbirds?
> >
> > The point of the relational model is that it is *democratic* - i.e. all
data
> > is treated equally. Cars have people,
>
> Don't be silly. Cars don't have people - they have owners. The person
> owns the car - and possibly others. The car is owned by the person.
> There's an implied relationship and it's a parent-child, one-to-many
> relationship. A person can have more than one child and more than one
> car. The database is required to record information about people,
> primarily, and the children they have, cars they own, and which car
> they usually drive. That's the real-world requirement, is it not? With
> a multivalue database all of the required data about a person and
> their relationships can be obtained and updated with a single
> read/write.
>

A child can also have more than one parent, and a car can be co-owned.

Just for my own edification, are you saying that if I were to ask, what is the name of the youngest child of that women driving the white Mercedes, it's an invalid question because you can only ask, "what cars does that woman own and to which children is she the parent? "

It seems somewhat hard to swallow that you would state that a relationship must be uni-directional. That is what you are saying, right?

If the cop that wants to find that the crook with red hair and a tattoo on his right arm, driving a white Ford Mustang with a partially seen license plate of P11..... from Kentucky, should he never ask the questions because they don't match your real-world requirement? Questions such as "To whom does a white Ford Mustang with a Kentucky plate beginning with 'P11' belong to? And does that person have red hair and a tattoo? Or is he related to someone who does?

You have me perplexed here.

• Dan

> > people have cars. We do not bias
> > ourselves one way or another. Children are no more (or less) important
that
> > Parents.
> >
>
> Perhaps the term "relational" database is a misnomer then? Aren't you
> really saying that the best way to store the data in a "relational"
> database is to do so in a way that *ignores* real world
> *relationships*?
>
> > We would say that your single sentence above is in need of normalisation
> > precisely because it favours some data over some others.
> > Now if some data is truly and always more important than some other
data, so
> > that say you are only ever
>
> I would use the word "primarily" rather than say "only ever" - and
> then use an appropriate primary key.
>
> > interested in the *set of kids* that a person
> > has, then sure model them as a set valued attribute, but otherwise go
the
> > extra mile and make kids (and cars) first class citizens.
> >
>
> What do we want to know about the kids in this example? What is there
> to know? other than who their parents are? We can index the file on
> kids if we want - at any stage before or while an application using
> the file is up and running. What more is required? or possible?
>
> > > and would all be filed in a single
> > > "folder" in PICK except, possibly, for code files used for validation
> > > -- there could be a code file for makes & models of cars.
> > > Depending on the application, it might make sense to have 4 "forms" in
> > > this folder -- one for each person: Jane and each of her kids or we
> > > might decide it isn't important to treat the kids as separate "filed"
> > > persons in our system at this point. If they are filed as separate
> > > people, then the Jane Doe record (form/document/proposition) would
> > > have a multivalued foreign key (pointer) to each of the child
> > > (literally!) records, else it would store the actual data, such as
> > > first names of each child.
> > >
> > > Playing the game with language to parse it out, split it into many
> > > fragments (often based on the nouns) for the purpose of storing it,
> > > only to need to retrieve it again as a whole, doesn't gain us
> > > anything, on the face of it.
> >
> > It gains your data a flat playing field.
>
> What if someone's child runs off the edge? The real world isn't flat!
>
> > It allows you to formulate queries
> > about (in you example) people who happen to be kids as easily
formulating
> > queries about people who happen to have kids.
>
> Use an index.
>
> > The relational model encourages this flat, democratic,
>
> ...unreal, distorted, unnatural,...
>
> > playing field.This
> > ideal has sometimes caused people to say that non-flat data (to speak
very
> > loosely) has no place in the relational model. I.e. that 'multi-valued
(e.g.
> > relation/set valued) attributes are not allowed.
> > Nowadays we (and I think I speak for most relational advocates here)
allow
> > relation valued attributes in the relational model.
>
> Have we reached a meeting of minds after all then?
>
> > SQL implementations
> > however, I hardly need say, have (mostly) not caught up.
> >
> > However, we would still generally caution against an over reliance on
using
> > 'multi-values' in a relation database.
>
> Sure. Just because you can use multivalues doesn't mean you have to.
>
> > If used 'badly', we begin to loose
> > the flat playing field.
>
> Oh. Gee. Back to a flat-earth view again? Damn. I would agree though
> that you can have badly designed multivalued databases - although most
> MVRDBMSes will tolerate poor design. This is imo the biggest problem
> with multivalue databases - they do tolerate too much poor design.
>
> > Relation valued attributes are OK. Short hands for
> > 'multivalued foreign key' constraints would make me nervous, and
> > (infinitely) recursive relation valued attributes seem to be
particularly
> > troublesome.
> >
> > 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 don't want to go there. Isn't that where Fabian Pascal spreads his
> muck around?
>
> >
> > 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.
> >
>
> There was this guy I worked with once. S**t programmer. Abused the
> c**p out of a multivalued database. IBM headhunted him. Now the
> company he left behind is in the process of migrating to DB2. Funny
> old world.
>
> I'm done.
>
> Mike.
>
> >
> >
> > > [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.
> >
> > E.g. these are global constaints.
> >
> > "WHEN (In Rome) DO (As the Romans)"
> > AND
> > "WHEN (Not in Rome) DO (As you like)"
> >
> > The 'local' constraints
> >
> > "DO (As the Romans)"
> > AND
> > "DO (As you like)"
> >
> > mean nothing (i.e. they always evaluate to TRUE, they constrain
nothing).
> >
> > Regards
> > Paul Vernon
> > Business Intelligence, IBM Global Services
Received on Tue Oct 21 2003 - 06:18:45 CEST