Re: Multiplicity, Change and MV

From: B Faux <>
Date: Tue, 18 Apr 2006 17:52:03 GMT
Message-ID: <7H91g.10833$>

"Bob Badour" <> wrote in message news:pl81g.61748$
>x wrote:
>> "dawn" <> wrote in message
>>>x wrote:
>>>>"dawn" <> 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.
> 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 believe I have been unintentionally ambiguous, please accept my apologies. As to your comment about loops, Mr Badour's comments and your question about relations within a domain...

First, yes all MV implementations support loops, (condition controlled, counter controlled, mixed variations of these) as they all have relative benefits. Unfortunately this also means that a programmer can apply a loop technique that is not optimum for their application, but rather is the technique with which that programmer is most familiar. But it still works, usually.

Second, as to Mr Badour's assertion that a 'Pick' database allows users to enter anything they want into the database, this is absurd on its face. Although the early file systems would support a 'write' function to a particular attribute few limitations, it was always incumbent upon the application programmer to constrain this ability. Any application that allows such nonsense would surely suffer a quick and painful death at the hands of the first user to whom it is entrusted. Today's implementations make it possible to reject these types of changes in exactly the same way that SQL-type DBMSs do, that is by applying limitations to the functions of read/write/delete to prevent corruption at the database level rather than relying on good application programming.

Third, I am not completely certain I understand your question about the relations within the domain so I'll answer it this way and hope I come close. The file structure contained within an MV DB does not allow for unlimited extension. That is to say, you cannot (in most cases) build an hierarchy wherein you have a cascading parent/child relationship such as that supported in most common file structures. So a file system such as: root/usr/dataset1/dataset2/... would not be directly applicable within an MV file system. This muddies the waters so to speak, but the good news is that this has never caused a problem in crafting an actual solution, in my limited experience (since 1983) when I was first exposed to an MV DBMS - which was not 'Pick' BTW.

So within an MV DB it would usually fall to the application designer (system analyst) to isolate the various expected relationships and address the types of cross-functionality desired. A repeating value within a particular domain (e.g., multiple instances of the same data value relating to different primary keys) the representation within the file structure is much like that in an SQL DB where each separate value is contained in the same column, but on different rows. In an MV DB, the file structure does not expose the physical storage (using a hashed algorithm for storage/retrieval) but rather keeps each individual row (record) logically separated from the others within the same table (file). By interposing pre-defined delimiters into each record, the over-all structure is preserved, while useful abstract capabilities are made available; such as variable length fields, additional value insertion, record extension, etc. Can a programmer screw this up? Certainly, but a DBA can make any other DB unusable with a single typo too!

The tool for the job analogy applies to all - and I still assert that the OP (JOG please correct me if I am wrong) is responsible for directing this thread into a less abstract, more functional discussion. For the record, the only reason I wandered into this swamp was because the subject contained 'MV' (not RM) and the OP mention 'Pick' by name.

BFaux- Received on Tue Apr 18 2006 - 19:52:03 CEST

Original text of this message