Re: Multiplicity, Change and MV
Date: 18 Apr 2006 12:08:55 -0700
Bob Badour wrote:
> x wrote:
> > "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> > news:1145367130.294647.63460_at_e56g2000cwe.googlegroups.com...
> >>x wrote:
> >>>"dawn" <dawnwolthuis_at_gmail.com> wrote in message
> >>>It just occured to me that other possible problem with MV systems beside
> >>>loops might be the [im]possibility to represent relations over the same
> >>>domain like r(A,A,A,A) where A is an element/entity/whatever like
> > Courses,
> >>>Lecturers etc.
> >>>Could you provide an example for this ?
> >>The domain for every (non-binary) attribute in Pick is String.
> >>Everything else, such as indicating that the string is a Date, is a
> >>description of the data. A single value can be described as a Date and
> >>as a String, for example. There is no problem having a relation with
> >>multiple courses. Each course would be named differently and would be
> >>a String.
> > String is not an entity of the domain of discourse.
> > I would like a detailed example as the one provided by B Faux.
> > I can wait, so no hurry :-)
> It's easy enough to construct your own example. Where he has
> PREREQUISITE, add a RECOMMENDED field for non-mandatory courses that the
> faculty suggest everyone take -- except those who are most confident in
> their ability. The example is easy enough to construct regardless
> whether PREREQUISITE and RECOMMENDED are both strings or both references
> to a COURSE file.
> To elaborate, a course in vector calculus might not be a prerequisite
> for studying electric fields and waves, but speaking from personal
> experience, it sure is helpful to have taken one first.
> The MV crowd would have you believe that one can create a database with
> single values, and when some user encounters a need for multiple values,
> the user can enter the data that way, while everything just continues to
> work. However, there are two logically distinct ways users could
> encounter that need:
> 1) A lecturer teaches more than one course.
> 2) A lecturer teaches a combined course.
> This thread has already discussed case 1).
> Case 2) might arise when some lecturer decides to combine vector
> calculus (VC) and electric fields and waves (EFAW) into a single lecture
> that grants credit for both courses. One could easily combine problem
> sets and tests to fully cover both curricula because EFAW uses so much
> VC. The students would have to buy both texts, and I suppose it would be
> easy enough to replace two 1-hour lectures with a single 90 minute lecture.
> Data entry users at the university who encounter both cases have been
> told they can enter multiple values and everything keeps working. Users
> who encounter either case are likely to do the exact same thing, and of
> course, the query engine cannot interpret the same data two different ways.
> As it happens, for identical queries, how Pick interprets the data
> differs depending on whether the COURSE domain is a string or a file
> reference, which is exactly the sort of thing casual users will not
> understand at all.
That is simply not the case. All queries are done against Files (one and only one in the File position in a query statement) and all restrictions are done related to attributes. Those attributes might be lists (or even matricies, lists with arity > 1), but there is no such confusion. I know way too well that it is far easier for an end-user (or even developer) to ask the right question and get the answer to the question they intended to ask in Pick (MV) than in SQL.
> In fact, three years ago, I convinced myself that so-called experts, who
> the online Pick community actually considers experts, are incapable to
> understand this issue.
I am very willing to try to understand the issue fully if you are willing to have the patience to explain it, answering the questions I might have until I can see what you see. I would like to understand your point about how identical queries would yield different results. Thanks. --dawn Received on Tue Apr 18 2006 - 21:08:55 CEST