Re: Multiplicity, Change and MV

"B Faux" <nospam_at_nospam.net> wrote in message news:EvS_f.24004$NS6.8332_at_newssvr30.news.prodigy.com...

> Ok, I'm gonna take a stab at this from a 'classic MV' perspecitve, ala
Pick.
> (wanted to yesterday, but waited until some SQL responses percolated a
bit)
> So here goes...

Do you understand the RM responses ?

> First off, the schema is no problem at all and modifying it later also
poses
> no threat to data integrity, consider the following:

> The general concept relys upon the granularity of the data requirement,
that
> is to say, how much detail do you want to store about each element? In my
> experience we should allow for as much detail as possible, so I would
> recommend building a seperate MV file (SQL table?) for each primary
element.

What is an element ?
In the RM we have relations and relational/domain operators. It make no sense talking about "stored detail about each element".

> "Courses" would be a file/table with primary elements having id's
> identifying them independently such as:

> Courses = { (name:French101), (name:English105), (name:German203) }

> Within each of these would be placed elements that relate to that
particular
> course, such as , prerequisites, class locations, lecturers, etc.

What are these "within" and "placed".
In the RM it make no sense to talk about "within" and "placed". The relations are.

> Another file/table for "Lecturers" with primary elements similar to
courses,
> but pertaining to lecturers such as:

> Lecturers = {
> (id:1, name:Tom, {teaches: {French, German}, play {tennis}} ),
> (id:2, name:Bob, {teaches: English, play{violin}} )
> }
>
> In "Pickdom" we don't usually concern ourselves with all of the
sintactical
> delimiter boardering ({}) et.al. so I'll model it in a more conventional
> Pick-like form:
>
> ---
> File "Courses"
>
> ID - French101
> LECTURER - Tom
> ROOM - Bldg A/Rm 106
> PREQUESITE - (null)
>
> ID - German105
> LECTURER - Bob
> ROOM - Bldg B/Rm 200
> PREREQUISITE - German101
>
> ---
>
> File "Lecturer"
>
> ID - Tom
> COURSE - French101
> PLAY - Tennis
> LIKES - Wine
>
> ID - Bob
> COURSE - German105
> PLAY - Violin
> LIKES - (null)
>
> ---
> etc...

> Now to extract the meaningful data we would construct a sentence such as;
> SELECT LECTURER IF COURSE = "French101" - this will return a single
result
> of Lecturer "Tom"
>
> If it turns out that Tom also qualifies to teach German105, then
"German105"
> would be added to his record such as:

> ID - Tom
> COURSE - French101]German105
> PLAY - Tennis
> LIKES - Wine

> And then if we execute a sentence like; SELECT LECTURER IF COURSE =
> "German105" - this will return a result containing BOTH Lecturer "Tom"
and
> "Bob" because they both contain the value of "German105" in their Courses
> attribute in their data record (column).

And your code would not require change because instead of the assumed one lecturer, it will get two of them now ...

> As time goes by and we discover there are more things we need to track
> concerning the lecturers we simply add attributes to those records
requiring
> them (such as the "PLAY" and "LIKES" attributes shown above)

Did you noticed the difference between play{tennis} and play{violin} ?

> By adding what is called a "Dictionary" item to describe these attributes,
> they can then be extracted with an "English" sentence as described above.
> In any event, all attributes can be exposed to a program that reads (or
> writes) these records regardless of the existence of a dictionary item
> describing them. And in the most recent versions of MV databases
> (Ladybridge/openQM, IBM/Universe, etc) a trigger can be employed to
maintain
> data integrity to prevent read/write/delete operations from executing
> without proper structure, subject to programmer's (or data base admin)
> control.

This is similar to Codd's RM/T but with many parts missing. The problem is when you start writing procedural code to access the "elements" by some sequential path instead accessing it by name. Then you will rely on all the path being present. The other problem is when you need to write procedural code to maintain the consistency.

> In a similar vein a reference dictionary item can be constructed to link
to
> the Course file for the "PREREQUISITE" item to the lecturer file to allow
> for the following: SELECT LECTURER IF PREREQUISITE = "German101" and again
> we would see two lecturers selected, because both Tom and Bob have
lecturer
> records containing courses linked to prerequisites of "German101". Notice
> that the value "German101" does not exist in the lecturer file, but
because
> the course "German105" contains this as a prerequisite, then the lecturers
> having courses that in turn contain this value, they will be returned.

What if "German101" is not in the file for some reason (as the example show) ? Received on Wed Apr 12 2006 - 16:33:27 CEST