OBJECT-RELATIONAL DATABASE DESIGN

RELĀCIJU-OBJEKTU DATU BĀZES PROJEKTĒŠANA

A.Stepanovs, J.Eiduks

Keywords: a hybrid DB management system, extended relational technology, persistent objects, object-relational DB, server procedures, row-type objects, column-type objects, heterogeneous object set, object collection table, object table.

Design and implementation of the information systems (IS) is the most decided tasks in the enterprises of information technologies. The IS main components are data base (DB) and software application. Technologies of its realizing have rapid developed isolated one from another. But the further IS making efficiency increase is impossible without improving collaboration of both these technologies. It has been much done for customizing the data base to object-oriented programming technology. Object-relational DB has been created. In this work has been analyzed what kind of possibilities are to realize object structures of object-oriented technologies in object-relational DB, how qualitative there are the existing transformations and what corrections and improvements should be implemented. Transformations elements have been analyzed and completed to provide the more qualitative transformations of object-oriented conceptual model to DB logical model.

Introduction

Data Base (DB) technology in its beginning has been developed isolated from application software or application development technologies. For the data exchange between the application and DB at first were produced specialized (for each DB management system) interface libraries. It was standardized later. Maturing complication (the graphic data, temporal data, and hierarchical data) of the used data structures and developing of object-oriented programming still more actual became a question about the efficiency improve of programming and DB data exchange.

Working with complicate data it is advantageous to organize data together with its procedures and functions, which execute manipulations with it. In the programs objects were formed as associations of data and methods. Till with there was a desire, although the DB complicate data and its treatment methods would form such objects. There were attempts to create object DB. Unfortunately the variants of object sturgeon were not found in an external memory, which provide effective (rapid) data retrieval. Need to remember also, that DB is not a persistent storage place of application data [1]. DB is formed for many applications and there is also its „life”

it, independent from applications (DB form, data input, management, optimization, safety enterprises). The objects of the programs and DB exist in different environments: in the operative memory and in an external memory (with exceptions). Object implementation DB was started to execute in a revolutionary kind, without a serious mathematical basis.

Examining relational DB technologies and object-oriented technology association need to be understood, that this situation differs from previous, when a revolutionary transition was executed from the prior relation DB systems on the relational DB systems. The first DB system solutions (DB + DB management system) were formed using technical ideas, which had appeared in a few years experience of working with large data volumes. Certainly, these systems had much imperfection, because there was no incorporated look on a problem totally. In the end of 1970th the mathematical basis were produced for relational data bases and already almost for 30 years the relational data bases or SQL data bases are spacious used for the forming of information systems. It can be explained with its serious and successful mathematical ground, which was produced by T. Kodd and his research group [2].

Developing DB with object-oriented structures; there is a desire to save basic framework of the relational systems, which has proved its decent properties in exploitation of many years [3]. After the ideas of a few lead specialists [1, 4], in the relational DB model the possibilities to use complicate data (new types of data) are potential included already, unfortunately the systems of the existing relational DB management are not realizing it. Therefore it often is been called also the pseudo (almost) relational DB systems.

Object-relational DB management systems

The association of relational database (DB) and object-oriented technologies can be executed using various approaches [4]:

1) Forming the hybrid DB management systems;2) Using of the extended relational technology for

DB development.The guidance systems of hybrid DB use the same

guidance mechanisms of data as relational DB, but the object-oriented external interface is been formed for it. It executes in the necessary structures of objects of transformations of structures of relational data and vice versa (Fig 1). Unfortunately execute of relational-object and an object-relational transformation worsens DB system performance. Despite this basic lack, this approach in the end of 80th was spaciously used for forming repositories in the CASE (Computer-Aided Software Engineering) and CAD (Computer Aided Design) systems [4].

The DB of the extended relational technology management systems completed the structures of relational data with objects and provided the desirable possibilities of data manipulations (Fig. 1). This technology in the 90th acquired a spacious confession and there were produced many conformable DB management systems.

Fig. 1. Hybrid and extended relational DBMS

The most spacious researches were executed in the firm IBM scientific centers and in the California University. As the first new generation DB management systems it can be marked Informix Universal Server (Informix Software, 1996), Oracle8i (Oracle Corp., 1997), DB2 Universal Database (IBM Corp., 1997), UNISQL (UNISQL, Inc., 1998).

The management systems of the extended relational DB began to call for the universal DB servers or object-relational DB management systems (object-relational

DBMS). Many specialists of DB technology under professor’s Chris Date guidance, already have marked in the beginning of this technology use that as foundation the relational DB technology is been used, which is complemented including the object-oriented principles [1]. Therefore more correct it will be to call these systems as relational-object DB management systems. Such name exactly would represent the included DB system principles (in the English language books of DB technology and in publications there have inculcated many careless formed definitions, therefore executing its translation, there would be useful to liquidate these inaccuracies).For the additional relational technology of object-relational DB it is performed to:

1) Form the complicate data types defined by user;2) Realize inheritance mechanisms of data and

methods;3) Store DB and to use the object processing methods

of complicate data types.In nowadays in the DB management system market

there are many companies, which produce and sell object-relational DB servers: Daffodil Software, Ltd. (Daffodil DB), EnterpriseDB Corporation (EnterpriseDB), FirstSQL, Inc. (FirstSQL/J), The GigaBase Project (GibaBase), IBM (Cloudscape and DB2), InterSystems Corporation (Cache’), Micro Data Base Systems, Inc. (TITANIUM), OpenLink Software, Inc. (Vituoso Universal Server), Oracle Corporation (Oracle), Paradigm Software (Valentina), PostgreSQL Global Development Group (PostgreSQL). The most spacious attention got the Oracle DB management systems (more than 1/3 from total amount) and DB2 (about 1/5). Many of the theoretical innovations have been inculcated in the PostgreSQL systems [5, 6, 7].

Multilevel architecture of information systems and transformations of data structures

The typical architecture of the modern information systems is being formed from several layers [8]. DB, DB interface, middleware, web and client levels are ordinary selected (Fig. 2). DB in same queue is formed by the DB persistent level (storage of data structures) and DB virtual level with views (object and ordinary), server stored procedures and procedures of the DB active rules – flip-flops. Designing and executing making of multilevel information systems, actual enough is a question about simplifying and providing efficiency of multilevel data structures’ connection. Various methods and instruments have been developed for executing these transformations

(mapping). It can be selected the following main groups of transformations:

1) Software objects (usually server software) à forming of persistent object in relational DB. This is object-relational transformation (object to relational mapping). This transformation is used in the cases when a software at first is been formed in object-oriented programming and DB is not created yet [9, 10]. The conformable structures of relational DB have been developed for the storage of object data. There is a spacious variety of tools to execute such transformations (for example, EclipseLink (Eclipse Persistence Platform), Hibernate [11], Java Data Objects (JDO), Object Relational Bridge (Apache OJB), TopLink by Oracle, (Torque, GenORMous).

2) Software objects à forming of the persistent objects in object-relational DB. It is an object - object-relational transformation (object to object-relational mapping).

3) DB relational and object-relational structures à objects of the DB stored procedures. Transformation of this type in the object-relational DB systems is ordinary automatized (publication of DB data objects (publishing process)) and it allows simplifying making of server stored procedures.

4) DB storage data objects à business objects (objects in the server software programs). It has been formed one more layer of virtual data objects to exactly adjust to the information system tasks. Object-relational transformation variant started to be used more widely.

5) In the integrated development environments (IDE) of the new generation information systems in the software developing programs the possibilities of using the conceptual data charts (ordinary UML type (Unified Modeling Language)) and to generate data storage structures of relation or object-relational DB from it already are included. The object-relational or object - object-relational transformations (object to object-relational) have being executed.

There are a few substantial failings of the developed transformation algorithms [12, 13]:

1) Object-relational transformations (object to relational) not always can provide adequate transformations, because there are substantial differences in the conceptions of relational and objects technology.

2) Executing automatic transformations of relational structures in the existing realizations only the DB permanent level is being used mainly. It is possible

to include the virtual level structures (views, flip-flaps) executing manual corrections only.

3) Executing automatic transformations of objects on object-relational structures the DB virtual level also is used poorly (object views, stored procedures). The use of object views, object identifiers and references allows substantial to increase efficiency of the obtained structures.

So for the organization of an effective collaboration between objects of object-oriented programs and data storage structures of DB:

1) The relational DB systems need to be replaced on the object-relational systems (often the replacement of DB management systems is not necessary, because the most widely used DB servers include both relational DB and object-relational DB possibilities);

2) The effective transformation of object-oriented technologies’ objects needs to be developed and apply in the object-relational DB structures (very primitive, simplified transformations are being used).

Fig. 2. The architecture of multilevel IS with object-relational server

Object-relational DB data storage structures

As already has mentioned, object-relational DB basic structure or framework is being formed of relational DB, which has developed object superstructure [14].

Fig. 3. Main object-relational structures of the Oracle10g DBMS

Therefore object-relational DB implements all the possibilities of relational DB and in addition:

1) Forming of row-type objects and column-type objects. Using object identifiers (OID) references may be done on row-type objects.

2) Its operating methods are linked to the objects;3) Operating methods are linked also to the object

views objects;4) Inheritance mechanisms of data and methods are

being implemented;5) In many situations it is possible to view the objects

also as an aggregate of column values of relational table. So transformations from relational data to objects and vice versa have been implemented in object-relational DB.

6) The Structure Query Language – SQL - is complemented with new functions, which provide determination of objects, data input of objects and execute of manipulations with object data.

In the various object-relational DB management systems (Oracle, DB2, PostgreSQL) object superstructure is being implemented essentially different [15, 16]. The basic in all are the user defined object types. One from the thought over and most effective solution of object superstructure belongs to the Oracle company [7]. There have been developed the object tables (tables with row-type objects), tables with column objects (use of column-type objects), tables with included object collections (nested table), and tables with heterogeneous objects, which allow to implement inheritance mechanisms (Fig. 3). Tables with the included collections also allow forming effective hierarchy of object structures. Great DB designing possibilities allow realizing the object views and its hierarchies.

The object-relational DB structures have been formed by frameworks of relational tables and by included various complication objects. As a result the complicate structures, which conform not to one used object of object-oriented technology, but to whole, object structure. It can promote an efficiency increase of data exchange and the objects’ transformation of object-oriented technologies should be taken into account producing the object-relational DB structures.

The use of object identifiers and references not only promotes a rapid operation increase of data retrieval, but gives widely possibilities to realize a various link types (Fig. 4). Instead of relational technology, links are one-way in this case. It allows realizing a link type „many-to-many”, exclude OR type constraints, as also many others constrains for links in complicate structures.

Fig. 4. Variety of object links realizations

Designing technology requirements for DB

The improvement of the mutual transformations of objects and object-relational data structures is necessary also from the point of information systems’ designing technologies.

In last ten years much considerable conclusions have been done looking after and analyzing the designing and developing experience of information systems. The developing models recommended by Agile Alliance are widely supported and used [17, 18]. Developing of the information systems is suggested to execute as an iteration procedure, the separate small stages or time-boxes of which last from 1 - 4 weeks. After the each iteration prototype of information system is being estimated and criticized. In result the purposes for the next iteration are determined. Such a work style grounds on the analysis of customer possibilities. Although how careful we execute questioning of the following potential users in the beginning of designing, they are not capable to determine their own requirements in details. Only after meeting the created prototypes of the information systems, more grounded presentation of own desires appear.

The Agile Alliance offered technology is a reaction on the use of „heavy” and „bureaucratic” designing and developing technologies. A large volume analyzing works in the beginning of designing often is vainly.

The Agile Alliance technology reduces not only on introduction of an iteration designing process. Also according tools are necessary, which can provide this process. Executing an iteration action often needs to make additions and correction in the existing variants. Therefore you must provide the DB and software clarification should be done as simple and maximal automatized as possible.

The DB designing chart using CASE (Computer-Aided Software Engineering) technology is shown in Fig. 5. The conceptual model of information system is being formed, its realized transformation to the DB logical model, in the logical model the additions are made and the DB physical model is generated. Starting new (improvement) iteration, the conceptual model needs to be specified with a help of re-engineering. But it is possible only then, if the changes made in the logical model in principle can be included in the conceptual model. Therefore conceptual model needs to contain elements, which form the accordingly structures in the logical model. If in the each iteration specifying the conceptual model it will be necessary again to complement the logical model with any changes, which have been done already beforehand, the work will be ineffective. Abandoning determination of the DB virtual

structures on the level of DB logical model, the examined situation appears. So the use of Agile Alliance technology requires executing substantial expansions in the conceptual data model of IS.

Fig. 5. Automatized designing chart of IS

Realization of typical object structures in object-relational DB

The most typical conceptual diagram structures of data objects (diagrams of classes) are inherit structures: generalization, specialization, aggregation and composition. Specialization is a complement of main class data with the subclass data. Generalization is a complement of subclass data with the main class data. Aggregation and composition realizes „a part – a whole” reproduction. Composition means the parts do not exist without whole. Aggregation specifies the parts exist also on itself.

Inheritance or “is-a” link allow the same real-world entity to be instantiated into several object types. This is

called a multi-instantiation. An instance of subclass can be associated with only one instance of superclass. An instance of superclass can be optionally included as a member of any number of subclass. It is not required that every instance of superclass should be a member of a subclass (Fig. 6). Sometimes we specify that different subclasses instances must be disjoint or may overlap (disjointness constraint).

Fig. 6. Types of superclass object instances

For the realizing of objects’ basic structures of class diagrams the most typical solutions for object-relational DB are related with using of inherit possibilities – using of tables with heterogeneous objects. But other solutions are also possible. Using of object views or tables with collections provide thgenee forming of generalization, specialization, aggregation and composition of a high-quality realization. Also variants with joint use of these technologies are possible. The object views provide an attachment of a various type objects and methods to the total data storage structure. In the tables with object collection several collections of one level and its hierarchies can be created. Also an attachment of various methods is been provided in various levels. It allows to design methods’ inherit possibilities.

In practice, for example in spatial DB, different combinations of standard inheritance structures are used: specialization with both disjoint and overlap constraints, lattice structures, “is-a” links hierarchies and composition hierarchies (Fig. 7). First structure could be realized in object-relational DB with the help of built in inheritance mechanism (tables with heterogeneous objects) and object views. For lattice structure realization two tables with heterogeneous objects and additional object view for subclass C instant union are used. “Is-a” link hierarchy is implemented with one table with heterogeneous objects and additional view for subclass B instance merge. Using of composition components means that we must use large objects with different type sub-objects (object hierarchies and collections).

As data transformations can be realized in various variants, before the transformation of the data conceptual model to DB logical model you have to make definitions of transformations, specifying the elements of conceptual model and of the logical model and correlation of its structures. Various designers can have different solutions

of transformations [19, 20, 21]. They are stipulated by experience and understanding of DB designing.

Fig. 7. Inheritance structures of the class diagrams and its realization in object-relational DB

Forming objects in relational DB you need to remember also the possibilities of used extended quire language - SQL. In the DB management system Oracle variant it provides manipulations of objects and possibilities of the virtual transformations [8]. The table of objects is formed as a structure, which can be examined both as an aggregate of row-type objects and as a relational table. Collection of objects also can be analyzed as a structure of objects or as a structure of conformable relation. In the extended quire language the wide alternative of objects, object sets and of collections processing functions is included.

Executing the conceptual model transformation of relational or object-relational DB structures in the CASE designing tools or IDE designing and operating tools the laws of transformations are determined for separate elements of the conceptual model or for basic structures. Often this only is insufficient. As already was mentioned, object-relational DB use is oriented on realizing of complicate data objects. The complicate data object in the

conceptual data model is being formed by several classes, structures and links. Object-relational DB is often desirable and is useful to realize it as an incorporated structure (for example, table with complicate objects, which are formed by the subordinated objects and collections of objects). For specifying of such realizing variants in the conceptual diagram the clusters are use [22, 23].

Dawn of cluster use can be found in use of packages. They were used to execute decomposition of big conceptual models. Little by little was noticed, that it is useful to execute the grouping of conceptual model elements also for selecting and specifying a group of incorporated elements with certain semantics. To mark such grouping the term of clusters is used.

Clusters provide links of internal classes’ objects and object links of other model part with the internal classes’ objects. A grouping into clusters is executed using various principles. The most typical variants are abstraction grouping, dominance grouping, relationship grouping, and constraint grouping (Fig. 8).

Fig. 8. Using of clusters for the association of separate structures of the conceptual model

Realizing a general transformation of semantic close linked conceptual model elements and of structures, allows valuable to estimate the use of association and its components. Data retrieval priorities can be determined

more basically and clearly. It, certainly, allows obtaining better results. The amount of used transformation laws matures, because combinations of the simplest laws appear. Possibilities of the alternative solutions appear also, therefore it is useful to realize transformations in an interactive mode (if necessary, a designer specifies his prior solutions).

Alike as the relational DB designing also in the object-relational DB designing the transformation of the conceptual data models in the DB structures are much simplified and the DM virtual structures are used minimally. In the automatic transformations it practical is not included. In the object-relational DB forming of hierarchical objects’ structures is poorly used using tables with collections and heterogeneous objects. Also the use of object identifiers for forming of various woody structures is not detailed.

The DB designing is multicriterial and multilevel. The DB structures are valued:

1) From the understanding simplicity point of view. Its semantics needs to be very easy perceive (3rd and 4th normal form criteria are used (3NF, 4NF)).

2) From the point of data retrieval rapid operation view;

3) From the point of changes’ realizing simplicity view (providing the use of Agile designing technology).

To take these criteria into account successful, the DB designing is executed in a few levels, but with a condition, that the all levels formed elements in an incorporated system contain in the conceptual data model. The basic levels of the DB designing conceptual model are:

1) Forming and analysis of data functional relationship diagrams (3NF, 4NF);

2) Forming of basic structures of the conceptual data model and determination of transformations;

3) Improvement of the virtual structures (views, stored procedures);

4) Designing of flip-flaps.Analyzing conceptual data diagrams structures of the

data objects and permanent and virtual structures of object-relational DB, as also its combinations, the 70 laws of transformations were developed with duplicating variants. They were realized in the object-relational DB designing in CASE tools, for processing of which the Eclipse environment of integrated developing of the information systems was used. Multilevel architecture of the conceptual model was realized also in designing tool. This tool has been approved executing the developing of the information system of the Latvian forest and fruit trees genetic data together with the specialists of Latvian State Fruit-growing institute. Designing and developing

motion has showed the including of innovations described in this work in a designing tool has substantial facilitated and improved a designing process and its quality.

Conclusions

1) The permanent and virtual data structures of object-relational DB can provide effective and semantic exact forming the storage structures of complicate objects of object-oriented program, as well increase of data retrieval rapid operation.

2) The object-oriented technologies in the objects’ transformation DB structures are very popular. Relational DB is mainly used, which already is improper in the conception frames. Detailed analysis of object-relational DB structure little by little corrects this situation.

3) The use of object-relational DB allows effective to realize progressive technologies of the information system designing, because provide better possibilities to correct elastic the DB data structures.

4) For the efficiency increase of object-relational DB data structures it is desirable to determine and to use transformations not only for separate elements of the conceptual model and basic structures, but also for clusters.

5) There are very much duplicating variants for transformations of conceptual models structures of data objects to the object-relational DB structures. That’s why more careful systematization and estimate of it is necessary.

References

1. Date C. An Introduction to Database Systems. Eight edition. – USA: Addison Wesley, 2005.

2. Codd E. A relational model of data for large shared data banks – San Jose, California: CACM, 1970.

3. Date C. Database in Depth. Relational Theory for Practitioners – USA: O’Reilly, 2005.

4. Simon A. Strategic Database Technology: management for the year 2000. – San Francisco, CA, USA: Morgan Kaufman Publishers, Inc., 1995.

5. Mullins C. DB2 Developer’s Guide. – USA: Sams Publishing , 2004.

6. Matthew N., Stones R. Beginning Databases with PostgreSQL: From Novice to Professional, Second Edition. – USA: Apress, 2005.

7. Loney K. Oracle Database 10G: The Complete Reference. – USA: McGraw-Hill , 2004.

8. Draheim D., Weber G. Trends in Enterprise Application Architecture. 2nd International Conference, TEAA. Nov.–Dec. 2006. – Berlin, Germany: Springer, 2007.

9. Chan C. Object-Relational Mapping with Apache Jakarta OJB. – USA: O’Reilly, 2003.

10.Ambler S. The Design of a Robust Persistence Layer for Relational Databases. – USA: Agile Data, 2005.

11.Minter D., Linwood J. Beginning Hibernate: From Novice to Professional. – USA: Apress, 2006.

12.Marcos E., Vela B., Cavero J. A Methodological Approach for Object-Relational Database Design using UML. Software System Modeling. – Berlin: Springer-Verlag, 2003, pp. 59–72.

13.Marcos E. et. al. Aggregation and Composition in Object. Relational Database Design. – Madrid, Spain: Springer-Verlag, 2001.

14.Date C., Hugh D. Foundation for Object/Relational Databases: The Third Manifest. – USA: Addison-Wesley, 1998.

15.Saracco C. Universal Database Management: Guide to Object/Relational Technology. – USA: Morgan Kaufman, 1999.

16.Brown P. Developing Object-Relational Database Applications. Part 1: database analysis and design methodology. – USA; Data Management Research, IBM, 2002.

17.Ambler S. Agile Database Techniques: Effective Strategies for the Agile Software Developer. – USA: Wiley, 2003.

18.Ambler S., Jeffries R. Agile Modeling. Effective Practices for Extreme Programming and the Unified Process. – USA: John Wiley & Sons, 2006.

19.Mok W. Designing nesting structures of user-defined types in object-relational databases. Information and software technology. – Newton, MA, USA: Butterworth-Heinemann, 2007, pp. 1017-1029.

20.Eessaar E. Whole-Part Relationship in the Object-Relational Database. Proceedings of the 10th WSEAS International Conference on Computers. July 13-15, 2006 – Athens, Greece: Vouliagmeni, pp. 1263-1268.

21.Vara J. et. al. Support Model-driven Development of Object-relational Database Schemas. A case Study. ICMT 2009. – Berlin: Springer-Verlag Heidelberg, 2009, pp. 181-196.

22.Teorey T., Lightstone S., Nadeau T. Database Modeling & Design. Logical Design. Fourth Edition. – USA: Morgan Kaufman Publishers, 2006.

23.Feldman P., Miller D. Entity Model Clustering: Structuring a Data Model By Abstraction. Computer

Journal 29. – London, UK: Oxford University Press, 1986, p. 204.

Andrejs Stepanovs, Riga Technical University, Meza 1/4, Riga, LV 1048, Latvia, M.sc.ing., andrejs.stepanovs@cs.rtu.lv. Research areas: database design, object-relational databases

Gunārs Lācis, Latvian State Institute of Fruit-Growing, Graudu 1, Dobele, LV-3701, Latvia, M.sc.biol., gunars.lacis@lvai.lv. Research areas: research coordination and management, fruit crop genetics, molecular genetics.

Jānis Eiduks, Riga Technical University, Meza 1/4, Riga, LV 1048, Latvia, asoc. prof., Dr.sc.ing., janis.eiduks@cs.rtu.lv. Research areas: data base technology, information system design, multicriterial optimization.

Stepanovs A., Lācis G., Eiduks J. Objektu-relāciju datu bāzes projektēšanaInformācijas sistēmu (IS) projektēšana un realizēšana ir visvairāk risinātie uzdevumi informācijas tehnoloģiju uzņēmumos. IS galvenās sastāvdaļas ir datu bāze (DB) un lietojumprogramma. To realizēšanas tehnoloģijas izolēti viena no otras ir strauji attīstījušās. Bet turpmākā IS izstrādes efektivitātes palielināšana nav iedomājama bez abu šo tehnoloģiju sadarbības uzlabošanas. Tiek daudz darīts, lai DB darbību pieskaņotu programmēšanas objektu orientētai tehnoloģijai. Ir izveidotas objektu-relāciju DB. Darbā tiek analizēts kādas ir iespējas objektu-orientēto tehnoloģiju objektu struktūras realizēt objektu-relāciju DB, cik kvalitatīvas ir eksistējošās transformācijas un kādi uzlabojumi un papildinājumi ir jārealizē. Tiek analizēti un papildināti transformāciju elementi, lai nodrošinātu kvalitatīvāku objektu orientētā konceptuālā modeļa pārveidošanu DB loģiskajā modelī.

Степанов A., Лацис Г., Эйдукс Я. Проектирование объектно-реляционных баз данныхПроектирование и разработка информационных систем (ИС) являются самыми решаемыми задачами в информационных технологиях бизнеса. ИС состоят из баз данных и прикладного программного обеспечения. Технологии разработки баз данных и и прикладных программ быстро развиваются, но они изолированы друг от друга. Дальнейшее повышение эффективности разработки невозможно без улучшения сотрудничества обеих технологий. Много делается для того, чтобы приспособить базы данных к объектно-ориентированной технологии, существуют объектно-реляционные базы данных. В работе проведен анализ возможностей реализации объектных структур в объектно -реляционных базах данных, насколько качественны существующие трансформации и какие исправления и улучшения следует внедрить. Проанализированы и дополнены элементы трансформаций,которые служат для более качественного преобразования объектно-ориентированной концептуальной модели в логическую модель баз данных.