ADVANTAGES OF USING OBJECT-ORIENTED DATA DB MANAGEMENT SYSTEMS IN THE DEVELOPMENT OF COMPLEX INFORMATION SYSTEMS

ADVANTAGES OF USING OBJECT-ORIENTED DATA DB MANAGEMENT SYSTEMS IN THE DEVELOPMENT OF COMPLEX INFORMATION SYSTEMS

Nikita Korneev

student, Federal State Autonomous Educational Institution of Higher Education "SIBERIAN FEDERAL UNIVERSITY",

Russia, Krasnoyarsk

ABSTRACT

When developing big and complex software projects, there is often a need to synchronize changes made in the code with changes made in the DBMS. Discrepancies in the versions of software and stored objects leads to an increase in the number of errors, negatively affects the quality of the program code and its performance. During the development of programming languages, software storage platforms were also improved. In particular, the creation of an object-oriented approach in programming entailed the creation of object-oriented DBMSs that have advanced functions to support the storage of object classes. The article considers the issues of choice and expediency of using object-oriented and relational DBMS when creating information systems.

Modern complex software projects differ in that the number of entities reflected in programming by object classes is very large, and the composition of attributes is very diverse. Manual synchronization and version control of changes in the DBMS becomes a separate complex task that consumes a large percentage of the resources of the main project. At the same time, there are tasks that do not require such activities throughout the life cycle of the project. At the design stages, it is necessary to separate these classes of tasks from each other, to identify the framework and limitations for their implementation, since the choice of a particular software platform for both project development and data storage implementation depends on it.

As a practical result of the research, the article suggests methods for selecting the appropriate type of DBMS, taking into account many factors, in order to optimize the timing and cost of project development at the early stages of design. Attention is also paid to the costs of choosing a relational DBMS platform as a data storage tool, modern trends in the development of the DBMS market towards object-oriented extensions that allow flexible use of relational and object-oriented approaches in one software project are considered.

Keywords: Object-oriented DBMS, relational DBMS, ODMG, Database, Bigdata.

1. Introduction 

Information technologies are taking an increasingly strong place in our lives. Despite the fact that computers were originally created to perform calculations, it soon became clear that they could be used to collect, store and process various types of information. Any information can be presented in binary form, only means are needed to convert information into digital form and vice versa. Therefore, the development of information technologies is directly related to such a direction of human activity as programming, which in turn is actively developing at the moment. New languages are being created to describe algorithms and data storage structures designed to speed up and reduce the cost of the development process and the implementation of cross-platform applications. One of the directions of transformations is the transition to an object-based way of describing, processing and storing data, which is most understandable to an ordinary user.

At the moment, many different object and object-oriented programming languages have been developed and used for writing programs. The most famous of them are: C++, Java, C#, PHP, Delphi, etc. In the syntax of each of these languages there are basic concepts - an object and a class. An object is an abstract entity consisting of many attributes of an object and many methods that process these attributes. A class is a collective description of objects of the same type, each object, respectively, is an instance of the class.

When creating a program in an object-oriented language, relatively speaking, some part of the virtual world is described, consisting of objects and actions on them. Such a description, close to reality, in the form of a system of interacting objects looks much more natural than in the form of complex relationships of individual modules, functions and procedures.

Historically, database management systems (DBMS) began their development with the model of the indexed sequential access method developed by IBM (ISAM). As data storage mechanisms developed in 1969-1971, the theory of the data description language (DDL) and the data manipulation language (DML), as well as the network and relational DBMS models were formulated. At the same time, the basic properties that determine the key characteristics of modern DBMS were developed: the ability to log operations and recover from failures, control and ensure data integrity, parallel work of several users.

In many cases, databases are used to collect, store and process information about real-world objects, contain their names, properties and other attributes. In such cases, the description of DBMS objects is in many ways similar to the description of classes in object-oriented programming and this determined the further steps of the development of relational DBMS in the direction of object-oriented DBMS in the mid-80s.

The development of object-oriented DBMS began mostly due to the need to meet new requirements for applications that were becoming more complex and diverse. In order to implement this variety of object classes and the processing of their attributes, the method of storing program objects directly in a single DBMS turned out to be the most effective - this optimizes the amount of stored data and reduces the number of data transformations during transmission between the DBMS and the application.

Computer-aided design (CAD) and automated production systems, multimedia content management and processing systems, knowledge management and extraction systems, Bigdata systems, complex analytical systems and artificial intelligence systems are all tasks that require complex algorithmic processing of large amounts of data. To solve these problems, it was necessary to create a new generation of applications working with object-oriented DBMS as the most efficient storage of multiple instances of objects of various classes. It is this type of DBMS that is recommended for creating high-performance data processing systems of complex and diverse structure.

The relevance of the chosen topic of work consists in determining how justified the use of object-oriented DBMS for the tasks of developing information systems, depending on the volume and structure of stored data in comparison with conventional relational DBMS. The solution of this issue should have sufficient grounds and be carried out every time at the early stages of design, since further steps of the project depend on it, as well as issues of further implementation and author support.

2. Description of the object-oriented approach

The object-oriented approach in database management systems makes it possible to store instances of classes directly in the form in which these instances are processed in applications - the object data model. Such a management system allows you to significantly expand the possibilities for storing and processing abstract OOP objects, which provides support for working with any types and structures of data.

Object-oriented DBMS owe their appearance to the massive transition from conventional modular programming to object-oriented programming languages (OOP) and a significant increase in the volume of processed data that did not fit in the memory of a computer or application server.

Object-oriented programming focuses on the processing of objects, allowing you to abstract from their properties, individual modules and libraries for their processing. This approach greatly simplifies the work of developers, separates the logic of applications and the logic of individual classes of objects, it provides the necessary isolation of application components for gradual and predictable changes. This is necessary for conducting for the absolute majority of medium and large projects, when a large number of developers have been involved in the development for a long time, as well as with further author's support.

An object-oriented DBMS uses and extends the concepts of object-oriented programming. Object instances should be able to be stored in the DBMS in binary form, should be able to control versions and convert binary DBMS objects from the old version to the new one as a result of application refactoring. References are used to address objects in the OOP, however, to ensure the addressing of objects stored in the DBMS, an extended version of addressing and identifying object instances is used – if, when accessing an object, it turns out that it is not in RAM, it will automatically be loaded from the DBMS and execution will continue.

Also, the creation of an object-oriented DBMS solves the important task of long-term storage of the intermediate state for each of a large set of class instances at a time when their active processing does not occur in the work of the application software, thereby the entire set of object instances can be stored in the DBMS and server hardware resources can be given over to processing other tasks and objects. This makes it possible to calculate the required power of the server equipment more efficiently, since it is not necessary to store all instances of objects in RAM for processing at the same time.

3. Object-oriented DBMS standard

Initially, most object-oriented DBMS were libraries that included data management application procedures and DBMS management procedures. As the volume of processed data grew, it became necessary to create dedicated object-oriented DBMS servers by analogy with the development of relational databases. In order to unify work with various object-oriented DBMS servers, there was a need to create a single development standard.

To do this, large software development companies joined forces and organized the consortium Object Database Management Group (ODMG). This consortium includes such companies as:

• Sun Microsystems;
• Computer Associates;
• Objectivity Inc.;
• POET Software;
• Versant Corporation.

In the course of its activities, the consortium of ODMG companies has created an industrial standard for the general model and architecture of object-oriented DBMS.

The main components of the architecture:

• Object Data Model (OM);
• Object Definition Language (attributes and methods) (ODL);
• Object Manipulation Language (OML), including standards for linking to programming language elements;
• Object Query Language (OQL).

The ODMG 1.0 standard and architecture was created in 1993 [1, p. 37].

Figure 1. ODMG Data Model

The ODMG standard supports an Object Model that adheres to the following basic constructs and principles:

1. The main semantic units are objects and literals. Objects have unique identifiers, unlike literals.
2. Each object and literal must have its class and type defined, respectively.
3. An object has a set of attributes and relationships that defines its range of states;
4. An object has a set of methods that determines its behavior;
5. The methods of the object when called have a set of input parameters and a set of output parameters, each with an indication of the type. Each method can also return a result of a certain type;
6. An object-oriented DBMS stores objects, which allows them to be shared by several users and applications.

The application developer uses the ODMG object model constructs to build their own application object model. The application object model is described by a set of predefined classes, such as: Document, Author, Publisher, and Chapter, as well as methods and properties of each of these classes. The application object model is a logical scheme of an object-oriented DBMS.

The ODMG model includes richer semantics than the relational DBMS model, due to the explicit declaration of relations and operations. As the standard developed, two more updated versions of ODMG 2.0 (September 1997) and ODMG 3.0 (2000) were released, and a specification for the ODMG 4.0 standard is currently being developed. Here are the main terms and definitions introduced by the current standard [2].

Within the framework of the standard, the concept of "Lifetime" of each type of object is defined. The lifetime of an object determines how the memory and storage allocated to the object are managed. The lifetime of the object is specified during the creation of the object. Two "Lifetime" options are supported in the object model:

• temporary;

• permanent.

Similar to OOP languages such as C++ or Java, the ODMG standard supports atomic objects (atomic), ordered collections of objects (collection), unordered collections of objects (set- sets), bag-type objects - multisets - unordered sets with repeated elements, lists - sorted collections (list), arrays - dynamically changeable sorted collections with element addressing (array), dictionaries - unsorted sequences of key-value field pairs (dictionary).

For example, syntactically the dictionary definition will look like this:

Inserting, deleting and retrieving entries from the dictionary is performed by bind, unbind and lookup methods, respectively.

All structured objects support the Object ODL interface. The DBMS object model defines the following structured objects:

• Date;
• Interval;
• Time;
• Timestamp.

As mentioned above, Literals are supported at the standard level. The following operations are defined for literals: copying, comparison, and equivalence checking. The object-oriented DBMS model supports the following types of literals:

• atomic literal - variables of built-in types;
• collection literal - supports any of the types of collections defined for objects;
• structured literal - consisting of embedded or user-defined structures of several static fields.

To model object-oriented DBMS objects, class definitions described in the ODL language are used. A class defines a set of properties through which users can access and sometimes directly manipulate the state of instances of the class. Classes have the ability to specify two types of properties: attributes and relationships. You can specify a specific type for attributes. Relationships are defined between two types, each of which must have instances that can be referenced by object identifiers. Literals cannot participate in relationships because they do not have object identifiers. Semantically, the recording of classes and relationships looks like this:

All constructions described in the ODL language are automatically converted to the corresponding object-oriented DBMS objects, in case of version mismatch, the stored objects are converted. Similarly, it is possible to create a detailed description of any applied tasks within the model with a high level of abstraction, convenient tools for expanding and modifying existing models. Mechanisms of inheritance of properties and methods, redefinition of methods of superclasses are implemented. At the level of the internal object-oriented DBMS model, data integrity control mechanisms, various types of locks and other mandatory attributes of a modern DBMS are implemented.

The ODMG data model also includes an object query language called OQL, which supports the following general postulates:

1. OQL fully supports the syntax of the SQL-92 standard.
2. OQL extensions only support the basic concepts of OOP.
3. OQL provides a set of tools for working with collections, structures, lists and arrays.
4. OQL can be used for composing complex queries, provided that the typing of operands is controlled.
5. OQL is computationally incomplete – it is a fairly simple and understandable query language.
6. OQL does not provide explicit DBMS update statements. For these purposes, there are the usual methods described in objects designed to process and preserve certain properties. Thus, it does not violate the semantics of the object model.

The advantages of the OQL approach are that within the framework of the usual syntax of the programming language in which the application logic functions, access to the DBMS is carried out without the constructs of converting data structures and formats into DBMS-level stored structures, and when reading in the opposite direction. All these functions are handled transparently for the programmer and do not require additional code. This is one of the key advantages of the object-oriented DBMS model.

4. Justifications for the right choice

With the development of object-oriented DBMS, conventional relational DBMS have been very widely developed all over the world, and although the object-oriented approach has its obvious advantages, business technicians often have concerns that the costs of creating application software on a new platform will pay off at the stages of implementation or during the period of operation of the system.

Often, the need for improvements and the use of the advantages and capabilities of the object approach arises at a time when the application software has already been developed and operates using a relational database management system. In this case, it can be extremely difficult to convince the project management and the customer of the need to switch to object-oriented DBMS.

A compromise for solving this issue may be an approach that will allow a gradual transition to the object-oriented DBMS platform. To do this, it is necessary to select the most suitable modules for refactoring from the total volume of existing functionality. You can start developing the selected modules in parallel with the maintenance of the main functionality using minimal budgets. This will save the budget at the initial stages and get the first results of using the new platform in order to assess the advantages and prospects of a complete refactoring of all customer systems.

In the software market, there are alternative options to build an object-oriented DBMS using object extensions to existing relational DBMS implementations, or object-relational adapters. The use of such developments for small systems is objectively more economically justified than the deployment of a separate object-oriented DBMS. For large applied developments, this option is not suitable due to the lack of sufficient scalability [4].

Conventional object-relational adapters allow you to automatically store and read stored program objects in a relational DBMS. This mechanism also has significant limitations on the possibilities of application and does not provide optimization in terms of working with a DBMS, unlike the object-oriented DBMS model [5, p.681].

In addition to those listed above, there are systems with an extended relational model – extended RDBMS. Oracle, Informix Software and IBM companies, developing in this direction, have created an object-relational DBMS, combining relational DBMS concepts and object-oriented DBMS models in their products. These extended RDBMS can be successfully used for the purposes of switching from a relational model to an object-oriented DBMS model, as well as for the development of application software using partial data storage in a relational DBMS. The key to the success of such projects is the correct design taking into account both DBMS concepts.

However, it is not always necessary to focus on object-oriented DBMS. If all the system data can be divided at the design stage into a set of simple relational tables with fixed-length fields (first name, patronymic, surname, address, phone, etc.), with a flat table structure, then it makes sense to choose a conventional relational DBMS. Another factor that indicates the need to use relational databases is the presence in the application software of the need to search for non-key fields. In object-oriented DBMS, it is impossible to create indexes on the internal contents of objects – this would be extremely inefficient.

At the same time, if the data of DBMS objects have a complex or hierarchical structure, or it is required to dynamically change the size of fields, then their representation in the relational DBMS model will lead to inefficient use of memory and performance, and will also have significant limitations on use. However, the object-oriented DBMS concept allows you to implement the storage of the described complex objects without much difficulty, using the ODL syntax, and at the internal level, the object-oriented DBMS model itself will decide how best to store and process data and the relationships between them. Thus, the use of object-oriented DBMS is more suitable for storing large amounts of data and complex relationships between them.

For most modern programmers, a very important factor that speeds up and simplifies development is the support of the OOP paradigm, which was at the origin of the creation of the object-oriented DBMS object model. The model supports basic OOP postulates such as polymorphism, inheritance, and encapsulation:

Figure 2. Combining the principles of OOP and DBMS

The programmer develops in his familiar IDE environment and gets full access to the DBMS at the level of the object-oriented DBMS object model. In a relational DBMS, data translation is required when issuing from the DBMS to the application and vice versa, so that the developer saves data from the application level to the DBMS level, data translation is also required, which leads to unproductive spending of server complex resources [6].

Practical development of application software using a DBMS usually requires the software platform to support three important operational characteristics:

• Integrity;
• Scalability;
• Fault tolerance.

Due to the similarity of the internal architecture of relational and object-oriented DBMS, identical mechanisms are used to ensure these characteristics. The main difficulty lies in the volume of stored data and integrity control at the level of links between objects. To ensure referential integrity, object-oriented DBMS uses the storage of mutual references to objects in order to avoid "hanging links".

In the architecture of modern object-oriented DBMS, there is a toolkit that allows you to build cluster systems to ensure the required performance and power of the DBMS. The scale limitations are related more to the power of the server hardware and the correctness of the configuration, rather than to software limitations. The same can be said about the fault tolerance of configured cluster and distributed systems.

The presence of many probable points of failure of modern software and hardware complexes is compensated by the reliability and redundancy of equipment, settings for automatic transition between nodes of failover clusters and mirror clusters. The correct configuration of all available mechanisms usually ensures long-term uninterrupted operation of the DBMS and protects data from complete or partial loss [7, p. 478].

5. Conclusion

The paper considers the main points of the object-oriented DBMS technology, focuses on their strengths and weaknesses, which are important for the entire development process and the final result when implementing complex software projects.

Other things being equal, object-oriented DBMS provide more development tools, does not require bidirectional translation of queries as relational DBMS, when developing in OOP environments, it is object-oriented DBMS that provides the highest development speed and most likely this will have a positive impact on the timing and cost of project implementation. The factors listed above indicate the expediency of using object-oriented DBMS.

At the same time, as with any other technology, with object-oriented DBMS, there are limits and restrictions on application on certain types of tasks. For object-oriented DBMS, such a limitation may be the simplicity of the original task. For example, there is no need to implement on the object-oriented DBMS platform if it is possible to perform the task using several simple relational DBMS tables.

In each specific case, architects and technical specialists of the project should deal with the feasibility of using a particular type of DBMS and make an informed decision based on the implementation requirements and technical specifications, plans for further development of the project, consultations with the customer and, of course, their own experience.

References:

1. Booch G., etc "Object-oriented analysis and design with applications", 3^rd ed., Addison-Wesley, 2007., - 717 p.
2. The Object Data Standard: ODMG 3.0. R.G.G. Cattel, D.K. Barry, eds., Morgan Kauffmann, 2000.
3. Andreev, A.M. Berezkin D.V. Kantonistov Yu.A. "Environment and storage: [Text] OOBD" PC World No. 7 2009.
4. Malcolm Atkinson, Francois Bancilhon, David DeWitt, Klaus Dittrich, David Maier, Stanley Zdonik. «The Object-Oriented Database System Manifesto. Proc. 1st International Conference on Deductive and Object-Oriented Databases», [Text] - Kyoto, Japan (1989), New York, N.Y.: Elsevier Science (1990).
5. Date, C. J. An Introduction to Database Systems Boston [etc.] [Text] - Pearson: Addison Wesley, cop. 2004 0-321-19784-4.
6. Kuznetsov S.D. Introduction to DBMS (Review). Part 9. J. DBMS No. 5-6, 1996.
7. Homonenko A.D., Tsygankov V.M., Maltsev M.G. - Databases. Textbook for Higher educational institutions (6th ed.) – 2009.
8. Mutushev, D.M. Filippov V.I. "Object-oriented databases" Programming. [Text] - M., 2010. No. 6.
9. Bobrov V.N. "Object-oriented databases, multimedia data types and their processing" [Text] Read.Me No. 4, 2007.