Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Multiplicity, Change and MV

Re: Multiplicity, Change and MV

From: dawn <dawnwolthuis_at_gmail.com>
Date: 12 Apr 2006 09:16:16 -0700
Message-ID: <1144858576.001309.90750@z34g2000cwc.googlegroups.com>

x wrote:
> "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".

Given that "MV" is in the subject and that is the generic term for MultiValue, aka Pick, solutions, I would think we could let him speak his language. The fact that the RM doesn't care about words like "detail" does not mean that database theory should be without such words.

Note to BFaux -- After a few years of trying, I am still learning the cdt language and still get taken to task for it. This is often not a meet-you-half-way dialog, but hang in there. Your terminology is as valid, just not what is taught in the schools which seems to focus on very few aspects of any theory behind implementing good database solutions.

> > "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".

Were you really confused by these terms or just irritated that potentially imprecise and certainly non-RM terms were used?

> 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 ...

The point is that a "vocabulary item" such as the name of the attribute LECTURER does not assume the cardinality. The property of the attribute LECTURER that says whether it is single or multi-valued would be changed (so metadata would change) but nothing in the existing code would break by making that change. Nothing. How cool is that? Forms/screens/UIs to update a list instead of a single value would need changing, although software can be written in such a way as to minimize this too (add or remove scroll bars).

> > 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} ?

Is there a difference that will make a difference for your applications or to your users? MV is a language-based practical approach to data management. If you are going to report that users play this or that, then this works.

> > 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.

Everything in MV is accessed by the query language by name. The name might relate to a virtual field that is specified with a logical path through the data (not unlike a view created using a join from a foreign key)

> The other problem is when you need to write procedural code to maintain the
> consistency.

And if that procedural code is in either a trigger or the only database service that can be used to maintain the data, what is the issue?

> > 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) ?

If the software (combination of database, metadata, code) was written properly, this would never be the case, but if it were the case, then the same result would be returned if German101 were used as the code (foreign key) as in this example.

Cheers! --dawn Received on Wed Apr 12 2006 - 11:16:16 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US