Object-SQL mapping |
Object-SQL mapping (commonly misnamed object-relational mapping or O/RM), is a programming technique that links SQL databases to Object-oriented programming language concepts, creating (in effect) a virtual object database. There are both free and commercial packages available that perform object-SQL mapping, although some programmers opt to code their own object-SQL mapping for their systems.
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 ) of phone numbers, and a list of addresses.
The trick comes when it s time to save that data out to permanent storage. Ideally, what database-driven software programmers want is to be able to create persistence objects which will still appear to continue to exist once the program is closed down and then started up again. In effect, the ideal situation would give the programmer such a level of abstraction that could act as if the entire database of objects were in memory, and no matter how many times the program would be switched on or off the objects would still be there.
Surprisingly, there are some utilities and database management systems that come quite close to this ideality, but reaching that stage took several twists and turns. From a programmer s perspective, the best solution is a persistent object store of some kind, into which any object can be placed and later found. Traditionally, there have been a wide range of ways to store objects persistently, but they all had their inherent problems.
=Serialization=
Most object oriented Application Programming Interfaces include some sort of solution for this task. For instance, Java programming language 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, files where objects are serialized, too often have very little organisation to them, and so 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. What programmers needed was a way to access large amounts of data efficiently, and in an object-oriented form.
=SQL database management systems=
The solution to these sorts of data storage problems already exists: database management systems. However, the primary kind of database that is used is the SQL database, which predates the object revolution that occurred in the 1990s and misimplements the relational model. Using SQL 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 SQL 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 SQL or object-oriented forms would impose limitations on each other. For example, SQL databases make complicated associations difficult, 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.
An alternate solution might be to use a truly relational DBMS. Unfortunately SQL, which misimplements the relational model, has long dominated the market and even academia. Early fully-relational implementations such as University Ingres QUEL and IBM Business System 12 never gained traction, and only recently new RDBMSs have appeared, Alphora Dataphor and Rel.
SQL databases use a series of table (database)s 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 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. Queries not only request what information to return but also specify 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.
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 paths will be faster.
Some object-SQL systems 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.
SQL, despite its deficiencies, is 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 amounts of data since the semantic gap between the object form and SQL form is eliminated.
Given these two very different worlds, object code for working with SQL 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-SQL mapping systems from programmers.
=Controversy=
[http://weblogs.asp.net/fbouma/archive/2004/10/09/240225.aspx To O/R map or not To O/R map] - Use of O/R mapping different tools have completely excluding each ones 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-SQL mapping utilities=
Object-SQL systems attempt to solve this problem by providing libraries of classes which are able to do this object-SQL 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 SQL 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 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-SQL mapping utilities except they are built on their own proprietary database software to maximise performance for both the object-oriented and SQL 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, 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.
=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. One of the few purely object-oriented databases, JADE programming language, is used throughout all the public hospitals in Australia s Northern Territory and powers the scheduling software for Britain s largest rail freight operator.
O/RM frameworks and tools
==Java==
*Java Data Objects (JDO) *Speedo [http://speedo.objectweb.org/], open source implementation of JDO *intelliBO by Signsoft [http://www.intellibo.com/], implementation of JDO *JPOX [http://www.jpox.org/], open source JDO 2 reference implementation *Enterprise Objects Framework, Mac OS X/Java *TopLink by Oracle [http://www.oracle.com/technology/products/ias/toplink/index.html] *CrossDB [http://crossdb.com/], open source *Hibernate (software), open source
==.Net==
*NHibernate [http://www.nhibernate.org/], open source *Briyante Integration Environment [http://www.visiphor.com/], commercial *Wilson ORMapper for .NET [http://www.ormapper.net/], commercial *LLBLGen Pro [http://www.llblgen.com/], commercial *Genom-e [http://www.genom-e.com/], commercial
==Perl==
==Python==
Lists of ORM tools for Python programming language: [http://www.thinkware.se/cgi-bin/thinki.cgi/ObjectRelationalMappersForPython] [http://wiki.python.org/moin/HigherLevelDatabaseProgramming] *SQLObject [http://sqlobject.org/], open source *PyDO [http://skunkweb.sourceforge.net/pydo.html], part of SkunkWEB (open source) *MiddleKit, part of Webware [http://www.webwareforpython.org/] (open source) *ForgetSQL [http://soiland.no/software/forgetsql], open source
==Ruby==
==PHP==
See also
*OODBMS *CORBA
External links
*[http://www.agiledata.org/essays/mappingObjects.html Scott W. Ambler: Mapping Objects to Relational Databases: O/R Mapping In Detail] *[http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html Core J2EE Design Pattern: Data Access Objects] *[http://sourceforge.net/projects/orm-net/ ORM-Net, for .NET] *[http://www.ideablade.com/ IdeaBlade ORM for .NET] *[http://www.visual-paradigm.com/dbva.php DB Visual Architect] *[http://citeseer.ist.psu.edu/cisq=object+and+relational+and+mapping+and+database Citations from CiteSeer] *[http://www.codefutures.com/weblog/andygrove/archives/2005/02/data_access_obj.html/ Data Access Objects versus Object Relational Mapping] *[http://www.objectarchitects.de/ObjectArchitects/orpatterns/ Patterns for Object / Relational Mapping and Access Layers] *[http://db.apache.org/ojb/ ObJectRelationalBridge] *[http://www.webobjects.com/ WebObjects]
test
**[http://www.omg.org/technology/documents/formal/relationship_service.htm Relationship Service] **[http://www.omg.org/technology/documents/formal/persistent.htm Persistent State Service]|
|