Object-relational mapping (ORM) is a software development technique that allows an application program written in an object-oriented programming language to store its objects in a relational database. The database then appears to the program as an object-oriented database, which facilitates programming. This technique is usually implemented with class libraries, such as Entity Framework for .NET programming languages, Hibernate for the Java programming language, Doctrine for PHP, SQL Alchemy for Python, Active Record for Ruby, or Diesel for Rust. For Java, there is also a standardized interface, the Jakarta Persistence API.
Object-oriented programming languages encapsulate data and behaviour in objects, whereas relational databases place data in tables. The two paradigms are fundamentally different. In this way, objects encapsulate their state and behaviour behind an interface and have a unique identity. Relational databases, on the other hand, are based on the mathematical concept of relational algebra. This conceptual contradiction became known in the 1990s as an object-relational impedance mismatch.
To resolve or at least mitigate the contradiction, various solutions have been proposed, such as object-oriented databases or the extension of programming languages with relational concepts (for example, embedded SQL). The direct object-relational mapping of objects to relations has the advantage that on the one hand, the programming language itself does not have to be extended and on the other hand, relational databases are available as established technology in all environments as mature software. The disadvantage of this approach, which is accommodating to the object-oriented programming language paradigm, is that the strengths and capabilities of relational databases are sometimes not used, which can translate into non-optimal performance.
---
In the simplest case, classes are mapped to tables, each object corresponds to a table row, and a table column is reserved for each attribute. The identity of an object corresponds to the primary key of the table. If an object has a reference to another object, it can be represented with a foreign key-primary key relationship in the database. The term shadow information refers to additional data that an object needs to be stored persistently. This includes primary keys – especially if they are surrogate keys of no technical significance – as well as auxiliary data for access control, such as timestamps.
Mapping of Inheritance Hierarchies
There are essentially three different ways to map inheritance hierarchies to database tables. Some frameworks offer further variations and mixtures of these three basic methods.
Table per inheritance hierarchy: In this procedure, all attributes of the base class and all classes derived from it are stored in a common table. In addition, a so-called “discriminator” is stored in another column, which determines which class the object stored in this row belongs to. In most cases, however, attributes of derived classes may not be provided with a NOT NULL constraint in this approach. In addition, restrictions on the number of allowed columns per table can thwart this approach for large classes or class hierarchies.
Table per subclass: In this procedure, a table is created for the base class and another table is created for each subclass derived from it. A discriminator is not needed because the class of an object is defined by a 1-to-1 relationship between the entry in the base class table and an entry in one of the tables of the derived classes.
Table per specific class: Here, the attributes of the abstract base class are included in the tables for the concrete subclasses. The table for the base class is omitted. The disadvantage of this approach is that it is not possible to use a query to discover instances of different classes.
Another method is the mapping of structures (relationships, inheritance) and data in general tables. The entire database contains exactly 5 tables: one for classes, one for relationships (including inheritance relationships), one for attributes, one for instances (of the classes), and one for values (of the attributes). However, this procedure has little significance in practice.
