1. ORM Object-Relational Mapping 1

2. Object Persistence Persistence is the ability of an object to survive the lifecycle of the process, in which it resides.  it is a desired feature in most nontrivial applications.  Persistence implies that data lives longer than objects.  When the program is stopped/restarted, the data from last execution is readily available. 2

3. Persistence Options Storing information in simple data files:  Insufficient for all but the most trivial cases (e.g., configuration data). Using object Serialization:  Supported in Java “out of the box”.  Perfect match for Java objects.  No support for non-Java environments.  Monolithic (save/store all objects every time).  Completely unusable for real-world cases. 3

4. Persistence Options (cont.) Using an Object-Oriented Database (OODBMS).  Maps nicely to object-oriented programs.  Not very popular.  Performance problems.  No industry standard. 4

5. Using a Relational Database The most common solution: a relational database. –Information is stored in tables. –Access via SQL. –Based on industry standards. –Widely accepted. –Unrivaled performance. But… How? 5

6. Using a Relational Database (cont.) The basic idea: –Map every persistent class to a database table e.g., Client ↔ CLIENT –Map every class field to a table field. e.g., String Name ↔ NAME (VARCHAR) –Every class instance represents a database row. –Access the database using SQL. In the case of Java, use JDBC or libraries that rely on it. 6

7. The Paradigm Mismatch However, there are many inherent problems to mapping object-oriented data to databases.  Granularity.  Subtypes and polymorphism.  Identity.  Associations.  Collections.  … and other problems. Let’s review a few of these problems in detail. 7

8. The Granularity Problem Consider the following (very typical) database table: 8

9. The Granularity Problem (cont.) Does the following class match? 9 class Client { String name; String mailAddressStreet; String mailAddressCity; String mailAddressState; String mailAddressZip; String billingAddressStreet; String billingAddressCity; String billingAddressState; String billingAddressZip;... methods } class Client { String name; String mailAddressStreet; String mailAddressCity; String mailAddressState; String mailAddressZip; String billingAddressStreet; String billingAddressCity; String billingAddressState; String billingAddressZip;... methods }

10. The Granularity Problem (cont.) What we want is the following two classes: OOP and databases work on different levels of granularity. 10 class Client { String name; Address mailAddress; Address billingAddress;... methods } class Address { String street; String city; String state; String zip; } class Client { String name; Address mailAddress; Address billingAddress;... methods } class Address { String street; String city; String state; String zip; }

11. Subtyping and Polymorphism Problem Consider the following class diagram: 11

12. Subtyping and Polymorphism Problem (cont.) How do we store BillingDetails in the database? How do we represent the relationship between Client and BillingDetails?  A foreign key can only point to one other table – CreditCard or BankAccount. 12

13. Identity Problem A single database row is always unique.  Assuming a primary key is used. But in OOP, multiple objects in memory can represent the same notion.  Two objects that map to the same database row. Database identity is different from object identity (“==”) and object equality (“equals()”). 13

14. Coping with the Paradigm Mismatch The paradigm mismatch greatly complicates OOP/RDBMS interoperability. Up to 30% of enterprise Java application code deals with persistence.  Tedious SQL/JDBC.  Bridging information representation.  Caused more than one project to sink. 14

15. Coping with the Paradigm Mismatch (cont.) The most accepted solution today: using middleware.  A library that bridges OOP to RDBMS.  “Object/Relational Mapping” (ORM). Java middleware solutions for persistence:  J2EE Entity EJBs.  Hibernate.  JDO (Java Data Objects). 15

16. Characteristics of a good ORM Solution Transparent (non-intrusive). Efficient (enables lazy-loading, selective updates, caching, etc.). Powerful (advanced querying capabilities, a lot of configuration options). Flexible (can fit into various environments such as Servlet Containers, EJB Containers, Plain Java Apps, etc.). Easy to use (mild learning curve, good testability, etc.). Supports OO idioms and concepts (inheritance, polymorphism, etc.). Standard. 16

17. ORM Options EJB 3 Hibernate JDO TopLink CocoBase Castor … 17