Re: Multiplicity, Change and MV

From: dawn <dawnwolthuis_at_gmail.com>
Date: 17 Apr 2006 09:49:08 -0700
Message-ID: <1145292548.823950.44180_at_u72g2000cwu.googlegroups.com>

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

OK, sorry I jumped on your response, x, but my guess was that you understood the term and were nitpicking. I'll figure I was wrong on that. I suspect the loosely used term "primary element" would be said more precisely as a "strong entity" where "element" (used below too, I see) could be "entity."

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

OK, no problem, moving on.

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

It just struck me that you are bi-lingual with English as a 2nd (or nth) language while I don't speak the RM as handily as MV, for example.  A minor challenge for both of us.

> I wonder if those who use them are confused by them or there are some
> precise definitions of them.

There are some terms with very precise definitions such as file, attribute/field, value (on my site in the MultiValue triology, particularly the Data "flashcards"), but since the model is not aligned precisely with any single, simple, mathematical model, there is a lot that is not nearly as precise as a mathematical definition would be.

Most terms are trivially defined. When an MV person says or writes a term in English, the meaning is found in an English dictionary. There is not a big distinction between saying that "Courses have prerequisites" (conceptual data model) and the correspnoding "Within each Course we will place a list of Prerequisites" (act of defining a dictionary). It can be difficult to explain the difference between a conceptual data model and a logical data model to an MV person. If a file called Person has a field called FormerNames, that is the implementation of the conceptual model (coming from the "real world") where a person might have a list of former names.

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

Nothing in the application would break if you change the cardinality of an attribute (although it would be possible to write some code that would cause it to break, since you can do most anything). However, if you have a web page that collects a single lecturer with a text box, then you would want to update not only the cardinality of the term LECTURER in the dictionary to indicate it is now multivalued, but would likely want to change the web page that collects the data to have a scrollabe window of lecturers, a textarea field, or some other UI component for collecting multiple, rather than a single, value. In other words, if you have constrained the UI (which you need not do, it could get the data from the dictionary in order to show the right component), you need to remove that constraint or change it.

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

I did an informal survey a while back and recently asked a similar question and I have found zero MV implementations that do not use the query language, but several that say they don't. Some folks have either higher or lower-level tools for querying, but all of these use the query language for selection, even if they do not use it for projection.

> The names are in the dictionary ?

If they were placed there, otherwise they are accessed only by ordinal (location, 0, 1, 2, 3, ...) They can be renamed in any program.

> What if the dictionary does not exists or does not contain entries for all
> the attributes.

Then an end-user cannot use the query language directly. They would use another user interface that provides them with options to click, for example. The developer typically maps a dict to names in a program. This is one of the tacky things about Pick, to be sure. The reason is that the dictionaries are strictly descriptive and not constraining in any way.

> Is this an instance of "enough rope to hang itself" ?

Yes.

> One RM rule say "no subversion" !

There is most definitely a different sense of what is elegant between the two worlds. Pick defines elegance almost exclusively in terms of maintainable code over time that accomplishes what the business needs. So, standardization is seen as a good thing by someone maintaining code, for example, while tying the hands of a developer is not. MV applications drive toward big bang for the buck, and take risks in doing so.

[Aside: Current industry trends might go too far in trying to identify the needs of an individual where Pick is much more global. Individuals might still have green-screen apps if that is deemed to be the best bang for the buck for an organization.]

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

Yes, I have claimed that to be the case too, but, dag nab it, this is another area where theory and practice seem to have a gap. I have claimed to many people that there are big advantages for maintainability in writing OO code over procedural. I have to convince myself of it before each time I am going to state it, however. I always have to convince myself in theory, 'cause I'm just have not seen that in practice. Similarly for RM constraints and procedural constraints.

> The others usually don't like maintenance because "computer programs are not
> cars". :-)

Thank goodness. Yes, we should perhaps use the term "adaptability." Cheers! --dawn Received on Mon Apr 17 2006 - 18:49:08 CEST