例えば、インターフェイス Payment と、それを実装した CreditCardPayment、CashPayment、 ChequePayment があるとします。階層ごとのテーブルマッピングは 以下のようになります。

<class name="Payment" table="PAYMENT">
    <id name="id" type="long" column="PAYMENT_ID">
        <generator class="native"/>
    </id>
    <discriminator column="PAYMENT_TYPE" type="string"/>
    <property name="amount" column="AMOUNT"/>
    ...
    <subclass name="CreditCardPayment" discriminator-value="CREDIT">
        <property name="creditCardType" column="CCTYPE"/>
        ...
    </subclass>
    <subclass name="CashPayment" discriminator-value="CASH">
        ...
    </subclass>
    <subclass name="ChequePayment" discriminator-value="CHEQUE">
        ...
    </subclass>
</class>

ちょうど一つのテーブルが必要です。 このマッピング戦略には一つ大きな制限があります。 CCTYPE のような、サブクラスで宣言されたカラムは NOT NULL 制約を持てません。

table-per-subclass マッピングは以下のようになります。

<class name="Payment" table="PAYMENT">
    <id name="id" type="long" column="PAYMENT_ID">
        <generator class="native"/>
    </id>
    <property name="amount" column="AMOUNT"/>
    ...
    <joined-subclass name="CreditCardPayment" table="CREDIT_PAYMENT">
        <key column="PAYMENT_ID"/>
        <property name="creditCardType" column="CCTYPE"/>
        ...
    </joined-subclass>
    <joined-subclass name="CashPayment" table="CASH_PAYMENT">
        <key column="PAYMENT_ID"/>
        ...
    </joined-subclass>
    <joined-subclass name="ChequePayment" table="CHEQUE_PAYMENT">
        <key column="PAYMENT_ID"/>
        ...
    </joined-subclass>
</class>

このマッピングには4つのテーブルが必要です。3つのサブクラステーブルは スーパークラステーブルとの関連を示す主キーを持っています （実際、関係モデル上は一対一関連です）。

Hibernateの table-per-subclass 実装は、discriminatorカラムを必要としないことを覚えておいてください。 Hibernate以外のO/Rマッパーは、table-per-subclass に異なる実装を用います。 それは、スーパークラスのテーブルにタイプdiscriminatorカラムを必要とします。 このアプローチは実装が困難になりますが、関係の視点から見ると、より正確なものです。 table-per-subclass 戦略でdiscriminatorカラムを使いたければ、 <subclass> と <join> を以下のように組み合わせて使ってください。

<class name="Payment" table="PAYMENT">
    <id name="id" type="long" column="PAYMENT_ID">
        <generator class="native"/>
    </id>
    <discriminator column="PAYMENT_TYPE" type="string"/>
    <property name="amount" column="AMOUNT"/>
    ...
    <subclass name="CreditCardPayment" discriminator-value="CREDIT">
        <join table="CREDIT_PAYMENT">
            <key column="PAYMENT_ID"/>
            <property name="creditCardType" column="CCTYPE"/>
            ...
        </join>
    </subclass>
    <subclass name="CashPayment" discriminator-value="CASH">
        <join table="CASH_PAYMENT">
            <key column="PAYMENT_ID"/>
            ...
        </join>
    </subclass>
    <subclass name="ChequePayment" discriminator-value="CHEQUE">
        <join table="CHEQUE_PAYMENT" fetch="select">
            <key column="PAYMENT_ID"/>
            ...
        </join>
    </subclass>
</class>

オプションの fetch="select" 宣言は、 スーパークラスのクエリ実行時に外部結合を使って、 サブクラスの ChequePayment データを取得しないように指定するためのものです。

このアプローチを使用すると、table-per-hierarchy と table-per-subclass 戦略を 組み合わせる事も可能です。

<class name="Payment" table="PAYMENT">
    <id name="id" type="long" column="PAYMENT_ID">
        <generator class="native"/>
    </id>
    <discriminator column="PAYMENT_TYPE" type="string"/>
    <property name="amount" column="AMOUNT"/>
    ...
    <subclass name="CreditCardPayment" discriminator-value="CREDIT">
        <join table="CREDIT_PAYMENT">
            <property name="creditCardType" column="CCTYPE"/>
            ...
        </join>
    </subclass>
    <subclass name="CashPayment" discriminator-value="CASH">
        ...
    </subclass>
    <subclass name="ChequePayment" discriminator-value="CHEQUE">
        ...
    </subclass>
</class>

いずれのマッピング戦略であっても、ルートである Payment クラスへの ポリモーフィックな関連は <many-to-one> を使ってマッピングします。

<many-to-one name="payment" column="PAYMENT_ID" class="Payment"/>

table-per-concrete-class 戦略のマッピングに対するアプローチは、2つあります。 1つ目は <union-subclass> を利用する方法です。

<class name="Payment">
    <id name="id" type="long" column="PAYMENT_ID">
        <generator class="sequence"/>
    </id>
    <property name="amount" column="AMOUNT"/>
    ...
    <union-subclass name="CreditCardPayment" table="CREDIT_PAYMENT">
        <property name="creditCardType" column="CCTYPE"/>
        ...
    </union-subclass>
    <union-subclass name="CashPayment" table="CASH_PAYMENT">
        ...
    </union-subclass>
    <union-subclass name="ChequePayment" table="CHEQUE_PAYMENT">
        ...
    </union-subclass>
</class>

サブクラスごとに3つのテーブルが必要です。それぞれのテーブルは、継承プロパティを含んだ、 クラスの全てのプロパティに対するカラムを定義します。

このアプローチには制限があります。 それは、プロパティがスーパークラスにマッピングされていた場合、 全てのサブクラスにおいてカラム名が同じでなければならないというものです。 （Hibernateの今後のリリースで緩和されるかもしれません）。 <union-subclass> を使った table-per-concrete-class 戦略では識別子生成戦略を使用できません。 主キーを生成するためのシードは、全ての union subclass の階層内で共有する必要があるからです。

もしスーパークラスが抽象クラスなら、abstract="true"とマッピングします。 もちろん、スーパークラスが抽象クラスでないなら、スーパークラスのインスタンスを 保持するためのテーブルの追加が必要となります(上の例でのデフォルトは PAYMENT )。

もう一つのアプローチは暗黙的ポリモーフィズムの使用です。

<class name="CreditCardPayment" table="CREDIT_PAYMENT">
    <id name="id" type="long" column="CREDIT_PAYMENT_ID">
        <generator class="native"/>
    </id>
    <property name="amount" column="CREDIT_AMOUNT"/>
    ...
</class>

<class name="CashPayment" table="CASH_PAYMENT">
    <id name="id" type="long" column="CASH_PAYMENT_ID">
        <generator class="native"/>
    </id>
    <property name="amount" column="CASH_AMOUNT"/>
    ...
</class>

<class name="ChequePayment" table="CHEQUE_PAYMENT">
    <id name="id" type="long" column="CHEQUE_PAYMENT_ID">
        <generator class="native"/>
    </id>
    <property name="amount" column="CHEQUE_AMOUNT"/>
    ...
</class>

Payment インターフェイスがどこにも明示的に示されていないことに注意してください。 そして、Payment プロパティがそれぞれのサブクラスにマッピングされていることにも注意してください。 もし重複を避けたいのであれば、XMLエンティティの利用を考えてください。 （例： DOCTYPE 宣言における [ <!ENTITY allproperties SYSTEM "allproperties.xml"> ] と、マッピングにおける &allproperties;）

このアプローチの欠点は、Hibernateがポリモーフィックなクエリの実行時にSQL UNION を生成しない点です。

このマッピング戦略に対しては、Payment へのポリモーフィックな関連は 通常、<any> を使ってマッピングされます。

<any name="payment" meta-type="string" id-type="long">
    <meta-value value="CREDIT" class="CreditCardPayment"/>
    <meta-value value="CASH" class="CashPayment"/>
    <meta-value value="CHEQUE" class="ChequePayment"/>
    <column name="PAYMENT_CLASS"/>
    <column name="PAYMENT_ID"/>
</any>

このマッピングについての更なる注意点があります。 サブクラスが自身を <class> 要素としてマッピングしているので、 （かつ Payment は単なるインターフェイスなので）、 それぞれのサブクラスは簡単にその他の継承階層の一部となります。 （しかも、今までどおり Payment インターフェイスに対するポリモーフィックなクエリ を使用することができます）

<class name="CreditCardPayment" table="CREDIT_PAYMENT">
    <id name="id" type="long" column="CREDIT_PAYMENT_ID">
        <generator class="native"/>
    </id>
    <discriminator column="CREDIT_CARD" type="string"/>
    <property name="amount" column="CREDIT_AMOUNT"/>
    ...
    <subclass name="MasterCardPayment" discriminator-value="MDC"/>
    <subclass name="VisaPayment" discriminator-value="VISA"/>
</class>

<class name="NonelectronicTransaction" table="NONELECTRONIC_TXN">
    <id name="id" type="long" column="TXN_ID">
        <generator class="native"/>
    </id>
    ...
    <joined-subclass name="CashPayment" table="CASH_PAYMENT">
        <key column="PAYMENT_ID"/>
        <property name="amount" column="CASH_AMOUNT"/>
        ...
    </joined-subclass>
    <joined-subclass name="ChequePayment" table="CHEQUE_PAYMENT">
        <key column="PAYMENT_ID"/>
        <property name="amount" column="CHEQUE_AMOUNT"/>
        ...
    </joined-subclass>
</class>

もう一度述べますが、Payment は明示的に定義されません。 もし、Payment インターフェイスに対してクエリを実行するなら （例えば from Payment 節を使って）、 Hibernateは自動的に CreditCardPayment （とCreditCardPaymentのサブクラス、Payment の実装であるため）、 および、CashPayment 、ChequePayment のインスタンスを返します。 NonelectronicTransaction インスタンスは返しません。