Impedance mismatch

It is a problem in electrical engineering that occurs when two transmission lines or circuits with different impedances are connected. This can cause signal reflection resulting in attenuation and noise. See also impedance matching.

In programming terminology it refers to the attempt to connect two systems that have very different conceptual bases, most commonly when trying to use an SQL database from an object oriented program. Christopher J. Date would argue that a truly relational DBMS would pose no such problem, as domains and classeses are essentially one and the same thing. Another significant impedance mismatch in programming occurs between the domain objects and the user interface.

Impedance mismatch between object-orientation and relational databases

The impedance mismatch between object-oriented programming and relational databases occurs when a relational database is being used within an object-oriented program in such way that objects are mapped in straightforward way to database tables. This practice has been recommended and documented by some object-oriented literature as a way to use databases in object-oriented programs. However, object-oriented programs are designed with methods that result in encapsulated objectss whose representation is hidden. Mapping such private object representation to database tables makes such databases fragile, since there are significantly fewer constraints for design of encapsulated private representation of objects compared to database's use of public data, which must be amenable to upgrade, inspection and queries.

In particular, object-oriented modelling emphasises the essential concept of an invariant, which requires the use of encapsulation before any access to data of OOP objects is performed. These invariants cannot be represented in relational databases. In relational thinking, "private" versus "public" is relative to need rather than an absolute characteristic of a piece of state (data). Relational and OO often have conflicts over relativity versus absolutism of classifications and characteristics. It is sometimes said that OO is a Plato-like view of the world while relational is an Einstein-like view.

Also, access to objects in object-oriented programs is allegedly best performed via interfaces that together provide the only access to the internals of an object. Similarly, essential OOP concepts for classeses of objects, inheritance and polymorphism, are not supported by database systems. A proper mapping between relational database concepts and object-oriented concepts can be made if relational database tables are linked to associations found in object-oriented analysis. Data stored in OOP objects should not as such be stored in relational databases.

Solving the impedance mismatch problem for object-oriented programs requires recognition of the difference in scale between object-oriented programs and relational database systems. In particular, relational database transactions, as the smallest unit of work performed by databases, are much larger than any operations performed by objects in object-oriented design. Transactions are collections of related associations. Therefore, objects can only represent data relating to a small portion of a database transaction. Object-oriented design can be used as a component of a system with a database, for example, as an implementation methodology for database resources. However, direct mapping between objects and some entities in databases are not possible without running into the impedance mismatch problem.

There have been some attempts at building object-oriented database systems (OODBMS) that would by default solve the impedance mismatch problem. They have been less successful in practice than relational databases however.

Key differences between OOP and relational can be summarized as follows:

• Declarative Vs. Imperative Interfaces - Relational thinking tends to use data as interfaces, not behavior as interfaces. It thus has a declarative tilt in design philosophy in contrast to OO's behavioral tilt. (However, some relational proponents may perhaps propose using lots of triggers, etc. to provide complex behavior, but this is not a common viewpoint.)

• Schema Bound - Objects don't have to follow a "parent schema" as far as which attributes or accessors an object has while table rows must follow the entity's schema. However "dynamical relational" theory may also provide this, although it does not exist in practice yet. Still, a given row must belong to one and only one entity. The closest thing in OO is inheritance, but it is generally tree-shaped and optional.

• Access Rules - In relational, attributes are accessed and altered through predefined relational operators, while OO allows each class to create its own state alteration interface and practices. The "self-handling noun" viewpoint of OO gives independence to each object that relational does not permit. This boils down to a "standards versus local freedom" debate. OO tends to argue that relational standards limit expressiveness, while relational proponents suggest the rule adherence allows more abstract math-like reasoning, integrity, and design consistency.

• Uniqueness Observation - Row identities (keys) generally have a text-representable form, but objects don't require an externally-viewable unique identifier.

• Normalization - Relational normalization practices are often ignored by OO designs. However, this may just be a bad habit instead of a native feature of OO.

• Schema Inheritance - Most relational databases do not support schema inheritance. Although such a feature could be added in theory to reduced the conflict with OOP, relational proponents are less likely to believe in the utility of hierarchical taxonomies and sub-typing because they tend to view set-based taxonomies as more powerful and flexible than trees.

• Structure vs. Behaviour - OO primarily focuses on ensuring that the structure of the program is reasonable (maintainable, understandable, extensible, reusable, safe), whereas relational systems focus on what kind of behaviour the resulting run-time system has (efficiency, adaptability, fault-tolerance, liveness etc.). [This needs some clarification.]