Object Relational Mapping - User Case Studies
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:
- Please explain briefly what are your application domains and your role in the enterprise.
- Do you have an "impedance mismatch" problem?
- 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)?
- Do you believe that Object Database systems are a suitable solution to the "object persistence" problem? If yes why? If not, why?
- What would you wish as new research/development in the area of Object Persistence in the next 12-24 months?
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.
Hrm... compile time checking a new thing, what?
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... )
Cultural impedance mismatch
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 =
See also other examples.
Re: ORM Decomposition
Use the ORM for 90-95% of cases, stored procedures mapped to methods for the last 5%. Problem solved.
Re: Cultural impedance mismatch
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...".
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.