Re: Multiplicity, Change and MV

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1144858576.001309.90750_at_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.

I did not mean to imply that.
I asked what is an element. An element of what ? Weather ? Chemicals ? Atoms ?

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

I did not mean to imply that.
I showed the RM perspective.

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

I'm not irritated. Nor confused. :-)
I wonder if those who use them are confused by them or there are some precise definitions of them.
I showed the RM perspective.

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

Now I'm confused :-)
The change need more change, not in the code, but in the UI ?

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

Ok.

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

But the query language is optional for writing applications. The names are in the dictionary ?
What if the dictionary does not exists or does not contain entries for all the attributes.
Is this an instance of "enough rope to hang itself" ? One RM rule say "no subversion" !

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

Someone need to maintain it and the rumor is that this proved to be hard to do for procedural code written by [below] average (or clever) programmers. The others usually don't like maintenance because "computer programs are not cars". :-) Received on Fri Apr 14 2006 - 13:35:56 CEST