Object-relational mapping
|
|
Object Relational mapping, more properly called object-SQL mapping, is a programming technique that links SQL databases to object-oriented language concepts, creating (in effect) a "virtual object database."
| Contents |
The problem
In the object-oriented programming methodology, programming objects represent real-world objects to some degree. To illustrate, consider the example of an address book, which contains listings of people along with zero or more phone numbers and zero or more addresses. In the OO world this would be represented by a "person object" with "slots" (fields, members, instance variables etc.) to hold the data that makes up this listing: the persons name, a list (or array) of phone numbers, and a list of addresses.
The trick comes when it's time to save that data out to permanent storage. From a programmer's perspective, the best solution is a persistent object store, into which any object can be placed and later found. Most object oriented APIs include some sort of solution for this task. For instance, Java uses the Serializable interface which will "serialize" a series of objects into a form suitable for saving to disk. This is a perfectly usable solution in most systems programming situations, and most programs use some similar form of object store; but it fails miserably in applications programming, where the database must be accessible ad-hoc by lay users.
However, for larger applications the store has to be considerably more powerful. Even minor damage to a "simple" file can render the entire file unusable for real-world applications. In addition, it becomes progressively more expensive to find information in such a store as the total number of objects—or more generally, the total amount of data—grows.
The solution to these sorts of data storage problems already exists: databases. However, almost all database systems predate the object revolution that occurred in the 1990s, and they tend to "map" poorly into the OO world because they fail to implement relational model's user-defined types. This problem is known as impedance mismatch, generally and incorrectly considered to be a mismatch in conceptual models, while it is actually a failure in SQL to provide relational capabilities.
The ideal solution would be to use an object database, which, as the name implies, is a database designed specifically to look at and work with object programs. However, these databases have a serious credibility problem in the "big iron" world of databases. Programmers are forced—directly or indirectly—to use SQL systems instead.
An alternate solution might be to use a truly relational DBMS. Unfortunately SQL, which doesn't fully implement the relational model, has long dominated the market and even academia. Early fully-relational implementations such as Ingres QUEL and IBM BS/12 never gained traction, and only recently a new RDBMS has appeared, Alphora Dataphor.
SQL databases use a series of tables representing simple data. Optional or related information is stored in other tables. A single record in the database often spans several of these tables, and requires a join to collect all of the related information back into a single piece of data for processing. This would be the case for the address book, which would likely include at least a user and address table, but perhaps even a phone number table as well.
In the object world there is a clear sense of "ownership", where a particular person object owns a particular phone number. This is not the case in a SQL, where the tables have no idea how they relate to other tables at a fundamental level. Instead, the user must construct a "query" to gather the information back together.
Doing this is not a simple task. Because SQL doesn't implement relational separation of the physical and logical levels, it can be very expensive to submit several queries in a row. One can't, for instance, expect good performance if one does a series of operations like "find this user, ok, now find this user's addresses, ok...". Instead, one must construct a single large query that says "find this user and all their addresses and phone numbers and return them in this format."; this would enable a truly relational system's optimiser to reach much higher global performance than possible with OO hand-tuned access, even if probably some particular OO access path will be faster. SQL, despite its deficiencies, is generally capable of a much faster global performance than OO.
After construction of the query, the data returned has to be copied into the fields in the objects in question. Once there, the object has to watch to see if these values change, and then carefully reverse the process to write the data back out to the database.
Given these two very different worlds, object code for working with databases tends to be complex and susceptible to bugs.
The solution
Object-SQL systems attempt to solve this problem by providing software to do this mapping automatically. Given a list of tables in the database, and objects in the program, they will automatically map requests from one to the other. Asking a person object for its phone numbers will result in the proper query being created and sent, and the results being "magically" translated directly into address objects inside the program.
From a programmer's perspective, the system looks like a persistent object store. One can create objects and work with them as one would normally, and they automatically end up in the relational database.
Things are never that simple though. All O-SQL systems tend to make themselves visible in various ways, reducing to some degree one's ability to ignore the database. Worse, the translation layer can be slow and inefficient (notably in terms of the SQL it writes), resulting in programs that are slower and use more memory than code written "by hand."
A number of O-SQL systems have been created over the years, but their effect on the market seems mixed. Considered one of the best was NeXT's Enterprise Objects Framework (EOF), but it failed to have a lasting impact on the market, chiefly because it was tightly tied to NeXT's entire toolkit, OpenStep. It was later integrated into NeXT's WebObjects, the first object-oriented Web Application Server. Since Apple Computer bought NeXT in 1997, EOF provides the technology behind the company's e-commerce Web site, the .Mac services and the iTunes Music Store. Apple provides EOF in two implementations: the Objective-C implementation that comes with the Apple Developers Tools and the Pure Java implementation that comes in WebObjects 5.2.
An alternative approach is being taken with technologies such as RDF and SPARQL, and the concept of the "triplestore". RDF is a serialization of the subject-predicate-object concept, RDF/XML is an XML representation of it, SPARQL is an SQL-like query language, and a triplestore is a general description of any database that deals with a triple.
More recently, a similar system has started to evolve in the Java world, known as Java Data Objects (JDO). Unlike EOF, it is a standard only, and it is expected that several implementations will be available from different vendors. The Enterprise Java Beans 3.0 (EJB3) specification also covers this same area. There has been standards conflict between the two standards bodies in terms of pre-eminence. JDO has several commercial implementations. EJB 3.0 is still under development. However, most recently another new standard has been announced by JCP to bring these two standards together and make the future standard something that works with various Java architectures.
See also
External links
- NHibernate (http://www.nhibernate.org/)
- IdeaBlade ORM for .NET (http://www.ideablade.com/)
- DB Visual Architect (http://www.visual-paradigm.com/dbva.php)
- Citations from CiteSeer (http://citeseer.ist.psu.edu/cis?q=object+and+relational+and+mapping+and+database)
- Patterns for Object / Relational Mapping and Access Layers (http://www.objectarchitects.de/ObjectArchitects/orpatterns/)
- SolarMetric Kodo JDO (http://www.solarmetric.com/)
- ObJectRelationalBridge (http://db.apache.org/ojb/)
- Versant Open Access (http://www.versant.com/products/openaccess)
- Speedo (http://speedo.objectweb.org/)
- CrossDB (http://crossdb.com/)
- WebObjects (http://www.webobjects.com/)
- CORBA
- PolePosition Benchmark (http://www.polepos.org) -- shows the performance trade-offs for solutions in the object-relational impedance mismatch context.
- Relationship Service (http://www.omg.org/technology/documents/formal/relationship_service.htm)
- Persistent State Service (http://www.omg.org/technology/documents/formal/persistent.htm)zh:对象关系映射