Q:

How to correctly translate UML Association, Aggregation and Composition to a Hibernate mapping?

There is a number of questions about the differences between UML Association, Aggregation and Composition out there and many many answers, some practical and some phylosofical. Here I'm asking we talk about practical differences!
In some answers I found:

Reference languages like Java can't really implement Compositions, since the instance life cycle is controlled by the garbage collection;
Associations and Aggregations have no practical difference, so we should just drop Aggregations and work with Associations and Compositions; still, those two kinds of relationship exist;
Those three concepts make sense only in programming languages like C++, that have an instance-based (and not reference-based) object model;
Aggregation allows many owners, Composition does not; a few sources advogate different.

However, no answer I've found so far approached those concepts in the context of persistent objects. No examples were given considering persistence, even though it is a very usual development condition.
When an object is persisted in a database system we do have a life cycle model free from garbage collection since an instance (or table row if you will) deletion happens in response to a deliberated act from some part of the software implementing some product requirement. 
The difference between Association and Composition is indeed very clear, they will produce different annotations in code. A very noticiable difference is that with a Composition we will have cascade delete enabled, so when the Owner id deleted, the Items are also deleted. In Association there is no cascade delete enabled.
However, what differences will we find when annotating Association and Aggregation, specially, when in both cases we have a cardinality bigger than 1?

A:

Aggregations and compositions are specialized associations that carry some additional semantic (i.e. meaning):  

UML doesn't specify the semantic of aggregation ("Precise semantics of shared aggregation varies by application area and modeler", page 110), except that the aggregated objects may be subject to shared ownership. In practice, aggregation is frequently used for showing a part-whole relationship.   
UML specifies composition as an exclusive ownership with the control of the lifecycle. The composed objects do not survive their owner. 

When persisting objects with an ORM such as Hibernate,  the associations, aggregations and compositions can therefore be implemented in exactly the same way.  The most common practices are: 

identity fields are used as primary key to uniquely identify an object of a certain class;
foreign key mapping is used to implement one-to-many associations;  
association tables are required to implement many-to-many associations. 

The difference between composition and aggregation or simple associations lie in the behavior outside the table (i.e.  deleting composed objects when the composite is deleted).   
For composition, an older DBMS practice is to use a compound key: a first member of the compound key is a foreign key corresponding to the owning object,  and as a second member to have a sequential number that is unique but only for the corresponding foreign key.  Sounds complex but it's simple: imagine you have a PurchaseOrder table with a primary key a POid.  Each PurchaseOrderLine would then have an compound key, made of the POid and a line number.  I'm not an hibernate specialist,  but here a blog post that explains how it works.  

