The OverRelational Manifesto ("TheORM"). Needs to be debunked.

From: U-gene <grigoriev-e_at_yandex.ru>
Date: 2 May 2006 09:16:17 -0700
Message-ID: <1146586576.964524.121220_at_i39g2000cwa.googlegroups.com>



I was out pair of weeks and, in that time, my previousу topiс changed to discussion "If somebody should say directly all what he thinks about".

I've found pair of interesting(for me) questions, which are waiting to be debunked.

In fact I don't think that any debinking is available after my statement that "The OverRelation Manifesto" offers just special way
(one of possibe ways) of implementation of relation data model in a
system". It doesn't offer some other model and it doesn't offer to changу this model. "TheORM" is about SYSTEM only.

Really "TheORM" could be written twenty years ago. Let s imagine that time. We (You Bob too) had no TTM and we believed that "scalar type" is something like a "simple type"

In my previouse topic I gave an example containing description of SHIPMENT structure, which seems to be complex (0NF) structure. One of ansews contains other structure definition that was described by author as "the better design". Twenty years ago this "better design" (when information about the shipments are stored in two relations – "Headers" and "Items") seemed to be only possible design in relational system.

I think, that it is the better one up to now and I think, that these two relations have to exist anyway. It means, that in system? which implement the system, two relation variables have to be defined. The simplest way is to define they directly - as Alfredo Novoa did http://groups.google.com/group/comp.databases.theory/tree/browse_frm/thread/0194f68088b82cd4/675529ca9d919267?rnum=11&_done=%2Fgroup%2Fcomp.databases.theory%2Fbrowse_frm%2Fthread%2F0194f68088b82cd4%3Ftvc%3D1%26#doc_aaddfc770981fa2e.

var Header base relation { No Integer, WareFrom Warehouse } key { No };

var Items base relation { No Integer, Article Char, Pieces Integer } key { No, Article };
constraint ItemsHaveShipment Is_Empty(Items not matching Header);

Using these expressions we define set of two relvars, which contain two relations. These two relations can be a part of some relational database. Moreover, these two relations themselves can form some relational database ("relational database" = "set of relations"). Also I can notice that full information about shipments contains in both two relations – so these two relvars have to coexist in system.

These expressions are translated in the system to create two system objects, which implements two relvars Alfredo thinks about. Can I use other language expressions to relvar creation? I think I can. For example I can define schema of relation firstly and then create relvar with this schema. Or I can create some relvar using existing relvar as template. This all is just languages potential and translator's possibilities.

What else language expressions we can use in the system to define this SET of two relvars where the first one contains information about headers and second one contains infirmation about Items? "TheORM"'s answer is "to do it we can describe the structure of entity, information on which going to be stored in this SET of relations". So we can define this SET of two relations with next expression

...SHIPMENT
{
  No INTEGER;
  WareFrom WAREHOUSE;
  Items SET OF
  {
    Article STRING;
    Pieces INTEGER;
   }key (Article)
}key (No)

Of course, at that we assume that powerful and smart translator exists to translate this expression. Of course some rules for such description must exist. But anyway, result is the same – the SET of two relvars
(named as "SHIPMENT" and "SHIPMENT.Itmes") will be created in system,

and user can manipulate with values of these variables.

My question for you, dear debunkers, is "How and where does such translator broke relational data model?". Try to debunk this translator.

Little remark. Here I means that the concept "data model" defined as: " …1) a collection of data structure types….2) a collection of operators or inferencing rules…3) a collection of general integrity rules…" (it is true about any data model). In other word RMD is sort of pure mathematics, which do not define how information system objects, which implement this mathematics, should be defined and named
(and what their names mean).

In my opinion you should try to debunk your NUMB DOGMATA on RMD becouse you look like a man who being imbued with arithmetics accuses persons, which do not uses arabic numerals, of principal ignorance of arithmetics. But arithmetics are true in other numerals too – this man cannot understand it becouse he doesn't know these numerals just. Received on Tue May 02 2006 - 18:16:17 CEST

Original text of this message