Understanding O/R Mapping

Document directory

• What is O/R Mapping?
• Why O/R Mapping?
• How to perform O/R Mapping?
• English document

The purpose of this article is to understand what O/R Mapping is, Why O/R Mapping is required, and how O/R Mapping is performed in the most refined language.

What is O/R Mapping?

In a broad sense, ORM refers to the mutual conversion between the object-oriented object model and the data structure of relational databases.

In a narrow sense, ORM can be considered as a virtual Object-oriented Data access interface based on relational database data storage. Ideally, based on such an object-oriented interface, persistence of an OO object requires no understanding of the Implementation Details of any relational database storage data.

Why O/R Mapping?

In a broad sense, because we need to describe our business by Object-Oriented means, we also need relational databases to store our data.

Some people may mention that we may not need to describe services using object-oriented methods, or may not use relational databases to store data. Yes, but at least there are a considerable number of programs, and cooperation between the two is required. It is reasonable to exist. Because they both need to exist objectively, it is worth discussing.

In a broad sense, existence is reasonable. You don't need to discuss why you need ORM. Many discussions about ORM are actually aimed at the narrow definition mentioned above. However, even so far, the tool that can perfectly implement this narrow definition of ORM does not actually exist (many tools, such as Hibernate, are very similar,, ).

Since it does not exist, before we need to discuss it, I am afraid we should first discuss whether it is possible, that is, theoretically, in mathematics, is the perfect ing between the object-oriented object model and the data structure of the relational database? To answer this question, we need to solve two problems.

O/R impedance imbalance

The first challenge is "O/R Impedance imbalance (O/R Impedance Mismatch)", which refers to the relationship between the OO object model and the data structure of the relational database, differences in design concepts. The design concept of OO is to describe the real world with the most correct semantics. the design concept of relational database is to more effectively store and manage data from the mathematical perspective. Due to their differences in design concepts, although they may be very similar in terms of data structure, their focus is often different.

 

For example:

• From the OO perspective, all attributes with clear semantics and Semantic Attributes of each object should be defined as an attribute. From the perspective of relational databases, it is possible that some attributes will never be used as query conditions, but multiple Semantic Attributes are stored in a data table field in a certain format, it is also possible that the frequency of a group of Semantic Attributes is completely different from that of another group of attributes, even if they belong to one object in semantics, it is also possible to split them into two data tables for storage.
• From the perspective of OO, objects only care about their inherent attributes and do not need to be uniquely identified. However, from the perspective of relational databases, generally, a unique identifier is required for each row of data in a data table, which may be meaningless in semantics, such as a self-increasing identifier.
• Optimization from the OO perspective generally follows the principle of SOLID to organize objects with more correct semantics. Optimization from the perspective of relational databases often aims at query performance, to modify the type and length of a field, modify the index, or even sub-tables and sub-databases.
• ...

It seems almost impossible for me to use an ORM tool with simple configuration to perfectly solve the "O/R impedance imbalance" problem. However, to a certain extent, flexible configuration supports the vast majority of common ing policies, coupled with interfaces that can be extended by users through custom code, it should still be very close to perfection.

Unbalanced cultural Impedance

The second challenge is "Cultural Impedance imbalance", which refers to Cultural differences between relational data experts and object-oriented experts. The most classic debate about this challenge is "Should we drive the development of the program with the relational database data structure or the OO object model ?".

 

The main opinions of OO experts on this debate are:
My business is the core of the program, and the database only serves the needs of persistent data. Therefore, when designing the OO object model, I should not consider how to store it in a relational database;

 

The main opinions of database experts are:
Data is the company's core fortune. Data stability is far stronger than the stability of the OO object model. The design of the database architecture driven by the OO object model does not guarantee performance, the cost of database maintenance is unacceptable.

 

In fact, the true cause of the debate is "Cultural Differences Between Relational Data Experts and object-oriented experts ". The Why Data Models Shouldn't Drive Object Models (And Vice Versa) article by Scott W. Ambler answered this question very well.

 

In the final analysis, since OO and relational databases are both indispensable parts and need to work together, we hope to achieve a perfect ORM, not just a good ORM tool, both OO experts and database experts need to understand each other's technologies and design concepts. An OO expert and An ORM tool can provide direct support for common ing supported by them. However, OO experts who use these ORM tools must understand relational databases, I know how to design an object model that is easier to map to a relational database without affecting the semantics of OO objects, and how to select the ing method SUPPORTED BY THE ORM tool, and how to use custom code to expand the ORM ing modes that ORM cannot easily support. Similarly, for a relational database expert, you also need to understand the semantics of OO and the possible reconstruction, this makes it easier to map the designed database structure to OO objects and to respond to the reconstruction of the OO object model. This is the true harmony and perfection.

Summary

To sum up, both an OO expert and a relational database expert need to understand OO, relational database, and the basic principles of ORM. Without comprehensive knowledge, a perfect ORM tool cannot be used correctly. With this knowledge, you can take full advantage of existing ORM tools to accelerate your work, in addition, the existing ORM tools can be reasonably expanded or custom code can be used to implement ORM ing beyond the capabilities of the ORM tools. This is the ideal ORM practice. Next, let's talk about the basic principles of ORM.

How to perform O/R Mapping? Simple ing

1. Class <-> Table

A Class can be mapped to a Table. A Class instance corresponds to a row of data in the Table. However, each row of data in a Table generally requires a primary key to uniquely identify this row of data, and each instance of a Class does not necessarily need a unique identifier.

2. Property <-> Field

The Property of a Class can be directly mapped to a Field of the Table. However, their data types do not necessarily match directly. If the semantics of the data types they represent can be converted, the Field type should be greater than or equal to the Property data type. If the type semantics they represent cannot be converted, You need to customize the conversion at the application layer.

Inheritance ing

1. Single-Table ing of the entire inheritance system

Use a database table to store data of all classes in the entire inheritance system. The data table requires additional Flag Fields to distinguish which Class should a row of records be mapped to the inheritance system, it is suitable for scenarios where the inheritance system has fewer layers, the total number of records is relatively small, and the attributes of child classes for parent classes are not extended so frequently.

The advantage of ing a single table to the entire inheritance system is that the data of each Class in the read/write inheritance system only needs to be operated on one table, and the performance is good. In addition, the inheritance Class is added, or to expand the Class attribute, you only need to add or remove a table field, which is easy to maintain. The main drawback is that all the classes in the inheritance system share a table, the table contains a large number of NULL field values, which wastes some storage space. At the same time, if the number of records is too large, the table will become larger and affect the read/write performance of the table.

 

2. Map a Class to a specific table

A Class ing a specific table means that each Class corresponds to a data table, and each data table redundant contains all attribute fields of its parent Class, and the Child Class shares the same primary key value with its parent Class. A Class A specific table scheme is suitable for scenarios that require high query performance. The hierarchy of the inheritance system is not complex, and the base Class contains fewer attributes, while the subclass extends more attributes, and can withstand certain database redundancy.

The main advantage of ing a Class to a specific table scheme is that the query performance is good. Only one table is required for read operations, and the corresponding structure of the object data is clear. It is easier to migrate and maintain database tables; the main drawback is that the data redundancy is large, because each time a subclass data is inserted, a copy of the data containing the parent field of the subclass must be inserted to all parent level tables.

 

3. Map a Class to an extended table

A Class ing an extended table means that each Class in the inheritance system corresponds to a data table. However, each subclass does not redundant and contains all attributes of the parent Class, it only contains extended attributes and Shared primary key values. A Class ing an extended table scheme is suitable for situations where the inheritance system is complex and the structure is variable, and data redundancy is minimized.

The advantage of ing a Class to an extended table scheme is that the structure is flexible. It is convenient to add a subclass or insert an inheritance Class in the middle, with the least redundant data. However, the disadvantage is that, both read and write operations involve sub-classes and all parent classes. During read operations, you must link to query the data tables of all parent classes. when inserting or updating data, you also need to write all parent tables.

 

4. General table structure ing all classes

This solution not only supports storing an inheritance system with a table, but also supports storing any number of different classes with a table. It is driven by metadata. Each row in this table contains an ID field of the type, a field that represents the attribute name of the Class, and a field that represents the attribute value of the Class. During runtime, all the Property values describing a Class instance are retrieved with a unique identifier, and then mapped based on the Property name.

For more information about the advantages and disadvantages of the instance analysis and detailed comparison of various inherited mappings, see Scott W. Ambler's O/R Mapping In Detail.

Association ing

1. One-to-one association and one-to-Multiple Association (including one-to-one and one-to-many Association)

The so-called one-to-one association can be divided into three situations, namely, 0 .. 1-1, 1-1, 1-0 .. 1. One-to-Multiple Association is divided into *-1 and 1 -*.

Among the following three solutions, 1st are the most commonly used ing solutions. The following solutions are available for reference in some special situations:

1) The most common solution is to add a foreign key to the table corresponding to the referenced object to the table corresponding to the class referenced by other objects. However, in the Entity class code corresponding to the table, for the "multiple" end in one to multiple cases, it must be defined as a set type;
2) In Hibernate, it is called "Component ing". For example, if the Person class contains an attribute of the Address Member type, and the Address is composed of City, Street, zipCode consists of three member attributes. if the Address is not associated with the Person object and is not used by other objects, we can consider using only one data table "Person" to persist the two tables "Person" and "Address, the Person data table contains a set of all the attributes except the Address attribute and the Address attribute in the Person class. Of course, the ing relationship must be specified in the metadata;
3) Another persistence scheme for the Person and Address classes in the above scheme is to serialize all the attributes of the Address type and store them in the Address field of the Person table, in this way, only one table can be used to persist two classes. Of course, in this solution, the data size of serialized object members should be as small as possible;
4) Another solution is to share one-to-one associations with the same primary key value. The records of the two tables can be associated with the same primary key.

 

2. many-to-many Association (including many-to-many self-Association)

The so-called many-to-many Association is naturally the case. Generally, an associated table containing the primary keys of both parties is required. When retrieving data, you need to link the associated table and data table.

English document

• Http://en.wikipedia.org/wiki/Object-relational_mapping
• Http://www.agiledata.org/essays/impedanceMismatch.html
• Http://www.agiledata.org/essays/culturalImpedanceMismatch.html
• Http://www.agiledata.org/essays/drivingForces.html
• Http://www.agiledata.org/essays/mappingObjects.html