Object Relational Mapping and Java Persistence: Data Modeling and Legacy Schemas
These days, it’s essential to have a strong knowledge of object relational mapping. This reflects the need for retaining application data long after the application has run. As the need for data storage grows, so too does the need to work with legacy databases or schemas. A schema is simply a description of a database—i.e., its tables, data types, constraints, etc.
Before working with legacy schemas, it’s sometimes necessary to learn more complex mapping techniques. This knowledge will help you in working around what are often quirky legacy schemas. Very often, it’s simply not an option to modify a legacy schema.
A key concept in object relational mapping is the difference between entity and value types. Let’s now look at this concept.
Entity and Value Types
In Hibernate, types can be either entity or value. An entity type has a persistent identity that can outlive the application that creates it. In other words, an entity is persisted to the database, loaded from the database, updated, etc. A value type, on the other hand, doesn’t have a persistent identity and may be considered no more than a set of attributes that relate to a more important entity. For a developer who’s starting up the object relational mapping value chain, there is a temptation to just lump everything in to the one class definition. Doing so misses an important design opportunity.
In summary, a value type may be a component of an entity. We need to make this more concrete! A typical example of an entity type is a user—e.g., a system user. The postal address of a user is more likely to be a value type. In some ways, you can think of a value type as an attribute of an entity. Let’s now see an example of how to map an entity and value type.