TheORM.narod.ru (MainPage/ГлавнаяСтраница) (c)Evgeniy Grigoirev 1999-2006
>>>Go to Russian version of this page<<<I couldn't find anything new. Maybe you could summarise
Why is that any different from a relational-valued attribute or indeed
any other type that allows relational assignment? It seems to be
covered by TTM - specifically that relation values are permitted as
values in relations.
**april2006**
OK. My next speculation isn't formal. I just want to illustrate my idea with explanation what (in my opinion) allows make some abstract, very common information system easier to use in case when we have to get both OO- and relational possibilities to work with data.
>>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 believe that relational data model needs no changes to use. 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
orthogonal 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 (domain names). But anyway we have two sets of names.
TheORM 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.
My next simple question is just the analogy, which helps us to understand the
TheORM's idea visually. The circle and the square exist.
Would you be so kind, to find something what combine both the round and the square shapes simultaneously?
I try to help you.
Do not try to use these strange figures.
I will laugh because they are neither circle nor square.
Of course, we can say, that a line is a set of point and each point can be considered as a very little round.
Why not? I think formally we achieve requisite result.
But I can offer some else. Let me mark some points on the circle and on the square.
As you can see I use the same names for both sets of point on the circle and on the square. By that I want to say that this is the same set of point. We just see these points from different points of view. It allows us can say definitely what is the something what combine both the round and the square shapes.
In the same way set of objects and set of the relations are considered by TheORM as orthogonal projections of very complex-organized set of simple variables. Both these projection can be described with the same set of name. All, what we need to define this set and these projection, is main requirement of TheORM: " The value describing the state of an entity of an enterprise must be represented as a set of relation values "
Let view on next type specification.
CREATE CLASS SHIPMENT
{
No INTEGER;
WareFrom WAREHOUSE;
Items SET OF //-- and this is a set of invoice lines
{
Article STRING;
Pieces INTEGER;
}
}
Of course, this specification describes complex objects evidently. This is object. It can be created (and deleted). To access this object we have to use its OID. Its component can be implemented in different ways. It has complex structure(0NF). It is a part of more complex structure, because it contains reference on some object of WAREHOUSE type and we can use path expression to get access to WAREHOUSE object.
Like in other OO systems predefined set of simple types exist, which is used for creation any complex types. Reference contains value of TOID type, which is one of these predefined types. TOID type is very simple. Only three operations are (comparison, assignment and implicit dereferencing) are defined for variables of the reference type. The last one means that any operation except for the operations of assignment and comparison is executed on the object (not the reference variable) referenced with this variable.
But this set of objects is just the one of two system projections. Let us
call it OO-projection.
And (according to TheORM) this specification also defines existence of set of relational
variables (R-variables). These relational variables form the orthogonal projection, in which the same data is organized with other (relational) structure.
Is is important, that all elements of this projection are defined with the
names, which are introduced in type SHIPMENT specification. Each of these variables contains some data about ALL objects of this type, which exist in system. Of course this relation are defined on the same set of type.
Once again - we use in this projection the names, which was introdused in type SHIPMENT
specification, which describe OOprojection object. Sometimes they combine as complex path expressions (like "SHIPMENT.Items" or "Items.Article"). But formally they are just names here. Their complexity,
which means what complex structure is defined in orthgonal OO-projection, exists
doesn't matter for RM, which describe this projection.
These relational variables can be used right after type SHIPMENT was specified. It means, that right after type specification we can use any expression, which uses these variables. For example I can create query
SELECT No FROM Shipment WHERE Items.Article = "Art1".
or
SELECT Article FROM Shipment.Items WHERE Pieces = "Art1".
The names, which seem to be complex path expression, impresses on us that we make a query on
complex structure (structure of OO-projection).We can work in such way with any complex structure – the common rule for definition and naming of possible R-variables says that the definition of complex reference structure, in which path expression
n1.*1.*2.nz is correct, can be interpreted as definition of a relation variable named as
n1.*1, in which the scalar attribute with a name *2.nz
exists. But really these are pure relational expressions (don't take in your head that I use SQL-like expression for explaining). You can read in
TheORM how names of these R-variables and their attributes are built and how their values are calculated.
The fact, that set of the objects and set of the relations are considered as orthogonal projections of very complex-organized set of simple variables, means that any changes of data in one projection results in the same changes in other projection. So, we can operate with data in both OO and relational projections simultaneously (Read
TORM about what we can get with this possibility).
By the way I have other suggestion about TTM. I don't think it's a good idea to forget, that all these systems, all programming languages etc. are just an instruments for creating complex information system on computers, on some hardware what realize short set of very simple types. TTM is true formally when it says about arbitrarily complex scalar values but what is situated between these complex scalar values and values of those simple types which realized by hardware? TTM says that relational system only needs to realize complex domain but no idea what are the values of these complex scalar domains inside? Practically it is one of biggest "only"s I've ever seen.
It's very interesting question because in my opinion all this means existence of some object sub-system realizing this complex domain. To realize these complex scalar values this sub-system uses different combination of values of simplest types. So trying to analyze TTM system in
common (as it can be realized on some computer), we've found two layers – the first one, where we realize the complex scalars (but there is no relations here), and second one where we've got relations at last (but all objects…. looks like a points (scalars) here).
In contrary there are no layers but two projections in TheORM system (R*O system). These two projections always coexist and can use each other in any way. OO projection allows describe complex enterprise. Any description existing in object projection means, that the data is also described as set of relation. Relational projection allows implement formal relational model to the data with using the names, which was introduced in description of the enterprise. We don't need to seacrh something to far-fetch
some concepts of very formal relational model to describe of the complex enterprise. And set of base types R*O system seems to be enough simple to be easy realized by computers hardware.
Can I assert now that TORM's approach seems to be more expressive, more usable, more relational and more object in the same time?
>>Why is that any different from a relational-valued attribute or indeed any other type that allows relational assignment?
Because the relation, which this attribute is defined in, cannot be inherited (a relation is not a type). Because we cannot re-implement this attribute. Because the tuple, containing such a value, cannot be referenced like
TORM's object can. I try to explain it in detail answering you on you next question.
SUMMARIZE SaleItems PER {Article} ADD SUM(Pieces) AS TotalPieces
If the problem is a parts explosion then you need the TCLOSE operator
in there as well (which is something not directly supported by SQL
incidentally).
What am I missing?
**april2006**
I think you don't understand my question. The problem I speak about isn't derived relations or transitive closure. I speak again about the ways to make system more expressive. One of such ways is the using of polymorphous types.
I think you know three words which sounds like mantra for OO people - "encapsulation", "inheritance" and "polymorphism". I believe that the good way to achieve these three really helpful
things is splitting type definition in two parts – type specification and type implementation. After this splitting we can define…
…encapsulation as ability to hide type implementation,
…inheritance as ability to re-use some type specification once and once again.
… polymorphism as ability to change implementation for different types which have the same specification.
By the way! Now I can say why these three concepts is really helpful. Because they really allow reduce the number of names using to create some system. Encapsulation means that we cannot know names, which aren't necessary for us. Inheritance means that we don't have to repeat some specification for different types. Polymorphism means that we can use only one name to
use possible different implementation of system components. So we speak again about expressiveness of system language.
For example in monomorphous (not polymorphous) system for describing some actions on similar but not equal structures we have to use different functions. And when we create a program we have to obviously call which of this function have to
be called for which structure. It looks like
If structure1 then call function1(); If structure2 then call function2();
It's bad because we have to know a lot of names and because any changes (for example structure3 appears) drive to necessity to change every piece of code where such IF construction exists. In polymorphous system we just have to write something like
SomeClass.somemethod()
Then, if some change occurs, we have to inherit SomeClass and to change implementation of somemethod(). But we continue to use the same name for call this new implementation and we don't need to check or change existing code.
Now about polymorphous types in TheORM. Of course I don't mean polymorphous in relational projection, because there is not such operation in
RM (as far as encapsulation and inheritance). But OO-projection is real polymorphous and this fact is very helpful (in my opinion) for
simple using of relational projection too.
Let us recall the type specification I give before
CREATE CLASS SHIPMENT
{
No INTEGER;
WareFrom WAREHOUSE;
Items SET OF //-- and this is a set of invoice lines
{
Article STRING;
Pieces INTEGER;
}
}
I would repeat once again, that this is just specification, just interface which can be used in other parts of system to define how objects of this type can be used. Also (in ORM case) this specification also defines existence of set of relational variables (R-variables), their names and structures. Therefore we can define some view accessing these R-variables right after this specification.
CREATE ShippedGoods AS SET OF
{
Article STRING;
Pieces INTEGER
}
IMPLEMENT AS
SELECT Article,Sum(Pieces)
FROM Shipment.Items
GROUP BY ShipmentItems.Article;
Some implementation of this type has to be defined before creation of its first variable
(the system cannot manipulate with value, which
is contained in the variable, until real(incapsulated) structure of the variable and these manipulations are defined in
detail).
For example we implement Items component as stored.
ALTER CLASS SHIPMENT IMPLEMENT Items AS STORED.
So in object of class SHIPMENT its component Items stores some values long-term. I show it with blue color. (OO-projection)
Of course R-variable SHIPMENT.Items contains this values too. (R-projection)
Then we define new type to describe sale events. But every sale is a shipment too, so we define type SALE as subtype of SHIPMENT.
CREATE CLASS SALE
EXTEND SHIPMENT
{
...
SaleItems SET OF
{
Article STRING;
Pieces INTEGER;
Price FLOAT;
}
}
We have to store information about each sale line
ALTER CLASS SALE IMPLEMENT SaleItems AS STORED;
Because of sold quantity of goods have to be shipped from warehouse, we have to re-implement inherited from type Shipment component Items as calculated on values contained(stored) in component SaleItems
ALTER CLASS SALE IMPLEMENT Items AS SELECT Article, Sum(Pieces) FROM SaleItems GROUP BY Article;
So in each object of class SALE component Items is calculated. I show it with red color.
(OO-projection) 
After class SALES specifying new R-variable SALE.SalesItems appears in relational projection. (R-projection)
R-variable SHIPMENT.Items contains all data of SHIPMENT objects even they are objects of derived class SALE, because component Items specified in class SHIPMENT was inherited with class SALE. But now it contains not only "stored" (blue) values but also "calculated" (red) ones. Therefore view ShippedGoods, defined right after class SHIPMENT specification, will work now both for SHIPMENT and for SALE objects without any
changes.
You can see what we don't have to use "UNION" obvious to unite
data which is stored in different relation (in my opinion it looks like we don’t' have to use IF expression in polymorphous languages).
Also the names of R-variable (here it is SHIPMENT.Items)
can be bound to the extendible set of implementation expressions. And R-projection is
still relational system because there is only relations here.
My question was: is it possible to realize such a case with D language?.