Re: Multiplicity, Change and MV

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

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

It's actually the 4th in cronological order if I don't count some foreign languages lessons in kindergarten :-)
Grammar is giving me headaches when writing (not reading) but I usually make more mistakes when thinking about it :-)

You should find it easy to understand RM with your background in mathematics.
My background is undergraduate (I don't have a PhD) "applied math" (yes, there is such a thing :-).
Oh, I just noticed you said "minor" :-).

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

This might be the reason of programmers productivity.

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

I don't care much about static web pages. It is good if only some declarative code need changing (as the data and the UI :-)
Anyway languages and automata are equivalent in math :-)

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

How many loops a Pick programmer need to write in code ?

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

Maybe the days when code will be as portable and valuable as data are comming :-)

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

Adaptability and debugging are two different things. One is about introducing bugs, the other is about removing them :-) Received on Tue Apr 18 2006 - 10:35:37 CEST