- Relational Persistence for Java and .NET
Historically, Hibernate facilitated the storage and retrieval of Java domain objects via Object/Relational Mapping. Today, Hibernate is a collection of related projects enabling developers to
utilize POJO-style domain models in their applications in ways extending well beyond Object/Relational Mapping.
http://www.hibernate.org/
Hibernate is an object-relational mapping (ORM) library for the Java language, providing a framework for mapping an object-oriented domain model to a traditional relational database. Hibernate
solves object-relational impedance mismatch problems by replacing direct persistence-related database accesses with high-level object handling functions.
Hibernate is free software that
is distributed under the GNU Lesser
General Public License.
http://en.wikipedia.org/wiki/Hibernate_%28Java%29
Refers to the UML modeling term
ofRefers to the UML modeling term of
composition
Commonly referred to as a “has a”
relationshipeato s p
– An
AccountOwner has an Address
Does not exist on its own;
dependentDoes not exist on its own; dependent
on a parent object
‘Address’ is a component
• Address is a component of ‘
AccountOwner’
– Non-existent without
AccountOwner
– No id of its own
Entity
lives on its own
Can
be made components
Can
be related/associated to other entities
‘
AccountOwner’ is an Entity
– Can
lives on its own
– Has its own id
Using Components
1. Determine your domain model
Which objects are best suited to be a component?
2. Create your database tables
Model your components accordingly within entity tables
Create your Java classes
• One for each entity, and one for each component
• Setup your components within the entity classes
Write the Hibernate mapping file for the
entity, using the embedded component tag
ithi it
t id
tif th t lwithin it to identify the component class
Nested Components
Component Address has nested component ‘
ZipCode’
Inheritance
Commonly referred to as an “is
a”Commonly referred to as an is a
relationship
Polymorphism
– Dynamic realization of subclass behavior while
treating the object as an instance of its superclass
Inheritance Realization
Easy to do in an
object oriented language
– Java: Use ‘extends’ or
‘implements’ keyword
Not so easy to do in a relational database
– Tables do not ‘extend’ from each other
– Part of the ‘impedance mismatch’ problem
How do we get around this?
– Four approaches through Hibernate
• Hibernate implicit polymorphism
• Table-per-concrete class
• Table-per-class-hierarchy
• Table-per-subclass
Modeling Inheritance
1
.Determine your domain model
What objects have hierarchical relationships?
2. Choose your inheritance strategy
• Hibernate implicit
polymorphismHibernate implicit polymorphism
• Table-per-concrete class
• Table-per-class-hierarchy
• Table-per-
subclassTable per subclass
3. Create your database tables based on the
chosen strategy
4. Code your Java objects, using
‘extends’ or
‘implements’
5. Write your Hibernate mapping file using
the
appropriate subclass tags
Implicit Polymorphism
Database
– One database table per concrete class
Hibernate Mapping Files
– Separate mapping files for each inherited class
• Like normal, including any inherited properties
Default Behavior
– Out of the box Hibernate will automatically
recognize any Java inheritance associations
Implicit Polymorphism
Advantages
– Get it for free. Hibernate automatically scans classes
on startup (including inheritance); No additional
configuration/mapping
neededconfiguration/mapping needed
– Not a lot of
nullable columns (good for integrity)
Queries against individual types are fast and simple
– Queries against individual types are fast and simple
Disadvantages
– Makes handling relationships difficult
• One-to-many relationships typically require a foreign key, but
inherited associations can’t
key to both tables; Databases y
don’t support it (Example:
AccountOwner:Account)
– Polymorphic queries are process intensive
• For queries against the superclass, Hibernate executes
o que es
aga s e
supe c ass, be
a e e ecu es
multiple queries
– SELECT * FROM CHECKING_ACCOUNT WHERE
ACCOUNT_OWNER_ID=?
– SELECT * FROM SAVINGS_ACCOUNT WHERE
ACCOUNT_OWNER_ID=?
– Database schema evolution more
complexp
• Need to add the same column to multiple tables
• Integrity constraints might have to span multiple tables
Table-per-concrete class
Database
– One database table per concrete class
Hibernate Mapping
– Single mapping
fileg pp g f
• Based on superclass
• Includes
‘union-subclass’ definitions for inherited classes
Table-per-concrete class
• Advantages
Shared mapping of common elements
• Shared database id
– Not a lot of
nullable columns (good for integrity
)Not a lot of
nullable columns (good for integrity)
– Queries against individual types are fast and simple
–
Less SQL statements generated with use of ‘Union’ for
polymorphic queries
• Disadvantages
– Still have difficulty with relationships
• Foreign keying to two tables not possible
– Database schema evolution still more
complexp
• Need to add the same column to multiple tables
• Integrity constraints might have to span multiple tables
Table-per-class-hierarchy
Database
– One database table for all subclasses
–
Denormalized table has columns for all attributes
Hibernate Mapping
– Single mapping file still based on superclass
– Includes
‘subclass’ definitions for inherited
classes
– Use ‘discriminator’ column/field to identity
concrete type
Table-per-class-hierarchy
• Advantages
– Simple
– Fast reads/writes, even across types
• Disadvantages
– Lots of
nullable columns
•
Possible data integrity concern
–
Denormalized table
generally considered bad
database design
Table-per-subclass
Database
– One database table for the superclass AND
one per subclass
• Shared columns in superclass table
• Subclass tables have their object-specific
columns
Hibernate Mapping File• Hibernate Mapping File
– Single mapping file based on the superclass
Includes
‘joined subclass’ definitions for
– Includes joined-subclass definitions for
inherited classes
Table-per-subclass
• Advantages
– Normalized schema
• Schema evolution and integrity are straight
fdforward
– Reduced number of SQL statements produced
• Hibernate uses inner joins for subclass queries• Hibernate uses inner joins for subclass queries,
outer joins for polymorphic ones
• Disadvantages
– Can have
poor performance for complex systems
• Requires many joins or sequential reads for queries
When to use Which
• Leave implicit polymorphism for queries against interfaces (based on behavior not
differentinterfaces (based on behavior, not different
attributes
)
• If you rarely require polymorphic queries, lean towards table-per-concrete-class.
• If polymorphic behavior is required, AND subclasses have only a few distinct properties, try table-per-
l hi
hclass-hierarchy
• If polymorphic AND many distinct properties, look
atIf polymorphic AND many distinct properties, look at table-per-subclass or table-per-concrete-class,
weighing the cost of joins versus unions
Summary
Components
are different from Entities
•
Enties have their own IDs
• Component are
dependant on Entities
the different methods of modeling inheritance relationships through Java/Database/Hibernate, and where each one is best
suited
Hibernate implicit polymorphism
• Table-per-concrete class
• Table-per-class-hierarchy
• Table-per-subclass
04-hibernate-
Component_and_Inheritance_Mapping
http://courses.coreservlets.com/Course-Materials/hibernate.html
Association
– Mapping relationships between two objects
– Example
• Account and
AccountOwner
• Collection• Collection
– Collection of values representing individual
pieces of data
– Example
• Map of holidays
• String array of months
Relationship Dimensions
Relationships between entities can
p
exist in multiple ways
– Multiplicity
• How many on each side of the
relationship?p
– Directionality
• From which side
(s) of the relationship
canFrom which side
(s) of the relationship can
you access the other?
Relationship Multiplicity
One-to-Many
A il Ath Tti– A single Account has many Transactions
– Reverse of a many-to-one relationship
• Many-to-Oney
– Multiple Transactions belong to a single account
– Reverse of a one-to-many relationship
One to One• One-to-One
– A single
AccountOwner has a single
HomeAddress
– A single
HomeAddress has a single
AccountOwnerg g
• Many-to-Many
– Multiple Accounts have multiple
AccountOwners
Oft li d
th h t t lti hi
– Often realized through two one-to-many relationships
• A single Account has multiple
AccountOwners
• A single
AccountOwner has multiple Accounts
Relationship Directionality
Unidirectional
Cl
bjf idfh– Can only traverse objects from one side of the
relationship
– Example: Account
: Transaction
• Given an Account object, can
obtain related
Transaction objects.
• Given a Transaction object, cannot
obtain related
Account object.
• Bidirectional
– Can traverse objects from both sides of the
relationshipCan traverse objects from both sides of the relationship
– Example: Account
: Transaction
• Given an Account object, can
obtain related
Transaction
objectsTransaction objects.
• Given a Transaction object, can
obtain related
Account object
Java vs. Database
Objects are inherently directional
• An object has a reference/pointer to another
object
– Transition by walking a networked graph of
object references
Database
– Relations are not inherently directional
A
t bl bit il
j i it
l ith• A table can arbitrarily join its columns with
columns of other tables
(not just those keyed
to)
– Transition by joining tables together through
joins/foreign keys
Relationships in Database
Denormalized table
• Record repeated in same table each time capturing• Record repeated in same table, each time capturing
different relationship data.
– Foreign keys
• Follow identifiers to related records on other tables
– Join tables
• Tables specifically setup to maintain a relationship
pyp p
between two identities (usually for M
:M)
–
Ad hoc joins in a query
• Arbitrary joins between columns relating data
Relationships in Java
For ‘Many’ side, Collections API
– Set
• No duplication allowed• No duplication allowed
• Objects organized with or without order
– Map
• Duplicate values allowed using different
keysDuplicate values allowed, using different keys
• Can
be organized with or without order
– List
• Duplication
allowedDuplication allowed
• Objects expected to
be organized in an order
– Arrays
• Duplication allowed
• Objects expected to
be organized in an order
• Strongly typed to
particular object
type, and lacks ability to resize
Relationships in Database
Denormalized Table
P
– Pros
•
Very fast
• Easy to query against
– Cons
• Contains redundant data
• Requires many
nullable columns
Foreign Keys
P
– Pros
• Reduce redundancy
• Better modeling of data
– Cons
• Slower than
denormalized table
• Slightly more complicated to query against
Join Tables
Pros
– Pros
• Built on foreign key model, enables
many:many relationships
– Cons
• Slower yet and even more complex querying
Joins
– Pros
• Allows for any
possible query a user can think of without having
to
predefine the requirements in the schema design
C
– Cons
• No model enforcement
– Can join ‘age’ and ‘office floor’ columns
– but does it make sense?
• Can
be complicated/confusing to write; results may not appear
as desired
Java-to-Database Through Hibernate
Association & Collection mapping tags practically identical
Hibernate Collection Types
-<set>
• Unordered/Ordered, requiring value column
– <map>
• Unordered/Ordered, requiring key and value
lcolumns
– <list>
Ordered requiring an index column on the• Ordered, requiring an index column on the
referenced object table
– <array>
• Map to Java Type and Primitive Arrays• Map to Java Type and Primitive Arrays
• Ordered, requiring an index column on the
referenced object table
– <bag>
• No direct implementation available in Java
• Unordered/ordered collection allowing
duplicatesUnordered/ordered collection allowing duplicates
• Realized through Collection/List
• Requires value column
idb– <
idbag>
• Used for many-to-many relationships
• Same as Bag but with
additional identifierSame as Bag, but with
additional identifier
column used for surrogate keys
• Requires an ID Generator just like Entity classes
03-hibernate-
Association_and_Collection_Mapping
http://courses.coreservlets.com/Course-Materials/hibernate.html
- Building a Hibernate Application
Define the domain model
2. Setup your Hibernate configuration
– hibernate.cfg.xml
3 C
t th d i
bj t i fil3. Create the domain object mapping files
– <
domain_object>
.hbm.xml
4 Make Hibernate aware of the mapping files4. Make Hibernate aware of the mapping files
– Update the hibernate.cfg.xml with
list of mapping files
5 Implement a HibernateUtil class5. Implement a HibernateUtil class
– Usually taken from the Hibernate documentation
6. Write your code
02-hibernate-
A_Simple_Example
http://courses.coreservlets.com/Course-Materials/hibernate.html
Application is made up of layers or tiers
– Each layer encapsulates specific responsibilities
– Enables changes in one area with minimal impact to other
areas of the
applicationareas of the application
• Common tiers
– Presentation
• ‘View’ in model-view-controller
• Responsible for displaying data only. No business logic
Service
– Service
• Responsible for business logic
– Persistence
• Responsible for storing/retrieving data
01-hibernate-
Introduction_to_Hibernate
http://courses.coreservlets.com/Course-Materials/hibernate.html
The object-relational impedance mismatch is a set of conceptual and technical difficulties that
are often encountered when a relational database management system (RDBMS) is being used by a program written in an object-oriented programming language or style; particularly when objects or class definitions
are mapped in a straightforward way to database tables or relational schema.
Mismatches
Object-oriented concepts
Encapsulation
Object-oriented programs
are designed with techniques that result in encapsulated objects
whose representation is hidden. Mapping such private object representation to database tables makes such databases fragile according to OOP (object-oriented programming) philosophy, since there are significantly fewer constraints for design of encapsulated private representation of objects compared to a database's use of public data, which must be amenable to upgrade, inspection and queries
Accessibility
In relational thinking, "private" versus "public" access is relative to need rather than being an absolute characteristic of the data's state, as in the OO model. The relational and OO models often have conflicts over relativity versus absolutism of classifications and characteristics.
Interface, class, inheritance and polymorphism
essential OOP concepts for classes of objects, inheritance and polymorphism
are not supported by relational database systems
Mapping to relational concepts
Data type differences
A major mismatch between existing relational and OO languages is the type system differences. The relational model strictly prohibits by-reference attributes (or pointers), whereas OO languages embrace and expect by-reference behavior. Scalar types and their operator semantics are also
very often subtly to
vastly different between the models, causing problems in mapping.
For example, most SQL systems support string types with varying collations and constrained maximum lengths (open-ended text types
tend to hinder performance), while most OO languages consider collation only as an argument to sort routines and strings
are intrinsically sized to
available memory. A more subtle, but related example is that SQL systems often ignore trailing white space in a string for
the purposes of comparison, whereas OO string libraries do not. It is typically not possible to construct new data types as a matter of constraining the
possible values of other primitive types in an OO language.
Structural and integrity differences
Another mismatch has to do with the differences in the structural and integrity aspects of the contrasted models. In OO languages, objects can
be composed of other objects—often to a high degree—or specialize from a more general definition. This may make the mapping to relational schemas less straightforward. This is because
relational data tends to be represented in a named set of global,
unnested relation variables
Manipulative differences
The relational model has an intrinsic, relatively small and well defined set of primitive operators for usage in the query and manipulation of data, whereas OO languages
generally handle query and manipulation through custom-built or lower-
level, case and physical access path specific imperative operations
Transactional differences
relational database transactions, as the smallest unit of work performed by databases, are much larger than any operations performed by classes in OO languages
Solving impedance mismatch
Minimization
There have been
some attempts at building object-oriented database management systems (OODBMS) that would avoid the impedance mismatch problem. They have been less successful in practice than relational databases however, partly
due to the limitations of OO principles as a basis for a data model
Alternative architectures
The rise of XML databases and XML client structures has motivated other alternative architectures to get around the impedance mismatch challenges. These architectures use XML technology in the client (such as
XForms) and native XML databases on the server that use the
XQuery language for data selection. This allows a single data model and a single data selection language (
XPath) to be used in the client, in the rules engines and on the persistence serve
http://en.wikipedia.org/wiki/Objecwt-relational_impedance_mismatch
- Inheritance is one of the most visible facets of Object-relational mismatch. Object oriented systems can model both “is a” and “has a” relationship. Relational model supports only “has a” relationship between two entities. Hibernate can help you map such Objects with relational tables. But you need to choose certain mapping strategy based on your needs.
1. Map one table per concrete class. Your mapping ignores the inheritance relationship and maps one table per concrete class. (implicit polymorphism)
2. Map one table per concrete class with union-subclass mapping. You still have one table per concrete class, but you use a “union-subclass” clause in your mapping. This helps mitigate
some of the problems we will face in the previous strategy.
3. Map one table per class hierarchy. Here your table will have a row for all the fields in the full class hierarchy. You will have a lot of potential null values and you will have a discriminator column to hold type information.
4. Map one table per subclass. Here you convert the
object oriented “is a” relationship into a relational “has a” relationship using foreign keys.
http://simsonlive.
wordpress.com/2008/03/09/how-inheritance-works-in-hibernate/
- inheritance models in Hibernate and describes how they work like vertical inheritance and horizontal
1. Table per concrete class with unions
2. Table per class hierarchy
(Single Table Strategy)
3. Table per subclass
(omitting implicit polymorphism which is table per concrete class)
Example:
Let us take the simple example of 3 java classes.
Class
TwoWheelerVehicle and
FourWheelerVehicle are inherited from Vehicle Abstract class
1. Table per concrete class with unions
In this case there will be 2 tables
Tables:
TwoWheelerVehicle,
FourWheelerVehicle[all common attributes will be duplicated]
2. Table per class hierarchy
Single Table can be mapped to a class hierarchy
There will be only one table in
database called 'Vehicle' that will represent all the attributes required for all 3 classes.
But it needs some discriminating column to differentiate between
TwoWheelerVehicle and
FourWheelerVehicle;
3. Table per subclass
In this case there will be 3 tables represent
TwoWheelerVehicle , FourWheelerVehicle and Vehicle
There are three
possible strategies to use.
Single Table Strategy,
With Table Per Class Strategy,
With Joined Strategy
http://www.dineshonjava.com/p/implementing-inheritance-in-hibernate.html#
.UfoIF11jG70
- There can be three kinds of inheritance mapping in hibernate
1. Table per concrete class with unions
2. Table per class hierarchy
3. Table per subclass
Example:
We can take an example of three Java classes like Vehicle, which is an abstract class and two subclasses of Vehicle as Car and
UtilityVan.
1. Table per concrete class with unions
In this
scenario there will be 2 tables
Tables: Car,
UtilityVan, here in this case all common attributes will
be duplicated.
2. Table per class hierarchy
Single Table can be mapped to a class hierarchy
There will be only one table in
database named 'Vehicle' which will represent all attributes required for all three classes.
Here it
is be taken care of that discriminating columns to differentiate between Car and
UtilityVan
3. Table per subclass
Simply there will be three tables representing Vehicle, Car and
UtilityVan
http://www.interviewjava.com/2007/10/explain-different-inheritance-mapping.html
- Hibernate Object Lifecycle
hibernate considers objects it can
tl bi
ffmanage to always be in one of four
states
Transient
– Transient
– Persistent
– Removed
– Detached
Transient State
All objects start off in the transient
ttstate
– Account account = new Account
();
• account is a transient object
Hibernate is not aware of the object
instance
Persistent State
Hibernate
is aware of, and managing, the object
This is the only state where objects
are saved to the
database
Persistent State
Session session =
SessionFactory getCurrentSession()
;SessionFactory.getCurrentSession();
// ‘transient’ state
– Hibernate is NOT aware that it exists
Account account = new Account
()
;Account account new Account
();
// transition to the ‘persistent’ state. Hibernate is NOW
// aware of the object and will save it to the
databasej
session
.saveOrUpdate(account);
// modification of the object will automatically
bejy
// saved because the object is in the ‘persistent’ state
account
.setBalance(500);
// it
th t ti// commit the transaction
session
.getTransaction().commit
();
Removed State
A previously persistent object that is
deleted from the database
– session
.delete
(account);
Detached State
A persistent object that is still referenced
after closure of the active sessionafter closure of the active session
– session.close() changes object’s state from persisted to
detached
Saving Changes to the Database
Session methods do NOT save changes to
the databasethe database
– save();
– update();p ();
– delete();
These methods actually SCHEDULE
changes to be made to the databasechanges to be made to the database
Hibernate collects SQL statements to be
issued
Statements are later flushed to the database
– Once submitted, modifications to the database are not
permanent until a commit is issuedpermanent until a commit is issued
• session.getTransaction().commit();
Flushing the Context
Submits the stored SQL statements to
th d t bthe database
• Occurs when:
– transaction.commit() is called
– session.flush() is called explicitly
Before a query is executed– Before a query is executed
• If stored statements would affect the results of the quer
Cascading
Hibernate represents domain object
• Propagate the persistence action not only to
the object submitted, but also to any objects
associated with that object
05-hibernate-Object_Lifecycle_Persistence_and_Session_Management
http://courses.coreservlets.com/Course-Materials/hibernate.html
Represents a single unit-of-work
All or nothing – either all of the actions get committed or the entire effort fails
Other resources can also participate in• Other resources can also participate in
transactions
– Java Messaging Service (JMS)gg ( )
• Roll back a message if something fails
– Legacy Systems
– Anything that leverages JTS (Java Transaction Service)
• TransactionManager Interface
- Walked through Query by Criteria (QBC) and Query by
Example (QBE) querying methods, and learned about the
core Hibernate classes involved in querying
• Criteria
• Criterion
• Restrictions
• Property
• Order
• Projections
07-hibernate-Querying_QBC_and_QBE
http://courses.coreservlets.com/Course-Materials/hibernate.html
- three ways of handling inheritance
– Single table per class hierarchy
• InheritanceType.SINGLE_TABLE
Tbl i l– Table per concrete entity class
• InheritanceType.TABLE_PER_CLASS
“join” strategy where fields or properties that are– join strategy, where fields or properties that are
specific to a subclass are mapped to a different
table than the fields or properties that are pp
common to the parent class
• InheritanceType.JOINED
MiiHib t’Iliit• Missing Hibernate’s Implicit
Polymorphism
10-hibernate-JPA.pdf
http://courses.coreservlets.com/Course-Materials/hibernate.html
- What is Connection Pooling? In many of our applications we need to connect to the database for various purposes such as inset, update , delete and retrieve the data from the DB. For each of these activities the application needs to connect to the database which is expensive in terms of resource as well as time. Instead of connecting to the database each time a user makes a request which requires database operation an application should use a pool of connections. Then each application thread that needs to access the database can request a connection from the pool and returns the same to the pool when all the database operations have been executed. This mechanism is called connection pooling.
Hibernate supports various types of connection pooling mechanisms such as C3P0, Apache DBCP, Proxool. C3P0 is an Open source connection pool that comes bundled with hibernate.
http://www.mindfiresolutions.com/How-to-configure-C3P0-connection-pooling-in-Hibernate-1649.php