Re: Pizza Example

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:HLyec.53517$CH6.17237_at_newssvr16.news.prodigy.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c54cdd$upt$1_at_news.netins.net...
> > "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> > news:SRhdc.13831$Uy3.4866_at_newssvr15.news.prodigy.com...
> >
> > > Of course. This assumes that your main reason for storing the data is
to
> > > display it again, in its original form, for humans. If that's all
you're
> > > doing, then many different simple systems will suffice - a Word
> document,
> > a
> > > spreadsheet, etc. But if you're trying to reason about the data, then
> you
> > > need to structure it in a way amenable to automated deduction. You are
> > also
> > > perfectly free to keep a copy of the original, which would then be
> > dependent
> > > upon the key, the whole key, and nothing but the key per normalization
> > > rules.
> >
> > I want my cake and eat it too! The PICK structure does what I have
> > described and is "amenable to automated deduction" and it seems to me
that
> > there is some value in that, but I'm still poking and prodding to
clarify
> > what that might be.
>
> Of course it's amenable, just much less so. It's its lack of symmetry and
> consistency that poses a problem. By nesting values inside values (and
then
> a further layer inside that, I believe), you complicate the algebras,
> closure, and optimizations. Relational is much simpler, hence its power.

Possibly conceptually simpler as a mathematical model, but in real life it does not seem to be simpler at all. The end-user sees it as symmetric once the vocabulary is in place for that to be the case.

LIST STUDENTS COURSES WITH COURSE_NAME LIKE "A..." might list the students and all of their courses with a name starting with A

LIST COURSES STUDENTS WITH STUDENT_NAME LIKE "A..." might list the courses and all of their students with a name starting with A

It is not symmetric when the vocabularly has not been put in place for it to be so, for example, if the student name (which would obviously not be the stored foreign key for the student and is not physically stored in the COURSES file) is not placed in the vocabularly of the COURSES file/graph/tree/function.

> On a related note, things like objects add a great deal of complexity in
the
> pursuit of "intuitive" modeling techniques; specifically hierarchies,
> graphs, and a persistent (no pun intended) confusion between variables and
> values. That additional complexity always comes at a cost, and it's
> unfortunate that people are so uncomfortable with symbolic logic and
related
> disciplines that they bite into much more complexity than they would
> otherwise have to, simply because the "operational" (procedural) approach
> appears intuitive.

It doesn't just "appear" intuitive -- it typically IS more ntuitive. --dawn

P.S. I've been mulling over Date's write-up on the issue of whether a class can "be" a relation. The argument against it seems to come down to ... "If you were to create a class that defines a relation type, then you would no longer be consistently following the relational model". I suspect I'll have some questions or opinions on that matter soon. Received on Mon Apr 12 2004 - 18:35:29 CEST