The notion of a component is re-used in several different contexts, for different purposes, throughout Hibernate. A component is a contained object that is persisted as a value type, not an entity reference. The term "component" refers to the object-oriented notion of composition (not to architecture-level components). For example, you might model a person like this: Now Name may be persisted as a component of Person. Notice that Name defines getter and setter methods for its persistent properties, but doesn't need to declare any interfaces or identifier properties. Our Hibernate mapping would look like: ]]> The person table would have the columns pid, birthday, initial, first and last. Like all value types, components do not support shared references. In other words, two persons could have the same name, but the two person objects would contain two independent name ojects, only "the same" by value. The null value semantics of a component are ad hoc. When reloading the containing object, Hibernate will assume that if all component columns are null, then the entire component is null. This should be okay for most purposes. The properties of a component may be of any Hibernate type (collections, many-to-one associations, other components, etc). Nested components should not be considered an exotic usage. Hibernate is intended to support a very fine-grained object model. The <component> element allows a <parent> subelement that maps a property of the component class as a reference back to the containing entity. ]]> Collections of components are supported (eg. an array of type Name). Declare your component collection by replacing the <element> tag with a <composite-element> tag. ]]> Note: if you define a Set of composite elements, it is very important to implement equals() and hashCode() correctly. Composite elements may contain components but not collections. If your composite element itself contains components, use the <nested-composite-element> tag. This is a pretty exotic case - a collection of components which themselves have components. By this stage you should be asking yourself if a one-to-many association is more appropriate. Try remodelling the composite element as an entity - but note that even though the Java model is the same, the relational model and persistence semantics are still slightly different. Please note that a composite element mapping doesn't support null-able properties if you're using a <set>. Hibernate has to use each columns value to identify a record when deleting objects (there is no separate primary key column in the composite element table), which is not possible with null values. You have to either use only not-null properties in a composite-element or choose a <list>, <map>, <bag> or <idbag>. A special case of a composite element is a composite element with a nested <many-to-one> element. A mapping like this allows you to map extra columns of a many-to-many association table to the composite element class. The following is a many-to-many association from Order to Item where purchaseDate, price and quantity are properties of the association: .... ]]> Of course, there can't be a reference to the purchae on the other side, for bidirectional association navigation. Remember that components are value types and don't allow shared references. A single Purchase can be in the set of an Order, but it can't be referenced by the Item at the same time. Even ternary (or quaternary, etc) associations are possible: .... ]]> Composite elements may appear in queries using the same syntax as associations to other entities. The <composite-map-key> element lets you map a component class as the key of a Map. Make sure you override hashCode() and equals() correctly on the component class. You may use a component as an identifier of an entity class. Your component class must satisfy certain requirements: It must implement java.io.Serializable. It must re-implement equals() and hashCode(), consistently with the database's notion of composite key equality. Note: in Hibernate3, the second requirement is not an absolutely hard requirement of Hibernate. But do it anyway. You can't use an IdentifierGenerator to generate composite keys. Instead the application must assign its own identifiers. Use the <composite-id> tag (with nested <key-property> elements) in place of the usual <id> declaration. For example, the OrderLine class has a primary key that depends upon the (composite) primary key of Order. .... ]]> Now, any foreign keys referencing the OrderLine table are also composite. You must declare this in your mappings for other classes. An association to OrderLine would be mapped like this: ]]> (Note that the <column> tag is an alternative to the column attribute everywhere.) A many-to-many association to OrderLine also uses the composite foreign key: ]]> The collection of OrderLines in Order would use: ]]> (The <one-to-many> element, as usual, declares no columns.) If OrderLine itself owns a collection, it also has a composite foreign key. .... .... ... ]]> You may even map a property of type Map: ]]> The semantics of a <dynamic-component> mapping are identical to <component>. The advantage of this kind of mapping is the ability to determine the actual properties of the bean at deployment time, just by editing the mapping document. Runtime manipulation of the mapping document is also possible, using a DOM parser. Even better, you can access (and change) Hibernate's configuration-time metamodel via the Configuration object.