You can define a composite primary key through several syntaxes:

As you can see the last case is far from obvious. It has been inherited from the dark ages of EJB 2 for backward compatibilities and we recommend you not to use it (for simplicity sake).

Let's explore all three cases using examples.

Hibernate can generate and populate identifier values for you automatically. This is the recommended approach over "business" or "natural" id (especially composite ids).

Hibernate offers various generation strategies, let's explore the most common ones first that happens to be standardized by JPA:

Starting with release 3.2.3, there are 2 new generators which represent a re-thinking of 2 different aspects of identifier generation. The first aspect is database portability; the second is optimization Optimization means that you do not have to query the database for every request for a new identifier value. These two new generators are intended to take the place of some of the named generators described above, starting in 3.3.x. However, they are included in the current releases and can be referenced by FQN.

The first of these new generators is org.hibernate.id.enhanced.SequenceStyleGenerator which is intended, firstly, as a replacement for the sequence generator and, secondly, as a better portability generator than native. This is because native generally chooses between identity and sequence which have largely different semantics that can cause subtle issues in applications eyeing portability. org.hibernate.id.enhanced.SequenceStyleGenerator, however, achieves portability in a different manner. It chooses between a table or a sequence in the database to store its incrementing values, depending on the capabilities of the dialect being used. The difference between this and native is that table-based and sequence-based storage have the same exact semantic. In fact, sequences are exactly what Hibernate tries to emulate with its table-based generators. This generator has a number of configuration parameters:

Hibernate supports the automatic generation of some of the identifier properties. Simply use the @GeneratedValue annotation on one or several id properties.

@Entity

public class CustomerInventory implements Serializable {

  @Id

  @TableGenerator(name = "inventory",

    table = "U_SEQUENCES",

    pkColumnName = "S_ID",

    valueColumnName = "S_NEXTNUM",

    pkColumnValue = "inventory",

    allocationSize = 1000)

  @GeneratedValue(strategy = GenerationType.TABLE, generator = "inventory")

  Integer id;



  @Id @ManyToOne(cascade = CascadeType.MERGE)

  Customer customer;

}


@Entity

public class Customer implements Serializable {

   @Id

   private int id;

}

You can also generate properties inside an @EmbeddedId class.

You can add optimistic locking capability to an entity using the @Version annotation:

@Entity

public class Flight implements Serializable {

...

    @Version

    @Column(name="OPTLOCK")

    public Integer getVersion() { ... }

}           

The version property will be mapped to the OPTLOCK column, and the entity manager will use it to detect conflicting updates (preventing lost updates you might otherwise see with the last-commit-wins strategy).

The version column may be a numeric. Hibernate supports any kind of type provided that you define and implement the appropriate UserVersionType.

The application must not alter the version number set up by Hibernate in any way. To artificially increase the version number, check in Hibernate Entity Manager's reference documentation LockModeType.OPTIMISTIC_FORCE_INCREMENT or LockModeType.PESSIMISTIC_FORCE_INCREMENT.

If the version number is generated by the database (via a trigger for example), make sure to use @org.hibernate.annotations.Generated(GenerationTime.ALWAYS).

To declare a version property in hbm.xml, use:

<version
        column="version_column"                            
        name="propertyName"                                
        type="typename"                                    
        access="field|property|ClassName"                  
        unsaved-value="null|negative|undefined"            
        generated="never|always"                           
        insert="true|false"                                
        node="element-name|@attribute-name|element/@attribute|."
/>

Alternatively, you can use a timestamp. Timestamps are a less safe implementation of optimistic locking. However, sometimes an application might use the timestamps in other ways as well.

Simply mark a property of type Date or Calendar as @Version.

@Entity

public class Flight implements Serializable {

...

    @Version

    public Date getLastUpdate() { ... }

}           

When using timestamp versioning you can tell Hibernate where to retrieve the timestamp value from - database or JVM - by optionally adding the @org.hibernate.annotations.Source annotation to the property. Possible values for the value attribute of the annotation are org.hibernate.annotations.SourceType.VM and org.hibernate.annotations.SourceType.DB. The default is SourceType.DB which is also used in case there is no @Source annotation at all.

Like in the case of version numbers, the timestamp can also be generated by the database instead of Hibernate. To do that, use @org.hibernate.annotations.Generated(GenerationTime.ALWAYS).

In hbm.xml, use the <timestamp> element:

<timestamp
        column="timestamp_column"                          
        name="propertyName"                                
        access="field|property|ClassName"                  
        unsaved-value="null|undefined"                     
        source="vm|db"                                     
        generated="never|always"                           
        node="element-name|@attribute-name|element/@attribute|."
/>

In the annotations world, every non static non transient property (field or method depending on the access type) of an entity is considered persistent, unless you annotate it as @Transient. Not having an annotation for your property is equivalent to the appropriate @Basic annotation.

The @Basic annotation allows you to declare the fetching strategy for a property. If set to LAZY, specifies that this property should be fetched lazily when the instance variable is first accessed. It requires build-time bytecode instrumentation, if your classes are not instrumented, property level lazy loading is silently ignored. The default is EAGER. You can also mark a property as not optional thanks to the @Basic.optional attribute. This will ensure that the underlying column are not nullable (if possible). Note that a better approach is to use the @NotNull annotation of the Bean Validation specification.

Let's look at a few examples:

public transient int counter; //transient property


private String firstname; //persistent property


@Transient

String getLengthInMeter() { ... } //transient property


String getName() {... } // persistent property


@Basic

int getLength() { ... } // persistent property


@Basic(fetch = FetchType.LAZY)

String getDetailedComment() { ... } // persistent property


@Temporal(TemporalType.TIME)

java.util.Date getDepartureTime() { ... } // persistent property           


@Enumerated(EnumType.STRING)

Starred getNote() { ... } //enum persisted as String in database

counter, a transient field, and lengthInMeter, a method annotated as @Transient, and will be ignored by the Hibernate. name, length, and firstname properties are mapped persistent and eagerly fetched (the default for simple properties). The detailedComment property value will be lazily fetched from the database once a lazy property of the entity is accessed for the first time. Usually you don't need to lazy simple properties (not to be confused with lazy association fetching). The recommended alternative is to use the projection capability of JP-QL (Java Persistence Query Language) or Criteria queries.

JPA support property mapping of all basic types supported by Hibernate (all basic Java types , their respective wrappers and serializable classes). Hibernate Annotations supports out of the box enum type mapping either into a ordinal column (saving the enum ordinal) or a string based column (saving the enum string representation): the persistence representation, defaulted to ordinal, can be overridden through the @Enumerated annotation as shown in the note property example.

In plain Java APIs, the temporal precision of time is not defined. When dealing with temporal data you might want to describe the expected precision in database. Temporal data can have DATE, TIME, or TIMESTAMP precision (ie the actual date, only the time, or both). Use the @Temporal annotation to fine tune that.

@Lob indicates that the property should be persisted in a Blob or a Clob depending on the property type: java.sql.Clob, Character[], char[] and java.lang.String will be persisted in a Clob. java.sql.Blob, Byte[], byte[] and Serializable type will be persisted in a Blob.

@Lob

public String getFullText() {

    return fullText;

}


@Lob

public byte[] getFullCode() {

    return fullCode;

}

If the property type implements java.io.Serializable and is not a basic type, and if the property is not annotated with @Lob, then the Hibernate serializable type is used.

The <property> element declares a persistent JavaBean style property of the class.

<property
        name="propertyName"                                
        column="column_name"                               
        type="typename"                                    
        update="true|false"                                
        insert="true|false"                                
        formula="arbitrary SQL expression"                 
        access="field|property|ClassName"                  
        lazy="true|false"                                  
        unique="true|false"                                
        not-null="true|false"                              
        optimistic-lock="true|false"                       
        generated="never|insert|always"                    
        node="element-name|@attribute-name|element/@attribute|."
        index="index_name"
        unique_key="unique_key_id"
        length="L"
        precision="P"
        scale="S"
/>

typename could be:

If you do not specify a type, Hibernate will use reflection upon the named property and guess the correct Hibernate type. Hibernate will attempt to interpret the name of the return class of the property getter using, in order, rules 2, 3, and 4. In certain cases you will need the type attribute. For example, to distinguish between Hibernate.DATE and Hibernate.TIMESTAMP, or to specify a custom type.

The access attribute allows you to control how Hibernate accesses the property at runtime. By default, Hibernate will call the property get/set pair. If you specify access="field", Hibernate will bypass the get/set pair and access the field directly using reflection. You can specify your own strategy for property access by naming a class that implements the interface org.hibernate.property.PropertyAccessor.

A powerful feature is derived properties. These properties are by definition read-only. The property value is computed at load time. You declare the computation as an SQL expression. This then translates to a SELECT clause subquery in the SQL query that loads an instance:

<property name="totalPrice"
    formula="( SELECT SUM (li.quantity*p.price) FROM LineItem li, Product p
                WHERE li.productId = p.productId
                AND li.customerId = customerId
                AND li.orderNumber = orderNumber )"/>

You can reference the entity table by not declaring an alias on a particular column. This would be customerId in the given example. You can also use the nested <formula> mapping element if you do not want to use the attribute.

With this approach the properties of all the subclasses in a given mapped class hierarchy are stored in a single table.

Each subclass declares its own persistent properties and subclasses. Version and id properties are assumed to be inherited from the root class. Each subclass in a hierarchy must define a unique discriminator value. If this is not specified, the fully qualified Java class name is used.

@Entity

@Inheritance(strategy=InheritanceType.SINGLE_TABLE)

@DiscriminatorColumn(

    name="planetype",

    discriminatorType=DiscriminatorType.STRING

)

@DiscriminatorValue("Plane")

public class Plane { ... }


@Entity

@DiscriminatorValue("A320")

public class A320 extends Plane { ... }          

In hbm.xml, for the table-per-class-hierarchy mapping strategy, the <subclass> declaration is used. For example:

<subclass
        name="ClassName"                                   
        discriminator-value="discriminator_value"          
        proxy="ProxyInterface"                             
        lazy="true|false"                                  
        dynamic-update="true|false"
        dynamic-insert="true|false"
        entity-name="EntityName"
        node="element-name"
        extends="SuperclassName">

        <property .... />
        .....
</subclass>

Each subclass can also be mapped to its own table. This is called the table-per-subclass mapping strategy. An inherited state is retrieved by joining with the table of the superclass. A discriminator column is not required for this mapping strategy. Each subclass must, however, declare a table column holding the object identifier. The primary key of this table is also a foreign key to the superclass table and described by the @PrimaryKeyJoinColumns or the <key> element.

@Entity @Table(name="CATS")

@Inheritance(strategy=InheritanceType.JOINED)

public class Cat implements Serializable { 

    @Id @GeneratedValue(generator="cat-uuid") 

    @GenericGenerator(name="cat-uuid", strategy="uuid")

    String getId() { return id; }


    ...

}


@Entity @Table(name="DOMESTIC_CATS")

@PrimaryKeyJoinColumn(name="CAT")

public class DomesticCat extends Cat { 

    public String getName() { return name; }

}            

In hbm.xml, use the <joined-subclass> element. For example:

<joined-subclass
        name="ClassName"                                   
        table="tablename"                                  
        proxy="ProxyInterface"                             
        lazy="true|false"                                  
        dynamic-update="true|false"
        dynamic-insert="true|false"
        schema="schema"
        catalog="catalog"
        extends="SuperclassName"
        persister="ClassName"
        subselect="SQL expression"
        entity-name="EntityName"
        node="element-name">

        <key .... >

        <property .... />
        .....
</joined-subclass>

Use the <key> element to declare the primary key / foreign key column. The mapping at the start of the chapter would then be re-written as:

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
        "-//Hibernate/Hibernate Mapping DTD//EN"
        "http://www.hibernate.org/dtd/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="eg">

        <class name="Cat" table="CATS">
                <id name="id" column="uid" type="long">
                        <generator class="hilo"/>
                </id>
                <property name="birthdate" type="date"/>
                <property name="color" not-null="true"/>
                <property name="sex" not-null="true"/>
                <property name="weight"/>
                <many-to-one name="mate"/>
                <set name="kittens">
                        <key column="MOTHER"/>
                        <one-to-many class="Cat"/>
                </set>
                <joined-subclass name="DomesticCat" table="DOMESTIC_CATS">
                    <key column="CAT"/>
                    <property name="name" type="string"/>
                </joined-subclass>
        </class>

        <class name="eg.Dog">
                <!-- mapping for Dog could go here -->
        </class>

</hibernate-mapping>

A third option is to map only the concrete classes of an inheritance hierarchy to tables. This is called the table-per-concrete-class strategy. Each table defines all persistent states of the class, including the inherited state. In Hibernate, it is not necessary to explicitly map such inheritance hierarchies. You can map each class as a separate entity root. However, if you wish use polymorphic associations (e.g. an association to the superclass of your hierarchy), you need to use the union subclass mapping.

@Entity

@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)

public class Flight implements Serializable { ... }            

Or in hbm.xml:

<union-subclass
        name="ClassName"                                   
        table="tablename"                                  
        proxy="ProxyInterface"                             
        lazy="true|false"                                  
        dynamic-update="true|false"
        dynamic-insert="true|false"
        schema="schema"
        catalog="catalog"
        extends="SuperclassName"
        abstract="true|false"
        persister="ClassName"
        subselect="SQL expression"
        entity-name="EntityName"
        node="element-name">

        <property .... />
        .....
</union-subclass>

No discriminator column or key column is required for this mapping strategy.

This is sometimes useful to share common properties through a technical or a business superclass without including it as a regular mapped entity (ie no specific table for this entity). For that purpose you can map them as @MappedSuperclass.

@MappedSuperclass

public class BaseEntity {

    @Basic

    @Temporal(TemporalType.TIMESTAMP)

    public Date getLastUpdate() { ... }

    public String getLastUpdater() { ... }

    ...

}


@Entity class Order extends BaseEntity {

    @Id public Integer getId() { ... }

    ...

}

In database, this hierarchy will be represented as an Order table having the id, lastUpdate and lastUpdater columns. The embedded superclass property mappings are copied into their entity subclasses. Remember that the embeddable superclass is not the root of the hierarchy though.

You can override columns defined in entity superclasses at the root entity level using the @AttributeOverride annotation.

@MappedSuperclass

public class FlyingObject implements Serializable {


    public int getAltitude() {

        return altitude;

    }


    @Transient

    public int getMetricAltitude() {

        return metricAltitude;

    }


    @ManyToOne

    public PropulsionType getPropulsion() {

        return metricAltitude;

    }

    ...

}


@Entity

@AttributeOverride( name="altitude", column = @Column(name="fld_altitude") )

@AssociationOverride( 

   name="propulsion", 

   joinColumns = @JoinColumn(name="fld_propulsion_fk") 

)

public class Plane extends FlyingObject {

    ...

}

The altitude property will be persisted in an fld_altitude column of table Plane and the propulsion association will be materialized in a fld_propulsion_fk foreign key column.

You can define @AttributeOverride(s) and @AssociationOverride(s) on @Entity classes, @MappedSuperclass classes and properties pointing to an @Embeddable object.

In hbm.xml, simply map the properties of the superclass in the <class> element of the entity that needs to inherit them.

While not recommended for a fresh schema, some legacy databases force you to map a single entity on several tables.

Using the @SecondaryTable or @SecondaryTables class level annotations. To express that a column is in a particular table, use the table parameter of @Column or @JoinColumn.

@Entity

@Table(name="MainCat")

@SecondaryTables({

    @SecondaryTable(name="Cat1", pkJoinColumns={

        @PrimaryKeyJoinColumn(name="cat_id", referencedColumnName="id")

    ),

    @SecondaryTable(name="Cat2", uniqueConstraints={@UniqueConstraint(columnNames={"storyPart2"})})

})

public class Cat implements Serializable {


    private Integer id;

    private String name;

    private String storyPart1;

    private String storyPart2;


    @Id @GeneratedValue

    public Integer getId() {

        return id;

    }


    public String getName() {

        return name;

    }

    

    @Column(table="Cat1")

    public String getStoryPart1() {

        return storyPart1;

    }


    @Column(table="Cat2")

    public String getStoryPart2() {

        return storyPart2;

    }

}

In this example, name will be in MainCat. storyPart1 will be in Cat1 and storyPart2 will be in Cat2. Cat1 will be joined to MainCat using the cat_id as a foreign key, and Cat2 using id (ie the same column name, the MainCat id column has). Plus a unique constraint on storyPart2 has been set.

There is also additional tuning accessible via the @org.hibernate.annotations.Table annotation:

Make sure to use the secondary table name in the appliesto property

@Entity

@Table(name="MainCat")

@SecondaryTable(name="Cat1")

@org.hibernate.annotations.Table(

   appliesTo="Cat1",

   fetch=FetchMode.SELECT,

   optional=true)

public class Cat implements Serializable {


    private Integer id;

    private String name;

    private String storyPart1;

    private String storyPart2;


    @Id @GeneratedValue

    public Integer getId() {

        return id;

    }


    public String getName() {

        return name;

    }

    

    @Column(table="Cat1")

    public String getStoryPart1() {

        return storyPart1;

    }


    @Column(table="Cat2")

    public String getStoryPart2() {

        return storyPart2;

    }

}

In hbm.xml, use the <join> element.

<join
        table="tablename"                                  
        schema="owner"                                     
        catalog="catalog"                                  
        fetch="join|select"                                
        inverse="true|false"                               
        optional="true|false">                             

        <key ... />

        <property ... />
        ...
</join>

For example, address information for a person can be mapped to a separate table while preserving value type semantics for all properties:

<class name="Person"
    table="PERSON">

    <id name="id" column="PERSON_ID">...</id>

    <join table="ADDRESS">
        <key column="ADDRESS_ID"/>
        <property name="address"/>
        <property name="zip"/>
        <property name="country"/>
    </join>
    ...

This feature is often only useful for legacy data models. We recommend fewer tables than classes and a fine-grained domain model. However, it is useful for switching between inheritance mapping strategies in a single hierarchy, as explained later.

An ordinary association to another persistent class is declared using a

and a foreign key in one table is referencing the primary key column(s) of the target table.

@Entity

public class Flight implements Serializable {

    @ManyToOne( cascade = {CascadeType.PERSIST, CascadeType.MERGE} )

    @JoinColumn(name="COMP_ID")

    public Company getCompany() {

        return company;

    }

    ...

}            

The @JoinColumn attribute is optional, the default value(s) is the concatenation of the name of the relationship in the owner side, _ (underscore), and the name of the primary key column in the owned side. In this example company_id because the property name is company and the column id of Company is id.

@Entity

public class Flight implements Serializable {

    @ManyToOne( cascade = {CascadeType.PERSIST, CascadeType.MERGE}, targetEntity=CompanyImpl.class )

    @JoinColumn(name="COMP_ID")

    public Company getCompany() {

        return company;

    }

    ...

}


public interface Company {

    ...

}

You can also map a to one association through an association table. This association table described by the @JoinTable annotation will contains a foreign key referencing back the entity table (through @JoinTable.joinColumns) and a a foreign key referencing the target entity table (through @JoinTable.inverseJoinColumns).

@Entity

public class Flight implements Serializable {

    @ManyToOne( cascade = {CascadeType.PERSIST, CascadeType.MERGE} )

    @JoinTable(name="Flight_Company",

        joinColumns = @JoinColumn(name="FLIGHT_ID"),

        inverseJoinColumns = @JoinColumn(name="COMP_ID")

    )

    public Company getCompany() {

        return company;

    }

    ...

}       

@Entity

public class Ticket implements Serializable {

    @ManyToOne

    @JoinColumnOrFormula(formula="(firstname + ' ' + lastname)")

    public Person getOwner() {

        return person;

    }

    ...

}       

You can mark an association as mandatory by using the optional=false attribute. We recommend to use Bean Validation's @NotNull annotation as a better alternative however. As a consequence, the foreign key column(s) will be marked as not nullable (if possible).

When Hibernate cannot resolve the association because the expected associated element is not in database (wrong id on the association column), an exception is raised. This might be inconvenient for legacy and badly maintained schemas. You can ask Hibernate to ignore such elements instead of raising an exception using the @NotFound annotation.

Sometimes you want to delegate to your database the deletion of cascade when a given entity is deleted. In this case Hibernate generates a cascade delete constraint at the database level.

Foreign key constraints, while generated by Hibernate, have a fairly unreadable name. You can override the constraint name using @ForeignKey.

Sometimes, you want to link one entity to another not by the target entity primary key but by a different unique key. You can achieve that by referencing the unique key column(s) in @JoinColumn.referenceColumnName.

@Entity
class Person {
   @Id Integer personNumber;
   String firstName;
   @Column(name="I")
   String initial;
   String lastName;
}

@Entity
class Home {
   @ManyToOne
   @JoinColumns({
      @JoinColumn(name="first_name", referencedColumnName="firstName"),
      @JoinColumn(name="init", referencedColumnName="I"),
      @JoinColumn(name="last_name", referencedColumnName="lastName"),
   })
   Person owner
}

This is not encouraged however and should be reserved to legacy mappings.

In hbm.xml, mapping an association is similar. The main difference is that a @OneToOne is mapped as <many-to-one unique="true"/>, let's dive into the subject.

<many-to-one
        name="propertyName"                                
        column="column_name"                               
        class="ClassName"                                  
        cascade="cascade_style"                            
        fetch="join|select"                                
        update="true|false"                                
        insert="true|false"                                
        property-ref="propertyNameFromAssociatedClass"     
        access="field|property|ClassName"                  
        unique="true|false"                                
        not-null="true|false"                              
        optimistic-lock="true|false"                       
        lazy="proxy|no-proxy|false"                        
        not-found="ignore|exception"                       
        entity-name="EntityName"                           
        formula="arbitrary SQL expression"                 
        node="element-name|@attribute-name|element/@attribute|."
        embed-xml="true|false"
        index="index_name"
        unique_key="unique_key_id"
        foreign-key="foreign_key_name"
/>

The second approach is to ensure an entity and its associated entity share the same primary key. In this case the primary key column is also a foreign key and there is no extra column. These associations are always one to one.

In hbm.xml, use the following mapping.

<one-to-one
        name="propertyName"                                
        class="ClassName"                                  
        cascade="cascade_style"                            
        constrained="true|false"                           
        fetch="join|select"                                
        property-ref="propertyNameFromAssociatedClass"     
        access="field|property|ClassName"                  
        formula="any SQL expression"                       
        lazy="proxy|no-proxy|false"                        
        entity-name="EntityName"                           
        node="element-name|@attribute-name|element/@attribute|."
        embed-xml="true|false"
        foreign-key="foreign_key_name"
/>

Primary key associations do not need an extra table column. If two rows are related by the association, then the two table rows share the same primary key value. To relate two objects by a primary key association, ensure that they are assigned the same identifier value.

For a primary key association, add the following mappings to Employee and Person respectively:

<one-to-one name="person" class="Person"/>

<one-to-one name="employee" class="Employee" constrained="true"/>

Ensure that the primary keys of the related rows in the PERSON and EMPLOYEE tables are equal. You use a special Hibernate identifier generation strategy called foreign:

<class name="person" table="PERSON">
    <id name="id" column="PERSON_ID">
        <generator class="foreign">
            <param name="property">employee</param>
        </generator>
    </id>
    ...
    <one-to-one name="employee"
        class="Employee"
        constrained="true"/>
</class>

A newly saved instance of Person is assigned the same primary key value as the Employee instance referred with the employee property of that Person.

All XML mappings should declare the doctype shown. The actual DTD can be found at the URL above, in the directory hibernate-x.x.x/src/org/hibernate , or in hibernate3.jar. Hibernate will always look for the DTD in its classpath first. If you experience lookups of the DTD using an Internet connection, check the DTD declaration against the contents of your classpath.

This element has several optional attributes. The schema and catalog attributes specify that tables referred to in this mapping belong to the named schema and/or catalog. If they are specified, tablenames will be qualified by the given schema and catalog names. If they are missing, tablenames will be unqualified. The default-cascade attribute specifies what cascade style should be assumed for properties and collections that do not specify a cascade attribute. By default, the auto-import attribute allows you to use unqualified class names in the query language.

<hibernate-mapping
         schema="schemaName"                               
         catalog="catalogName"                             
         default-cascade="cascade_style"                   
         default-access="field|property|ClassName"         
         default-lazy="true|false"                         
         auto-import="true|false"                          
         package="package.name"                            
 />

If you have two persistent classes with the same unqualified name, you should set auto-import="false". An exception will result if you attempt to assign two classes to the same "imported" name.

The hibernate-mapping element allows you to nest several persistent <class> mappings, as shown above. It is, however, good practice (and expected by some tools) to map only a single persistent class, or a single class hierarchy, in one mapping file and name it after the persistent superclass. For example, Cat.hbm.xml, Dog.hbm.xml, or if using inheritance, Animal.hbm.xml.