Object relational mapping: Top down vs bottom up mapping

One of the greatest hypes in modern enterprise software development is the term object relational mapping.

Back in the old days (before 2002), development of database applications was done primarily using the traditional way: SQL queries, JDBC resultsets, ADO datasets, etc. That time I was using Borland Delphi. I was using plain sql queries and datasets (along with databound widgets).

Some day I noticed that Delphi Enterprise (I think since version 6) had a very bizzard feature called Delphi Bold. I was trying to read what was the purpose of this tool and found out that it was an object relational mapping framework! It was completely integrated with Delphi and there were even ORM-bound widgets to help you out in RAD development! The query language was the OCL (Object Constraint Language) and had nothing to do with SQL. Anyway, it seemed quite compilcated to me and decided to drop my curiocity needs on this tool!

However, I had already realized that developing software using SQL queries and databound controls in the long term results to error prone applications that are difficult to manage. It it was then I decided to develop a simple ORM framework in Delphi using data transfer objects and encapsulating the sql queries in a data access layer. The result was worth the trouble since I managed to separate the sql queries and the whole data access code from the rest of the application.

When I entered the Java arena in 2003, I did a search on ORM tools. I found some (Java Data Objects, iBatis), but only one really stood up: Hibernate! I quickly started to investigate hibernate features and decided that it was an amazing tool that could be used by the whole team and completely get rid of manual sql query handling. And I was right, the team loved the tool, especially as a cool term used in their resume.

However, a dilima came up. What is the best approach to create your java model classes?
1. Create your database schema (tables, foreign keys) and use a tool (Hibernate includes one) to automatically create a java class for each of the tables.
or
2. Create your java class model completly ignoring the term "Database" and focus on using the rich expressiveness of class modeling and object oriented paradigm.

Well, from the first moment I selected the second choice, but I then saw many people not feeling comfort at all with me. I sounded a little bit crazy when I was saying create your class model using an object oriented approach and after your are COMPLETELY finished then think how to map your classes to tables.
They all said that there were no reason why to use this tecnique since everything can be done just be carefully designing your database schema and object oriented modeling is too complicated to use without adding any real value.

Even today the majority of the programmers and few (I believe) software architects create the domain model by designing a database schema. The database schema design terminology includes only four terms: table, primary key, unique key, foreign key.
Of course, they make a very elegant database design, and then they automatically create the classes from the database. A table will be mapped to a class, the table columns to class properties of which the primary key will be properly marked and the foreign keys will be mapped as class associations and class properties. Everything seems to be ok or isn't it?

The answer to this question is based on the following idea: A man's thoughts are bounded by the richness of his vocabulary. What this means is that a smaller vocabulary results to simpler thoughts.

Now in our case. The database design model official uses only four terms (table, primary key, unique key, foreign key). The object oriented domain model uses the following terms:
Class, class attributes, class inheritance, class polymorphism, one to one class association (bidirectional or unidirectional), one to many class association (bidirectional or unidirectional), many to many class association (bidirectional or unidirectional). Associations can be specified using sets or lists (lists of unique items or just lists). Also we can put cardinality attributes to these associations (i.e. an order can have at most ten orders items and no less than one).

As you can see our objected oriented vocabulary is using more than 15 terms! This in turn allows to make more complex domain model thoughts.

I am a strong follower of the "be practical" attitude in software programming. I use the technology to make me life better. It is nice to say that I use ORM tools but it has to have a positive result in my productivity. My five year experience in domain class modeliing lead me to the result that the productivity impact in favor of the object oriented domain modeling is absolutely HUGE.

I encourage everyone to put the effort in changing his way of thinking in domain modeling. After all, the exact same problem arised when object oriented programming came out and everyone was thinking procedural. Now the object oriented programming background is a must for every enterprise project.