Relational data model defines a specification of a type "relation". However, its simplicity does not mean that the system implementing this model must operate with structures having the same simplicity. We consider two principles allowing create a system which combines object-oriented paradigm (OOP) and relational data model (RDM) in one framework. The first principle -- "complex data in encapsulated domains" -- is well known from The Third Manifesto by Date and Darwen. The second principle --"data complexity in names"-- is the basis for a system where data are described as complex objects and uniquely represented as a set of relations. Names of these relations and names of their attributes are combinations of names entered in specifications of the complex objects. Below, we consider the main properties of such a system.
Deep Dive into Why the relational data model can be considered as a formal basis for group operations in object-oriented systems.
Relational data model defines a specification of a type “relation”. However, its simplicity does not mean that the system implementing this model must operate with structures having the same simplicity. We consider two principles allowing create a system which combines object-oriented paradigm (OOP) and relational data model (RDM) in one framework. The first principle – “complex data in encapsulated domains” – is well known from The Third Manifesto by Date and Darwen. The second principle –“data complexity in names”– is the basis for a system where data are described as complex objects and uniquely represented as a set of relations. Names of these relations and names of their attributes are combinations of names entered in specifications of the complex objects. Below, we consider the main properties of such a system.
This paper has appeared as a reaction (but not a responce) to the paper "Integration of programming languages with data bases: what is the problem?" [1]. After reading it, the same perception arises that is induced by the current state of the discussed subject in total. All ideas and remarks by themselves seem true; but, as a whole, we have an image of either a labyrinth or a heap --in general, something where you should not enter.
We will not do this –because the problem of impedance considered in the aforementioned paper as the fundamental one casts some doubt upon its universality mainly. Impedance appears as a side effect in a quite concrete configuration which (in the most general form) includes an OOprogramming system and a relational data bases management system (in quite different its implementations). One should understand that this very wide-used configuration is nevertheless a result of chaotic evolution (dependent on thousands of random factors) of interaction of the systems working with fast memory (RAM) and with slow (external) one [2]. Designers and developers of OO-languages and RDMBS during their creation met a lot of problems more important than the forthcoming problem of matched interaction [15,16].
In this connection, it seems interesting to attract attention to possible logical alternatives of combining OOP and RDM into framework of unique system (especially as such approaches to their creation exist already). The necessity of implementation of such combined systems comes, first, form main features of OO-programming systems [3] since this is a guarantee of rich expressive capacities of the system and, second, from formality of relational data model [4,5] (in what follows, RDM) since it is a basis of data management systems, which provide the mathematically founded group access to the data, and (in this sense) has at present no alternative.
This paper shows ability to create a system that unites these different and orthogonal conceptions (there is no need to change or/and mixture these conceptions themselves). It means an OO-system, which implements relational data model. Such a system is referred below as R×O-system, where the ‘×’ symbol denotes the orthogonality of two conceptions.
Quite broad and indefinite representation of the term “Data Model” is met very often though it was very clearly formally defined by E. Codd [6,17] (who is known first of all as the author of RDM). A data model is defined as a collection of types (where a type is a set of values), a collection of possible operations over instances of these types, and a collection of integrity constraints applicable to the m.
In accordance with this formal definition of the notion “Data Model, " the relational data model (1) defines a type “relation”, (2) introduces operations of relational algebra (applying which to relation, we obtain relation ), (3) defines keys, which allow us to restrict the integrity of data represented in the form of a single relation (relation keys) or several relations (external keys)
In papers devoted to problems of designing next generation DBMS, the relational data model (RDM) is quite often criticized. The usual accusations are “old”, “poor system of types”, “twodimensional data representation”, “atomicity of stored values”, “impossibility to describe the enterprise adequately”, “insufficient semantics” -the list is far from the complete one [7, 10,11,12,13,14]. When you try to delve into these papers or discuss with their authors, two ordinary fallacies appear (usually, combined).
(1) They try to use RDM as a infological tool. In other words, RDM is considered as a tool for description of the enterprise. In such cases, one usually asserts that “the enterprise must be described as a collection of relations " and reasons why such a description of the enterprise seems to be clumsy and more elegant methods are necessary.
Actually, the requirement that data should be described as a set of relations is only a condition allowing one to apply the RDM operations and constrains (on which the group data processing is based) to these data. As an analogy, I can formulate next assertion -if values are numbers, the y can be applied with the arithmetical operation “addition”. The latter raises no doubts; however, this does not imply that mathematics requires that information about the enterprise should be presented in the form of numbers. Similarly, the necessity of data representation in the form of relations has no links with enterprise description.
Another fact demonstrating mistakes of type (1) is the attempts to estimate “semantics” of RDM (they mean the possibility to convey or preserve a data meanings) and compare its “semantics” with other approaches. In this case, we often meet the RDM (as a formalism) to be confused with the relational scheme of data (a concrete collection of concrete relations created in terms of this formalism).
Of course, there exist neither “poor” nor “rich” “semantics”
…(Full text truncated)…
This content is AI-processed based on ArXiv data.
