Lecture
ORM (English o bject- r elational m apping , Russian object-relational mapping ) is a programming technology that links databases with concepts of object-oriented programming languages, creating a “virtual object database”. There are both proprietary and free implementations of this technology.
In object-oriented programming, objects in a program represent objects from the real world. As an example, consider an address book that contains a list of people with zero or more phones and zero or more addresses. In terms of object-oriented programming, they will be represented by objects of the “Man” class, which will contain the following list of fields: name, list (or array) of phones, and list of addresses.
The essence of the task is to convert such objects into a form in which they can be stored in files or databases, and which can be easily extracted later, while preserving the properties of objects and the relations between them. These objects are called "stored" ( persistent ). Historically, there are several approaches to solving this problem.
The solution to the problem of data storage exists - it is relational database management systems. Using a relational database to store object-oriented data leads to a semantic gap, forcing programmers to write software that must be able to both process data in an object-oriented form, and be able to store this data in a relational form. This constant need for conversion between two different forms of data not only greatly reduces performance, but also creates difficulties for programmers, since both forms of data impose limitations on each other.
Relational databases use a set of tables that represent simple data. Additional or related information is stored in other tables. Often, several tables are used to store a single object in a relational database; this, in turn, requires the use of the JOIN operation to get all the information related to the object to process it. For example, in the considered variant with a notebook, at least two tables will most likely be used to store data: people and addresses, and perhaps even a table with phone numbers.
Since relational database management systems usually do not implement the relational representation of the physical level of relationships, it may be too expensive to perform several sequential queries (related to a single "object-oriented" data structure). In particular, one request of the form “to find such a user and all his phones and all his addresses and return them in such a format” is likely to be executed faster than a series of requests like “Find a user. Find his addresses. Find his phones. This is due to the work of the optimizer and the cost of parsing the query.
Some ORM implementations automatically synchronize the memory-loaded objects with the database. In order to make this possible, after creating an object-in-SQL-transforming SQL query (a class that implements communication with DB), the data is copied into the object fields, as in all other ORM implementations. After that, the object must monitor changes in these values and write them to the database.
Relational database management systems show good performance on global queries that affect a large area of the database, but object-oriented access is more efficient when working with small amounts of data, as this reduces the semantic gap between the object and relational forms of data.
With the simultaneous existence of these two different worlds, the complexity of the object code for working with relational databases increases, and it becomes more error prone. Database-based software developers were looking for an easier way to achieve consistency in their objects.
Many packages have been developed that eliminate the need to convert objects for storage in relational databases.
Some packages solve this problem by providing libraries of classes that can perform such conversions automatically. Having a list of tables in the database and objects in the program, they automatically convert queries from one type to another. As a result of a request for the “person” object (from the address book example), the necessary SQL query will be generated and executed, and the results will be “magically” converted into “phone number” objects within the program.
From the point of view of the programmer, the system should look like a permanent storage of objects. He can simply create objects and work with them as usual, and they will automatically be stored in a relational database.
In practice, everything is not so simple and obvious. All ORM systems usually manifest themselves in one form or another, reducing in some way the ability to ignore the database. Moreover, the transaction layer can be slow and inefficient (especially in terms of generated SQL). All this may lead to the fact that programs will run slower and use more memory than programs written "by hand".
But ORM saves the programmer from writing a large amount of code, often monotonous and error-prone, thereby greatly increasing the speed of development. In addition, most modern ORM implementations allow the programmer, if necessary, to strictly specify the SQL query code that will be used for certain actions (saving to the database, loading, searching, etc.) with a permanent object.
Comments
To leave a comment
Databases, knowledge and data warehousing. Big data, DBMS and SQL and noSQL
Terms: Databases, knowledge and data warehousing. Big data, DBMS and SQL and noSQL