Re: THe OverRelational Manifesto (ORM)

>>Like Bob, I couldn't find anything new. Maybe you could summarise
>>exactly what problem you are trying to solve...

You can read on this problem in TTM. I just have other solution.

>>...or what you think is "missing" from existing descriptions of RM.

Nothing! I think that relational data model needs no changes to be very useful. But what do you mean when you say " existing descriptions of RM".

I know very simple definition of concept "data model": " ...1) a collection of data structure types....2) a collection of operators or inferencing rules...3) a collection of general integrity rules..." (it is about not only relational, but any data modal) Also I know, that a type is a set of values. It is easy, isn't it?

Of course system, which implement some X-model, has to implement these three items. This implementation must include X-variables assigned to contain values of types existing in X-model. And describing these variables we define a set of names, which named all types, all variables, all elements of their structure and all other thing. It's very important to understand that these names is used to any manipulation on system, on any value stored in this system.

Why do I say about names? Let's imagine we can use two different program systems to complete some task. Using first system we have to introduce 100 different names to name different program objects (I mean types, variables, attributes or something else - it doesn't matter really). Using the second system we have introduce only 50 names. The using of second system seems to be easier, doesn't it? So can I suppose that the quantity of names, introduced in system to complete some task, can be treated as measure (one of measures) of its expressiveness?

By the way - now we can say more definitely why using of usual combination of OO program and relational DB is very hard. The possible answer is because we introduce two different sets of names - one in OO program and second in relational DB. We have to remember meaning of the names twice and (I think this is hardest part) we have to set relationships between this two sets.

Trying to solve these problems people has offered sundry approaches. The first one sounds to be easy. The using of two different sets of names follows from the necessity to use different program objects, which allows to implement different task and to realize different properties. So it seems that we need to find some universal set of program objects, which allow realize all properties we need. For example - does relation looks like class? OK let the something exists looking both like class and like relation and now we need only one name to name this formation. But this is wrong way because it leads to very strange formations and ideas - like un-normalized "relations", mixing of types and variables, very un-formal (and anti-formal ever) admission. So the result is very dismal because the system we've got at last is neither Object-Oriented nor Relational.

"The Third Manifesto" is right absolutely when it tries to find the possible logical relationships between relations and objects to avoid such dismal result. OO and relational properties are orthogonal and it needs different types and different variables to realize these properties. And I believe that this approach allows some reducing of quantity of names we operate with because the names of types defined by us are the names of domain ("type = domain"). So the two sets (we spoke before about) have some intersection. But anyway we have two sets of names.

The ORM's offers absolutely other approach. It also operates with two different set of program object to realize orthogonal OO- and relational properties. But this approach allows use only one set of name for naming of object of these different sets.

I've understood that I need to paint some some for further answer. I can make in three-four hours. Received on Wed Apr 12 2006 - 16:48:48 CEST