org_party_idとorg_party_typeの 2 つのフィールドを持つOrganizationという名前の新しいテーブルを作成します。
一致する各org_party_idは、 org_party_typeが CUSTOMERの場合はCustomer.idに一致し、 org_party_typeが VENDORの場合はVendor.idに一致します。
CustomerとVendorのマッピングを Organization のサブクラスに変更します。(リファレンス マニュアルを参照してください。識別子としてorg_party_typeを設定します。
ここで、 Contactのマッピングを Organization を指すように設定します。
これにより、 CustomersとVendorsの組織部分が抽象化され、一貫して処理できるようになります。抽象化の一貫性を保つために、コード内にOrganizationインターフェースを作成することもできます。
UPDATED
あなたのコメントに基づいて(そして質問を読み直しています)、結合されたサブクエリが最善の策であるように見えます. これは、サブクラスが ID によって結合されるため、実際には org_party_type を追加する必要がないことを意味します。そのようです:
<class name="Party" table="PARTY">
<id name="org_party_id" column="uid" type="long">
<generator class="hilo"/>
</id>
<!-- other PARTY properties -->
<joined-subclass name="Customer" table="CUSTOMER">
<key column="customer_id"/>
<property name="name" type="string"/>
<!-- other CUSTOMER properties -->
</joined-subclass>
<joined-subclass name="Vendor" table="VENDOR">
<key column="vendor_id"/>
<property name="name" type="string"/>
<!-- other VENDOR properties -->
</joined-subclass>
</class>
_