Re: Multiplicity, Change and MV
- From: "B Faux" <nospam@xxxxxxxxxx>
- Date: Tue, 18 Apr 2006 17:52:03 GMT
"Bob Badour" <bbadour@xxxxxxxxxxxxxxxx> wrote in message
news:pl81g.61748$VV4.1153485@xxxxxxxxxxxxxxxxxxxxxxxxxx
x wrote:
"dawn" <dawnwolthuis@xxxxxxxxx> wrote in message
news:1145367130.294647.63460@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x wrote:
"dawn" <dawnwolthuis@xxxxxxxxx> wrote in message
news:1145292548.823950.44180@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.
X-
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-
.
- Follow-Ups:
- Re: Multiplicity, Change and MV
- From: Bob Badour
- Re: Multiplicity, Change and MV
- References:
- Multiplicity, Change and MV
- From: JOG
- Re: Multiplicity, Change and MV
- From: x
- Re: Multiplicity, Change and MV
- From: B Faux
- Re: Multiplicity, Change and MV
- From: x
- Re: Multiplicity, Change and MV
- From: dawn
- Re: Multiplicity, Change and MV
- From: x
- Re: Multiplicity, Change and MV
- From: dawn
- Re: Multiplicity, Change and MV
- From: x
- Re: Multiplicity, Change and MV
- From: dawn
- Re: Multiplicity, Change and MV
- From: x
- Re: Multiplicity, Change and MV
- From: Bob Badour
- Multiplicity, Change and MV
- Prev by Date: Re: Multiplicity, Change and MV
- Next by Date: Re: Multiplicity, Change and MV
- Previous by thread: Re: Multiplicity, Change and MV
- Next by thread: Re: Multiplicity, Change and MV
- Index(es):
Relevant Pages
|