Information About

Object-relational Impedance Mismatch
  CATEGORIES ABOUT OBJECT-RELATIONAL IMPEDANCE MISMATCH
   
relational model
   
databases
   
object-oriented programming
   
APPAREL
BABY
BEAUTY
BOOKS
CAR TOYS
CELL PHONES
DVD'S
ELECTRONICS
GOURMET FOOD
GROCERIES
HEALTH & PERSONAL
HOME & GARDEN
JEWELRY
MUSIC
MUSIC INSTRUMENTS
OFFICE PRODUCTS
SOFTWARE
SPORTING GOODS
TOOLS & HARDWARE
TOYS
VIDEO GAMES
SHOPPING HOME
MORE SHOPPING...



The Object-Relational Impedance Mismatch refers to a set of conceptual and technical difficulties which are often encountered when a Relational Database is being used by a program written in an Object-oriented Programming Language or style; particularly when objects and/or class definitions are mapped in a straightforward way to database tables and/or relational schemata. 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 Object s 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 a 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 Interface s that together provide the only access to the internals of an object. Similarly, essential OOP concepts for Class es 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.

It has been argued, by Christopher J. Date and others, that a truly Relational DBMS would pose no such problem, as Domain s and Class es are essentially one and the same thing. It is suggested that a naïve mapping between classes and relational schemata is a fundamental design mistake; and that individual tuples within a database table (relation) ought to be viewed as establishing relationships between entities; not as representations for complex entities themselves. However, it has also long been seen as an advantage of the relational approach that entities and relationships can both be modelled using tables.

Another significant impedance mismatch in programming occurs between the Domain Object s and the User Interface . Sophisticated user interfaces, to allow operators, managers, and other non-programmers to access and manipulate the records in the database, often require intimate knowledge about the nature of the various database attributes (beyond name and type). In particular, it's considered a good practice (from an end-user productivity point of view) to design user interfaces such that the UI prevents illegal transactions (those which cause a Database Constraint to be violated) from being entered; to do so requires much of the logic present in the relational schemata to be duplicated in the code.

A third source of contention relates to the use of SQL . It has been argued that SQL, due to a very limited set of domain types (and other alleged flaws) makes proper object- and domain-modelling difficult; and that SQL constitutes a very lossy and inefficient interface between a DBMS and an application program (whether written in an object-oriented style or not). However, SQL is currently the only widely-accepted common database language in the marketplace; use of vendor-specific query languages is seen as a bad practice when avoidable. Other database languages such as Business System 12 and Tutorial D have been proposed; but none of these has been widely adopted by DBMS vendors.

Another source of contention is where the "canonical" copy of state is located. The relational model generally assumes that the Database Management System is the only authoritative repository of state concerning the enterprise; any copies of such state held by an application program are just that--temporary copies (which may be out of date, if the underlying relation was subsequently modified by a transaction). Many object-oriented programmers prefer to view the in-memory representations of objects themselves as the canonical data, and view the database as a backing store and persistence mechanism.

Yet another source of contention concerns the division of responsibility between application programmers and Database Administrators . It is often the case that needed changes to application code (in order to implement a requested new feature or functionality) require corresponding changes in the database definition; in most organizations, the database definition is the responsibility of the DBA. Due to the need to maintain a production database system 24 hours a day; many DBA's are reluctant to make changes to database schemata that they deem gratuitous or superfluous; and in some cases outright refuse to do so. Use of developmental databases (apart from production systems) can help somewhat; but when the newly-developed application "goes live"; the DBA will need to approve any changes. Some programmers view this as intransigence; however the DBA is frequently held responsible if any changes to the database definition causes a loss of service in a production system--as a result, many DBAs prefer to contain design changes to application code, where design defects are far less likely to have catastrophic consequences.

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 databases, 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.


  • Object Identity - Objects (other than immutable ones) are generally considered to have a unique identity; two objects which happen to have the same state at a given point in time are not considered to be identical. Relations, on the other hand, are viewed as data records with no concept of identity. That said, it is a common practice to fabricate "identity" for records in a database through use of globally-unique Candidate Keys ; though many consider this a poor practice for any database record which doesn't have a one-to-one correspondence with a real world entity.


  • 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. An alternate view is that a collection of objects, interlinked via Pointers of some sort, is equivalent to a Network Database ; which in turn can be viewed as an extremely-denormalized Relational Database .


  • Schema Inheritance - Most relational databases do not support schema inheritance. Although such a feature could be added in theory to reduce 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. OO advocates point out that inheritance/subtyping models need not be limited to trees (though this is a limitation in many popular OO languages such as Java ). It has been argued that trying to inherit from a database record is a mistake.


  • 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.). needs some clarification.


As a result of the Object-Relational Impedance Mismatch, it is often argued by partisans on both sides of the debate that the other technology ought to be abandoned or reduced in scope. Some database advocates view traditional "procedural" languages as more compatible with a RDBMS than many OO languages; and/or suggest that a less OO-style ought to be used. (In particular, it is argued that long-lived domain objects in application code ought not exist; any such object that do exist should be created when a query is made and disposed of when a transaction is complete). On the other hand, many OO advocates argue that more OO-friendly persistence mechanisms ought to be developed and used, and that relational technology ought to be phased out. Of course, it should be pointed out that many (if not most) programmers and DBAs do not hold either of these viewpoints; and view the Object-Relational Impedance Mismatch as a mere fact of life that Information Technology have to deal with.