Some quotation.

"
...
... the “The Third Manifesto” is formal and logical. However, The OverRelational Manifesto (TheORM) cannot unconditionally accept the claims of the “The Third Manifesto”, because, in our opinion, the premises, which are its basis, are incomplete. Recall that, answering the first question “What concept in the relational world is the counterpart to the concept "object class" in the object world?”, the “The Third Manifesto” considers the two possible versions
1. domain = object class
2. relation = object class
"The Third Manifestо" argues strongly that the first of these equations is right and the second is wrong (TheORM agrees with this) and, further, its arguments are based just on the first version.

Note that TheORM does not claim that the propositions of the “The Third Manifesto” are erroneous. However, TheORM does not doubt that these two answers (even the right one) to the question in the preceding paragraph are not only answers to the question about the possible relationship between the “object world” and the “relational world.” There is another approach that can be described by none of the answers proposed in the “The Third Manifesto”.
...
...

TheORM assume that the value describing the state of any entity is a set of relations (or, more definitely, relation values), which is a subset of the relational database describing the state of the whole enterprise.
...
...

TheORM claims that a system that allows to specify explicitly and to manipulate such subsets is the required system that possesses the properties of both object and relational systems. Accordingly, the main requirement of TheORM is the following:
The value describing the state of any entity of an enterprise must be represented as a set of relation values.

Any system satisfying the main requirement will be referred to as an R*O-system.
Remark. Therefore, to relate the “object world” and the “relational world”, TheORM associates object with a set of relations. Note that the concept "database" appearing in RMD is also defined as a set of relation. Essentially, ORM regards the database as a collection of subsets (not necessarily disjoint, even embeddings are possible); by definition, each subset may also be considered the database.
...
...
The type system necessary for description and manipulation of data, constraints on the data integrity, and a set of operations are described. It is shown that complex structure definition, in which these types are used, can be treated as definition of set of relational variables (R-variables). The common rule for definition and naming of possible R-variables is formulated, which asserts that the definition of complex reference structure, in which path expression n1.*.*.nz is correct (where "*" is any, possible empty sequense of names), can be interpreted as definition of a relation variable named as n1.* , in which the scalar attribute named as *.nz exists
...
...
...the specification of an object type does not define whether the values of its components are stored or calculated. A component implemented in the parent type as a stored one may be redefined in a successor type as calculated (and vice versa)....Strongly speaking, the value of an R-variable should, of course, be calculated and this value is the UNION of several values some of which may be implemented as stored, while the others are calculated....However, in any case, the R*O system must calculate the values of any R-variables implicitly for the user. Only the type specification is necessary to use R-variables.
...
...
Thus, if we have an object type t, in which a component a is defined, and R-variables corresponding to this type are used in queries and methods, then, after creating a type t* that inherites a type t and redefines the implementation of component a, we have to do nothing to use re-implemented component in these existing queries and methods.
...
...
In the second part, we are going to show that the R*O system can be created on the basis of existing relational DBMS.
...
...
As has been said in the first part of the study, data in the implemented R*O system are represented by values of object components and, simultaneously, by values of R-variables. We will refer to the realized totality of objects and R-variables as the data representation level. It should be understood that the data representation level is realizable and, hence, is virtual. One may speak about the existence of objects and R-variables of the representation level only as far as there exist a collection of commands for manipulation with the objects and R-variables (including the valued stored in them) and a program executing these commands. Receiving a command, this program transforms (translates) it into a command or a sequence of commands of the RDBMS being used. Executing these commands, the RDBMS manipulates with the data stored in the tables. The set of relation variables realized by the RDBMS (i.e., tables) will be referred to as the data storage level. Note that the data at the storage level are nothing else but a relational database.
...
...
But, in our opinion, of significant interest is the fact that the used RDBMS realizes the set operations determined by the relational model. On this basis, one can show that an expression f (for example - some method) defined at the representation level can be translated into an expression stf' of the storage level such that its single execution (no iterators!) results in the changes of the system such as if the initial expression f were executed for every object of type t existing in the system.
...
...
The OverRelational Manifesto confirms the most important positions of its predecessors. Similarly to "The Object-Oriented Database System Manifesto" it supports the idea of long-term stored complex objects. Similarly to "Third-Generation Data Base System Manifesto" it assumes that the existing systems for data storage can be used and developed. Moreover, similarly to "The Third Manifest," it tends to preserve the purity of ideas of the relational data model.

On the basis of the approach proposed by TheORM, a system can be developed, which can be treated, first of all, as a system for creating an adequate, active, and long-term model of the enterprise that is controlled by the user and provides the user with data about its state.
...
...
"

Dear ALL. You can find full version (preprint, PDF, 37 pages) on www.TheORM.narod**** or on http://www.arxiv.org/abs/cs.DB/0602052

I'm very interesting for your opinion on the ORM. You can leave you messages here, or in GuestBook of www.TheORM.narod****, or by e-mail grigoriev.e@yandex****.

i think you have the wrong website, grigor

you should post that over on dbdebunk.com, not dbforums.com

here on dbforums we discuss database design, not manifestos

Hi

1) There is no forums there

2) I sent a question to dbdebunk about month ago...
...I have a question concerning "The Third Manifesto".
The reasonings and conclusions are very persuasive, but initial assumption, which these reasonings and conclusions are built on, do not seem to me full. I mean the question " What concept in the relational world is the counterpart to the concept "object class" in the object world?" and two answers
1. domain = object class
2. relation = object class
I'm not sure that these two answers (of course, the first one is true and second one is false) are only possible. And what is more - I'm not sure, that the question itself is only one question we should answer to find relationship between objects and relations. Really these assumptions look like just your personal opinion, because there is no any argument for adequacy of only these cases.
So, how can you argue this assumption?...
...and I had got only Fabian Pascal's remark about resending this question to Mr. Darwen. No answer then. I don't think they have any argument I ask about.

3) So if I cannot be listened by guys from dbdebunk I try to be listened by somebody, who has interest on this field, else. And I very hope, that such persons exist here. That's why I've posted that here. But If any other proper places exist let me know, please.

By the way, as I see this forum is named as "Database Concepts & not only Design".

i was kidding you

this is actually a good place to discuss concepts, however, in my experience you will get very few people interested in theory here

that's because we're all actively working on the actual practice of using databases, rather than theory

kind of like the bumblebee, which is too stupid to realize that it cannot possibly fly (ask any scientist), we database practitioners are far too stupid (ask fabian underpants) to realize we can't possibly use existing so-called relational database products

we for sure wouldn't be interested in something even better than relational databases, because we couldn't possibly use that, either

Rudy is just giving you grief... He's good at that

I'm interested, but a wee bit busy right now. I'll try to review this information and post a couple of meaningful observations/questions, but it might well be a few days before that happens. I'm kind of "in the thick of things" right now.

-PatP

I'm sure you'd get a lot more response over at comp.databases.theory, where this level of discussion is a lot more common.