Object-relational impedance mismatch

As object - relational impedance mismatch - often only impedance mismatch - (English for about object-relational intolerance ) is defined as a problem of computer science in application development, which occurs when objects are stored in an object oriented programming in a relational database.

Background

The problem arises by the use of object-oriented programming, in conjunction with data that is stored in relational databases. Object-oriented applications provide their data through objects dar. If the data are stored, so it makes sense to store the objects in a database. However, it turns out that the relational database model has fundamental differences with the object oriented model. This incompatibility is called impedance mismatch since the early 1980s.

SYMPTOMS

The problem lies in the different paradigms of the two systems. Thus, an object can be characterized by four main features:

• Identity
• State
• Behavior
• Encapsulation

A relational system, however, derives from the relational algebra and saves truth statements in so-called relations. A relation might look like this: { name, company name }. This relation corresponds to an assertion of the form: " There is a person with name NAME, who works at a company COMPANY ". A tuple is a truth statement within the relation for example, looks like this: { John Doe, ACME } ( There is a John Doe who works at ACME. ). A tuple is itself composed of attributes (name and company ). By linking relations, new relations can be formed and thus derive new truth statements, such as the answer to " How many people are there who work at ACME? ".

A closer examination of the two paradigms demonstrates that there are some differences.

• Structure. An object comprises both data and behavior. The corresponding class may be part of a class hierarchy. The relational model does not support such an object-oriented concepts such as inheritance ( generalization and specialization). A tuple in the sense of the relational model is merely a truth statement dar. Looking at a class - subclass relationship, so only an object to represent the data is required, whereas non-redundant representations of the relational model require two tuples in the object-oriented model.
• Identity. An object has one on its state (data) independent identity. If an object-oriented application is run twice, the same object has (in the sense of his condition ) different identities. Also, two data- like objects differ in a program run by their identities. In contrast, the identity of a tuple is determined by its data (or by the primary key, which is derived from the data of the tuple ). A tuple can be uniquely identified by its data so at any time, which is not true for an object.
• Data encapsulation. An object protects its data from being changed or limited by methods ( behavior ) the way in which data can be changed, a. An object there is the possibility to modify data in well-defined ways. In contrast, there are no such protection mechanisms in the relational model (many database vendors extend the SQL standard to create ways to achieve this, but this is not a fundamental part of the relational model ).
• Way of working. The data in a relational database may be modified by transactions from a connected application. This is strongly reminiscent of the procedural programming, whose characteristic feature is the separation of data and behavior. The object-oriented model grouped logically coherent behavior with relevance for this behavioral data in objects. An object-oriented application can be viewed as a network of interacting objects. The operations that can be executed on a relational database, work volume is based, whereas objects communicate individually with other (message passing).

Solutions

Object-oriented database

The most obvious solution is to replace the relational database with an object-oriented database. The programmatic handling is made easier, but complex queries can be very complicated. Furthermore, you thereby with management and database administrators often meets with opposition, because the data are hard-wired to the object and can not be visualized without the associated application. Eventual mapping is completely eliminated.

Object-relational database

Many of the major manufacturers expanded their relational database products with object-oriented features to an object-relational database management system ( ORDBMS ). In order to respond to the demand for object-oriented databases. Existing architectures with relational databases can be retained by these upgrades and offer the developer an object-oriented view of the data. The impedance mismatch is thus largely bypassed, depending on the database system but must still be accessed mapping.

Expand programming to relational functions

Thus, the problem is solved backwards. Through the relational support of the language used (eg embedded SQL) no mapping is necessary. This solution, however reluctant many OOP developers, as they usually restricts the use of objects.

O / R Mapper

An object-relational mapper is a layer between the application and the database. He takes care of the complete mapping between objects and tables. This process is invisible to the developer. Today Mapper perform very well - with increasing complexity, however, therefrom arising, many other issues. The more specific the solution is, the more frequently the developer must determine how the mapping between the worlds is to be done. This can sometimes be extremely complicated.

An O / R mapper must solve problems at various levels. One approach describes four levels:

• Paradigm. A paradigm in this context is a concept for representing data. Object relational mapping must the differences of the paradigms can overcome. In the previous section, these have already been explained.
• Language. A language is used to express a model through a paradigm. Object-oriented programming languages ​​commonly used are eg Java and C #. Relational databases are addressed using SQL. A major difference between these is the type system. SQL standard defines certain primitive types that can be used to store data. To store complex data, their own tables are needed. In contrast, the ability to define new data types in object-oriented languages ​​by native classes is an integral part of that.
• Scheme. A schema is a expressed in a specific language model. Source code and database scripts can be seen as the schema of an object- relational application. Most of the O / N mapper require a certain type of configuration (often a mapping file ) in order to overcome the differences between the schemes. It should be noted that the developers of object-oriented schema rule, make sure that the objects slightly complex business logic can be mapped as a database designer is usually anxious to avoid redundancy and to optimize performance (eg by normalization of the database schema ).
• Instance. Instance in this context means concrete data. This level is primarily concerned with issues such as access and modification of data and conversion of different data types, etc.

Conclusion

All previously existing approaches do not provide a real solution, only a more or less elegant workaround. No matter which solution you choose - as long as the systems are different, each developer will sooner or later reach the point at which no longer meets one or more of the following points his solution:

• Maintainability
• Performance
• Intelligibility

Credentials