Object Relational Mapping - User Case Studies

Posted by Steven Robbins on Jul 24, 2008

Sections

Enterprise Architecture,

Operations & Infrastructure,

Process & Practices,

Architecture & Design,

Development

Topics

Hype ,

Announcements ,

Architecture ,

Object Oriented Design

Tags

Object Databases ,

LINQ ,

Domain Modeling ,

Database

Roberto Zicari, from ODBMS.org, collected interviews and stories from several users of Object/Relational mapping technologies. The main point of the cases was around "impedance mismatch" between the object technology in the domain model and the relational technology in the data model.

Professor Zicari had five questions or topics of each user. The lead questions focused on explaining the applications, the O/R obstacles, and how users solved or worked around them. The last questions explored how ODBMS technology could or has helped in these areas. The questions/topics were:

1. Please explain briefly what are your application domains and your role in the enterprise.
2. Do you have an "impedance mismatch" problem?
3. What solution(s) do you use for storing and managing persistence objects? What experience do you have in using the various options available for persistence for new projects? What are the lessons learned in using such solution(s)?
4. Do you believe that Object Database systems are a suitable solution to the "object persistence" problem? If yes why? If not, why?
5. What would you wish as new research/development in the area of Object Persistence in the next 12-24 months?

In the study, the term "impedance mismatch" was described as

When the data models used to persistently store data (whether file systems or database management systems) and the data models used to write programs against the data (C++, Smalltalk, Visual Basic, Java, C#) are different, this is referred to as the "impedance mismatch" problem.

While there has been much debate over the definition of and even the existence of the O/R impedance mismatch, many of the people in the cases said that they had experienced it in their projects. John Davies, Technical Director of Iona, UK, said in answer to "Do you have an impedance mismatch problem?"

This "impedance mismatch" is a serious problem in the enterprise, upwards of 25-33% of development time is being wasted squeezing objects into relational persistence, usually termed Object Relational Mapping (ORM). While the examples of such tools demonstrate the simplicity of ORM, real life is usually several orders of magnitude more complex and the whole idea breaks down. Even the best tools create an incredibly inefficient model, resulting in serious performance issues.

Richard Aherns, a Director at Merrill Lynch, also agreed that the problem is real

We absolutely have this issue. In the equity derivatives business, agility and time to market are incredibly important. New products are introduced regularly, and flexible technology is required to adapt and keep up with the rapid pace of change in the industry. In our domain of order and quote management, having to maintain object-to-relational mappings across a wide variety of product and asset times is a drag on developer productivity and limits our ability to scale.

Gerd Klevesaat, Software Architect at Siemens AG in Germany, also acknowledged the mismatch problem and went on to explain how the ORM tools don't necessarily help the developers. He stated that "you are forced to define a query in a special query language. It would be beneficial to use the programming language to leverage compile time checking of query statements and navigation capabilities." Gerd pointed out that there are technologies and tools that are beginning to bridge the gap, specifically "LINQ in .NET, native queries in db4o or DataSets in Groovy."

On the other side of the discussion was Scott Ambler, Practice Leader for Agile Development at IBM Rational. Scott's take on the "impedance mismatch" issue was that several solutions exist to the technology side of the issue (e.g., O/R persistence frameworks, object databases, or OR databases). Instead, Ambler pointed out that most organizations have, in his words, a "cultural impedance mismatch" between the data communities and the developer communities: "These two communities have different ways of looking at the IT world, both of which have their strengths and weaknesses, and both communities could benefit from working closely with the other." Scott had more to say on the subject outside of the ODBMS.org case studies.

In general, Zicari's study was aimed at exposing the problems with object-oriented systems using relational database technologies. It also showed how many development and business organizations are starting to view object databases and other object persistence technologies as up and coming options for enterprise technologies when applied to the right set of problems.

1. Back to top

   Hrm... compile time checking a new thing, what?

   by Francois Ward

   I was using ORMs that leveraged the compile time checking features of the language years ago (LLBLGEN Pro anyone?), and its been around since longer than that, and it wasn't the first to do it...
   
   Its not new, and works quite well. The issue is mostly with architects that are trying to mix modern technology with obsolete practices and methodologies from 20 years ago. (That happens -away- too often... )

   Reply

2. Back to top

   Cultural impedance mismatch

   by Michele Mauro

   I second this interpretation. Everybody grew up studying the relational model of data analysis. The Object Oriented model that OODB propose has little academia value, so when analysist analyze, they often think in terms of tables, not objects. I experience this quite often, with my fellow collegues who work on the business analysis, when I correct them "you don't see the t_business_unit table, you have the BusinessUnit objects...".
   
   Michele

   Reply

3. Back to top

   ORM Decomposition

   by Jacob Hookom

   There's something to be said though for having an ORM solution which can easily be decomposed or allows you to 'skip' the ORM piece and go straight DB when the use case is justified. Yes, there is an initial cost in adopting ORM, but chose an implementation which will not tie your hands when you need to get out.

   Reply

4. Back to top

   Query

   by Thomas Mueller

   "you are forced to define a query in a special query language. It would be beneficial to use the programming language to leverage compile time checking of query statements and navigation capabilities."
   
   
   That's not a problem of O/R mapping itself, that's a problem of the existing tools. There are some tools that solve the problem, for example LINQ in .NET. It's a bit tricky to do that in Java, but it's possible. See for example the JaQu tool (part of the H2 database):

   
   Product p = new Product();
   List<Product> expensiveInStockProducts =
    db.from(p).
    where(p.unitsInStock).bigger(0).
    and(p.unitPrice).bigger(3.0).
    orderBy(p.productId).select();
   

   
   See also other examples.

   Reply

5. Back to top

   Re: ORM Decomposition

   by Francois Ward

   All good ORMs support mapping stored procedures to strongly typed methods. That pretty much lets you handle all messed up and weird scenarios right there.
   
   Use the ORM for 90-95% of cases, stored procedures mapped to methods for the last 5%. Problem solved.

   Reply

6. Back to top

   Re: Cultural impedance mismatch

   by Mileta Cekovic

   so when analysist analyze, they often think in terms of tables, not objects. I experience this quite often, with my fellow collegues who work on the business analysis, when I correct them "you don't see the t_business_unit table, you have the BusinessUnit objects...".
   Michele

   
   
   My experience is exactly the same. Even with 'senior' analysts. They just 'analyze' in tables and fields and cannot up the level of abstraction. The similar thing also happens on the other side (although I saw that much less often), where OO 'analysis' is done in the context of the particular OO programming language, instead of abstract model expressed by, say, UML.
   
   One of the reasons for this is that modeling tools are not up to their tasks and tend to tie the modeler to the implementation paradigm, either relational database or OO language.

   Reply

• Older >