Re: Pizza Example

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:6VFec.1415$4A7.960_at_newssvr32.news.prodigy.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c5egh1$d3l$1_at_news.netins.net...
> > "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> > news:HLyec.53517$CH6.17237_at_newssvr16.news.prodigy.com...
> >
> > > 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.
>
> I see. It just seems like you're simulating symmetrical access (e.g.
> relational joins) by mapping a hierarchical structure into a
> pseudo-relational view. Is creating this vocabulary necessary for any
> linkages, regardless of "nesting level"?

The vocabulary is flat (all at the same level) for each "view" of the data, but does not describe a relation or relational structure. It includes anything and everything that a user of that particular view of the data would expect. It includes whatever they would have found in that big filing cabinet plus everything that they might have to search for to correspond to the data they get from that filing cabinet.

So, you know you want to look at COURSES? What do you want to know about them -- who is teaching a course, taking it, what the course catalog description is, ...? All of this is part of the vocabulary of going after "COURSES" data. So, the user could possibly see data that is stored in hundreds of different "files" through the vocabulary of one or more such files. It is more like taking a di-graph (such as the web) and flattening it by being able to access any page you might want to access with links from a given page. So, if you got to the page/document/record for the course Calculus 161 Section 01 the page will have on it not just links to the name of the professor who is teaching it, but it will look to you, the reader, as if that data were actually the same as another data you see related to that course. The vocabulary saves the user from needing to know where anything is stored.

This is not a perfect scenario in that the vocabularly needs to be built and maintained, but that is something that one would expect to be necessary over the life of an office -- changing vocabulary and defining new vocabulary. The unfortunate part is that it often takes a software developer to extend the vocabularly beyond simple links (such as calculating cumulative GPA for each student in the class if that is also to be part of the vocabulary of COURSES).
> > > 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
> > intuitive. --dawn
>
> Maybe, but I still wouldn't base a computational model on intuition. After
> all, the aim of symbolic logic (and Leibniz's Dream) is to automate
> reasoning through sheer symbol manipulation - precisely what formal means
> (pertaining only to form - symbolic representation). So we're at something
> of a crossroads - we either proceed in a direction that continues to make
> intuitive sense (and if it's to end users, I'd place little stock in
this),
> or we proceed down a path of greater automation.

Not a problem -- I'm not trying to force my intuition on anyone or any discipline, but rather trying to see that there really is a formalism that can be applied that aligns with that intutiion -- said intuition being based on experience, education, logic and whatever else makes the brain hypothesize. I am open to learning that I am wrong or backing my opinions with better data. Based on the papers I've read of late, including those that Jan pointed us to, there are logicians who have put some backing to XML modeling. Unlike relational theory and its implementations, XML did not arise through rigor just as PICK did not.

When I suggested to a seasoned PICKie at one point a possible reason for why Don Nelson and Dick Pick chose the structure they chose, I was told that it was far more likely that they had a deadline (working for TRW) and the beer was flowing. The problem they were solving was that it was during the Viet Nam war and there was a need for Army troops in the field to be able to work with a parts system (for Cheyenne helicopters) without any database folks or software developers in the field. They needed regular human beings to be able to ask questions of the database. The language they developed (GIRLS = Generalized Information Retrieval Language and System) has been largely unchanged in 40 years (a bit of a shame but also a tribute) and is more standardized among the various database companies supplying variations of PICK than SQL is, in spite of (or because of?) the lack of a standards body. It is, however, invisible in the industry since it is licensed by way of Value-Added Resellers so users of the language or of PICK applications typically think only of their own vertical application and VAR.

> I don't see the two converging, just as none of the "higher-level"
languages
> have ever succeeded (or WILL ever succeed) in making end-users into
> programmers. We may as well bite the bullet and use effective means for
> automating reasoning, which is the reason (no pun intended) that we
invented
> the lil' buggers...
>
> > 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.
>
> Since you're so good at it, how about starting another thread? I have some
> things to say on this, and it's a neat discussion, but I'd rather you
> launched it...

Hey, thanks Eric -- I appreciate the compliment. As soon as I can frame it logically (in this case, I'll resort to the left brain), I'll start the thread. Stay tuned. --dawn

> - erk
>
> P.S. Thanks for lots of good topics... we may disagree, but I always find
it
> interesting and informative.

P.S. back atcha. Received on Tue Apr 13 2004 - 03:48:17 CEST