In object-oriented databases (OBD), users can set operations with a specific database consisting of objects, which can be of various types and for which operations are set. They can efficiently process binary information, such as multimedia objects. Another additional advantage of the OOBD is that it can be programmed with small procedural differences without affecting the entire system.
Prerequisites for creating a standard
The history of object-oriented OBDB databases begins at the end of the last century. They were created to meet the needs of new applications. At the same time, it was assumed that object-oriented databases would revolutionize software systems during the 90s. It is now clear that this is not so. However, the revival of this concept, thanks to the free software communities and the identification of applications suitable for it, motivates the revision of the characteristics of the ODBD, which is an alternative to the ubiquitous relational databases.
Orientation to objects provides flexibility for processing some or all of the requirements and is not limited to data types and query languages of traditional databases. A key feature of the OOBD is the opportunity that they provide to the developer, allowing him to specify both the structure of complex objects and the operation of the application. Another reason for the creation of OOBDs is the growing use of languages for software development.
Databases have become the fundamental foundations of many information systems, but traditional databases are difficult to use when the applications that access them are written in C ++, Smalltalk, or Java. For example, 1C object-oriented databases were designed in such a way that they can be directly integrated with applications using object-oriented languages, adopting their concepts: Visual Studio.Net, C ++, C #, Microsoft SQL Server and others.
The main advantage of the OOBD is the complete elimination of the need for RMs1 (impedance), followed by improved performance.
Disadvantages:
- Very primitive consulting mechanisms, without an independent standard of the adopted platform.
- The impossibility of stored procedures, since objects can only be accessed in the client.
- Immaturity in the market.
- There is no physical grouping of objects.
Object paradigm
Object-oriented databases are a programmable database that stores complex data and their relationships directly, without assigning rows and columns, which makes them more suitable for applications that work with large packages. Objects have many-to-many relationships and are accessible through the use of pointers that are associated with them to establish relationships. Like any programmable, OOBD provides an environment for developing applications and a permanent repository, ready for operation. It stores and manipulates information that can be digitized as objects, provides quick access and provides great processing capabilities.
Key concepts used in an object-oriented database:
- identity of objects;
- type of constructor;
- language compatibility;
- hierarchies of types and inheritance;
- processing complex objects;
- polymorphism and operator overload;
- creation of versions.
In order to fully consider all aspects of what concepts characterize an object-oriented database, it is important to note all the important paradigms of the object:
- Encapsulation is a property that allows you to hide information for other objects, thereby preventing incorrect access or conflicts.
- Inheritance is a property by which objects inherit behavior in a class hierarchy.
- Polymorphism is a property of an operation by which it can be applied to various types of objects.
- The interface or signature of an operation includes the name and data types of its arguments or parameters.
- The implementation or operation method is specified separately and can be changed without affecting the interface. User applications can work with data by invoking specified operations through their names and arguments, regardless of how they were implemented.
Classes and Functionality
Considering the concept of classes in the OOBD, it is necessary to distinguish between the terms "class" and "type". The type is used to describe a set of objects with similar behavior. In this sense, it depends on what operations can be called on the object. A class is a collection of objects that have the same internal structure, so it defines the implementation, and the type describes how to use it.
The term "instantiation" is aimed at the fact that class instantiation can be used to form a set of objects that have the same structure and behavior as established by the class.
A feature that is very important for the evolution of objects is that it can change its class, including attributes and operations, while maintaining its identity. This will require a mechanism to handle the emerging semantic integrity.
Inheriting an object-oriented organization database allows you to define a class as a subclass of an existing superclass. It will inherit all attributes and methods from the latter and may optionally define its own. This concept is an important mechanism for supporting reuse. The same parts of the structure of two different classes can be defined only once in a common superclass, thus less code will be written. There are some systems that allow a class to be a subclass of more than one superclass. This function is called multiple inheritance, unlike single inheritance.
Object Oriented Database Example
It is often useful to use the same name for different but similar methods of the media superclass from the picture and video classes. Many files can be viewed by different viewers. They often have a need to view all photos and videos using the “view” method, and the corresponding program must be launched. When you call the function and transfer the link to the video, the media player starts. To realize this feature, first of all, it is necessary to define the operation “presentation” in the general superclass media from the classes picture and video. Each of the subclasses overrides the lookup operation for its specific needs. This leads to different methods that have the same operation name. In this case, using this function has an important advantage.
ODBD structure
The object-oriented paradigm is based on the encapsulation of data and code related to each object in one module. Conceptually, all interactions between him and the rest of the system are carried out using messages. Therefore, the interface between them is determined by the allowed set.
In general, each object is associated with a set:
- Variables that contain object data and correspond to the attributes of the ER model.
- The messages to which he replies. Each may or may not have parameters, one or several.
- Methods, each of which is a code that implements messages and returns a value in response to it.
A message in an OO environment does not imply the use of physical SMS in computer networks. On the contrary, this applies to the exchange of requests between objects, regardless of the correct details of their implementation. Sometimes an expression calls a method to initiate the fact of sending a message to an object, and uses the execution of the corresponding method.
Object Identity
The system of object-oriented databases provides a unique identification for each independent object stored in the database. It is usually implemented using the unique identifier of the object generated by the system, or OID. The OID value is invisible to an external user, but the system uses it internally to manage links between objects.
The main property of OID is to be immutable. The OID value for a particular object should never change. This preserves the identity of the represented real world. It is also preferable that each OID is used only once, even if it is deleted from the database, its OID should not be assigned to another. It is also often considered inappropriate to base it on the physical address of the object in the repository, since reorganizing them into a database can change the OID. However, some systems use a physical address as an OID to increase the efficiency of receiving objects. An object-oriented structure automatically imposes relational constraints, usually more applicable: domain, key, object integrity, and referential integrity.
Three main constructors
In the OOBD, values or states of complex objects can be created from others using certain types of constructors. One way to represent them is to consider each one as a triplet (i, c, v), where i is the unique identifier of the object (OID), c is the constructor, that is, an indicator of how the value of the object is created, and v is value or state of the object. There may be several designers depending on the data model and the TOE system.
The three main designers of object-oriented databases are:
Others of more general use are lists and diagrams. There is also domain D, which contains all the basic atomic values available directly in the system. Usually they include integers and real numbers, character strings, dates, and any other data types that the system processes directly. Both object structure and operations are included in class definitions.
Programming language compatibility
The basic concepts of object-oriented databases are used as design tools and are codified for working with databases.
There are several possible languages in which these concepts can be integrated:
- Extending a language for processing data such as SQL by adding complex types and OOP. Systems provide object-oriented extensions for relational systems, called object-oriented relational systems.
- They use the existing object-oriented programming language and expand it to work with databases. These are called persistent programming languages and allow developers to work directly with data without having to go through a language for processing data such as SQL. They are called persistent because the data continues to exist after the completion of the program that created them.
When deciding which option to use, you need to keep in mind that persistent languages are usually powerful, and it is relatively easy to make programming errors that damage the database. The complexity of languages makes automatic high-level optimization difficult, such as reducing disk I / O. In many applications, the possibility of declarative queries is important, but persistent languages currently do not allow such queries without problems.
Inheritance Type Hierarchy
Object-oriented database schemas usually require a large number of classes. However, several classes are similar to each other. To allow a direct representation of the similarities between them, you will need to place them in the hierarchy of specializations. This concept is similar to the ER model. Class specializations are called subclasses that define additional attributes and methods for an existing class. Objects created using subclasses inherit everything from the parent. Some of these inherited characteristics may have been borrowed from higher hierarchies themselves.
Objects are considered complex because they require a large storage area and are not part of the standard data types that object-oriented database management (SOOBD) typically offers. Since the size of the objects is significant, COOBD can get a part of the object and provide it to the application program before receiving the entire object. It can also use buffer and caching methods to get parts of an object in advance, before the application gets access to them.
The OOBD allows users to create new types that include both structure and operations, in which case it is an extensible type system. You can create libraries of new types by defining their structure and operations. Many of them can store and receive an extensive structured object in the form of strings and characters or bits that are transmitted “as is” to the application for interpretation.
The method can directly access the attributes of the target object by name, including any that are inherited from the parent classes, but must have access to the attributes of other objects with secondary signals. The concept allows you to associate the same name or symbol of an operator with two or more different implementations of it, depending on the type of objects to which it is applied.
Application creation
Many database applications using OO systems require multiple versions of the same object. Typically, maintenance actions are applied to the software system as their requirements change, and includes the change of some development and implementation modules. If the system is already working, and if it is necessary to change one or several modules, the developer must create a new version of each of them, making changes.
It should be noted that there can be more than two versions of an object, in case two are required in addition to the original module. Native versions of the same software module can be updated at the same time. This is called the parallel design of object-oriented databases. However, there always comes a moment when they need to be combined, so that the hybrid OBD includes the changes made, they will be required to be compatible.
Object Oriented Conditions
All computer systems must have the properties of their architecture in order to be considered. For example, a system must have tables in order to be considered relational. OOBD is no exception and contains some basic properties of object architecture. However, in the real world, many of these properties are discussed, and some, such as multiple inheritance, are seen as improvements to the object-oriented database model, and not as part of the basic framework. For example, in the object-oriented Smalltalk language, multiple inheritance is not supported, even if it is considered part of the object architecture.
Methods for a class define a set of operations that can be performed on an object. For example, when it is applied to an object, it either returns a value or performs some operation to update the values. Sometimes methods do not return it. If a method were developed to update the number of passengers for a vehicle, no value would be returned, but the data item in the target would change it.
Objects are a fundamental concept in the ODOB. In fact, objects are an abstract representation of the things of the real world that are stored in it. An object is an instance of a class in the sense that it is excluded from its definition.
You can think of an object as a standalone package, which consists of three parts:
- Own personal information, data values.
- Private procedures that will manipulate values through class definition.
- An open interface so that this object can communicate with others.
Examples of OBOB
The use of OBDB simplifies conceptualization, since it is more natural to present information that needs to be stored. To model the structure or logic of the database, the use of class diagrams allows you to enter classes with their structural relationships and inheritance. , , , , , , .
- .
, . — , , . . , , , , .