| Object-relational Mapping |
Website Links For Mapping |
Information AboutObject-relational Mapping |
| CATEGORIES ABOUT OBJECT-RELATIONAL MAPPING | |
| databases | |
| database management systems | |
|
THE PROBLEM In object-oriented programming, programming objects represent real-world objects. 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 object-oriented terms this would be represented by a "person ) of phone numbers, and a list of addresses. The crux of the problem is in translating those objects to forms which can be stored in files or databases, and which can later be retrieved easily while preserving the properties of the objects and their relationships; these objects can then be said to be Persistent . Historically, there have been several approaches to solving this problem. RELATIONAL DATABASE MANAGEMENT SYSTEMS (RDBMS) The solution to these sorts of data storage problems already exists: Relational Database Management System s. The primary kind of database used is the relational database, which predates the popularisation of object-oriented programming in the 1990s. Using relational databases to store object-oriented data leads to a Semantic Gap where programmers would be required to allow their software to function in two different worlds — processing of data would be done in object-oriented form, but the same data would have to be stored in relational form. Requiring this constant conversion between two different forms of the same data not only had the effect of stifling performance, but imposed difficulties to the programmer as the relational or object-oriented forms would impose limitations on each other. For example, relational databases make complicated associations difficult, and they tend to "map" poorly into the OO world because they fail to implement the Relational Model 's user-defined types. This problem is known as Impedance Mismatch . Relational databases use a series of '' Table s'' representing simple data. Optional or related information is stored in other tables. A single (persistent object) 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 relational databases, 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. Queries not only request what information to return but also need to know how the tables involved are related to each other, illustrating the point that tables do not know their relationships when they are sitting in the database, these relationships are only known when a query is run to specify the relationships. Relational databases (which try to implement the Relational Model), do maintain relationships via constraints but the SQL query language is generally unaware of these. Because RDBMS usually don't implement relational awareness of the physical level, 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 SQL 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 paths will be faster. Some object-relational mappers automatically keep the loaded objects in memory in constant synchronisation with the database. For this to be possible, after construction of an object-to-SQL mapping query, first returned data is copied into the fields of the objects in question, like any object-SQL mapping package. 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. RDBMSs are generally capable of much faster performance on global queries that involve a large proportion of the database; however, object-oriented access is deemed to be more efficient when manipulating a smaller amount of data since the semantic gap between the object form and relational form is eliminated. Given these two very different worlds, object code for working with relational databases tends to be complex and susceptible to bugs. Database-driven software developers looked for a better way to achieve persistence for their objects. THE SOLUTION Many commercial packages have been developed to take the strain of developing object-relational mapping systems from programmers. CONTROVERSY To O/R map or not To O/R map - Different O/R mapping tools have completely excluded each others different approaches to object-oriented programming and will highly affect your design. It really matters if you will use Entity(Chen/Yourdon) approach or Domain model(Fowler/Evans) approach. OBJECT-RELATIONAL MAPPING UTILITIES Object-Relational systems attempt to solve this problem by providing libraries of classes which are able 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 phone number 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/RM 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/RM systems have been created over the years, but their effect on the market seems mixed. Considered one of the best was 5.2. Upon opening any developer journal or magazine these days, you will see advertisements for so-called post-SQL databases such as Caché . These are identical to the usual object-relational mapping utilities except they are built on their own proprietary database software to maximise performance for both the object-oriented and relational view of the system. 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, JDO is a standard, and several implementations are 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, while 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. OBJECT-ORIENTED DATABASES The ideal solution would be to use an Object-oriented Database Management System , which, as the name implies, is a database designed specifically to look at and work with object-oriented programs. Using an OODBMS would eliminate the need for converting data to and from its SQL form, as the data would be stored in its object representation. Object-oriented databases are yet to come into widespread use. One of their main limitations is that switching from an SQL DBMS to a purely object-oriented DBMS means you lose the capability to create SQL queries, which are excellent and well-suited for finding answers to ad-hoc queries. For this reason, many programmers find themselves more at home with an object-SQL mapping system, even though most commercial object-oriented databases are able to process SQL queries to a limited extent. However, object-oriented databases are beginning to gain popularity as programmers seek to improve on the performance of object-SQL mapping. =O/RM frameworks and tools= ColdFusion
Common Lisp
Java
.NET
Perl
PHP
Python Lists of ORM tools for Python : [http://wiki.python.org/moin/HigherLevelDatabaseProgramming
Ruby
Smalltalk
REFERENCES AND NOTES |
|
|