Re: Searching OO Associations with RDBMS Persistence Models


Dmitry A. Kazakov wrote:
On 30 May 2006 13:29:39 -0700, topmind wrote:

Dmitry A. Kazakov wrote:
On 29 May 2006 22:29:24 -0700, topmind wrote:

Dmitry A. Kazakov wrote:
On 28 May 2006 12:17:33 -0700, topmind wrote:


You have an excellent chance to present a proper RM decomposition of a
distributed system.

I need more details about the requirements. I don't know how to make a
generic distributed system and I am not even sure there is such a
thing, at least not in a practical sense (Turing Tarpit Syndrome).

As far as a remote backup, one can build in triggers into the live
tables to send any copies of changed records to the remote system.
Maybe every night there be fresh copies of all tables sent to make sure
nothing got skipped.

Huh, and what are the RM words for "send" and "remote system." You keep on
doing hierarchical decomposition all the time.

If we view those in RDBMS terms, it might look something like:

INSERT INTO systemTo::messageTable
(SELECT * FROM systemFrom::messageTable
WHERE systemFrom::messageTable.messageDate = sysToday)

Communication can potentially be viewed purely as queries.

But communication *is* a layer in a hierarchical system. Show me how goals
of communication can be achieved relationally. Isn't it a trivial practical
question?

I need to see the requirements.

No. I won't write requirements in terms of RM. Why should I do your job?
Provided, that I doubt that anybody could do it! Again, the point is that
your RM is sufficiently weak. That means not only an inability to solve
some problems. It is so weaker, that you are unable even to formulate many
*important* problem there. So much to your question about requirements.

It is possible to view communication as queries (above). However, even
if it couldn't, that does not by itself make RM "bad". What is worse,
something that can do 80% of everything well and stink at 20%, or
something that can do 100% of everything with a grade of "C-minus"? Is
my sadan car "bad" because it cannot go off-road? There are vehicles
that can do both the road and off-road, but they give a bumpy ride and
eat a lot of gas.


You can argue that in
your application domain of cooking, concentrated solely on can opening,
there is only one type of food (as found in cans). Though I doubt that.

If you can model food cleanly as "types" be my guest....

At least it would allow to distinguish cat food as a type of.

Both cats and humans eat fish and milk. There is a busted hierarchy
right there.

Say that to FDA.

The FDA's view of things may differ than say a pet-owner's. Everything
is relative and there are no universal/absolute taxonomies (for the
vast majority of things we model). Classification experts have known
this for centuries. Those who are looking for universal taxonomies are
living in the 1500's.

Another example is location divisions. Political districts often don't
match postal divisions of locations (with lots of help from creative
gerrymandering). Thus, there are two somewhat indepedent taxonomies
depending on what we want to do. Relational allows us to create
structures that are not overly tied to original or first taxonomies.
Relational describes nouns by adding yet more attributes, not by
sticking them in a particular path or slot.


I've tried to speculate on how ADT's and OOP behavioral classes may fit
into RM, but both of these get very messy when one deviates from
hierarchies. It is easier to manage non-trees as sets and/or
relational, at least for me. The alternative are undisciplined
shanty-town messes. Navigational is the Go To of
structuring/classfication. IS-A does not scale and is not flexible.
HAS-A is simply cleaner and more meta-able under sets/RM. Thus:

IS-A - Does not scale and is too artificial

HAS-A - Better as sets or RM than as networks of pointers
(navigational)

It becomes a theological dispute. The words HAS-A and IS-A have no meaning
outside a logical framework.

To your information. In set theory they are equivalent:

x is-a X is trivially same as X has-a x

It is the same relation, denoted by the same symbol "e".

Yes, but in sets there can be multiple IS-A's per item. With typing
this can get messy. The on-going circle/ellipse and square/rectangle
debates have shown hints of this.

As far as the Librarian Paradox, that seems like a problem with
conflicting/bad requirements. If your boss or users asks for something
contradictory, then you ask for clarification or a decision about which
of multiple paths to take.

And how do you know if a requirement contradictory?

Generally that is the job of the analyst.

How does the analyst do his job? He takes a set of rules applies them to
the data and comes to a conclusion.

Now carefully observe that the above describes a *logical* system. And if
that system is self-contradictory, then the analyst can come to two
incompatible conclusions from the *same* input data. You can't ask anything
in such system, because the answer is worth of nothing. In particular, he
might answer you that a requirement is both contradictory and perfect.

Let's assume that the requirements came from the library manager. If
the manager gives you such contradictory instructions, then you seek
clarification. This is a common scenario for analysts. Users are not
always sure what exactly they want or how to word it. About 95% of all
the requirements I see are in English, not mathematics.

They are translated to a formal language exactly for that reason. The whole
software developing process is nothing but translation of requirements to a
formal language. If you can translate librarian paradox, throw your formal
language away.

It will come out problematic regardless of which model you use. You
cannot successfully divide by zero unless you define a
situation-specific outcome for such.


For an example similar to the library example, if your manager asks you
to modify the database to log every record change of every single table
into a log table, then everytime the log table is updated we would have
to log that also, creating a run-away loop/recursion.

Why run-away recursion is wrong? Where it *follows* from? You cannot do
anything outside logic. You have to accept it, because everything you are
arguing to is based on deductions like "infinite recursion => program will
not halt".

I am not sure what your point is.


Perhaps more formal approaches work better when working with natural
rules such as physics, chemistry, etc.

Rubbish. Formality means only an ability to show consistency of the
approach. You can go informal as long as nobody has shown that what you are
doing is inconsistent. Librarian paradox is *enough* to throw rubbish away,
any paradox is. You cannot argue to any practical use of. There is no use
and no *arguing* in an inconsistent system.

The library example appears to be conflicting requirements, not a
conflicting implementation.

Stop. That's exactly the point. Conflicting implementation = librarian
paradox can be formulated in the language of implementation. So if I can do
it in your RM, then your RM is rubbish. This is the only practical use of
paradoxes, to throw rubbish theories out.

It will be rubbish *anywhere* because without modifications to the
requirements we cannot satisfy them literally. The solution is to build
a boat or take a different route, not try to walk on water.

Dmitry A. Kazakov

-T-

.