hibernate继承映射

《hibernate继承映射》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

在Java或.Net类与类之间存在关联、聚集和继承关系。一般来说：关联关系：采用“一对多或一对一”的映射即可；聚集关系：采用“集和映射”，即映射Set,Bag,List,Map继承关系：本文以下详述 因为关系数据库的表之间不存在继承关系，所以Hibernate提供了以下三种对继承关系映射的方法，即在继承关系树中：(1)、每个具体类（非抽象类）对应一个表：此方式中关系数据模型完全不支持对象的继承关系。(2)、基类（根类）对应一个表：此方式中对关系数据模型进行非常规设计，在数据库表中加入额外的区分子类的字段，从而使关系数据模型可以支持继承关系。(3)、每个类对应一个表：此方式中在关系数据模型中用外键关系来表示继承关系。这三种映射方式都各自有利有弊，需要根据具体情况来选择使用。分别说明一下：为了说明方便，引用一个比较经典的简单例子Employee类，它为抽象类，有两个直接子类HourlyEmployee类，Employee的子类，继承父类的name属性SalarilyEmployee类，Employee的子类，继承父类的name属性Company类，它有一个employees集和属性在此，先这样说明一下啊，日后有时间放个类图上来就一目了然了。 继承关系中每个具体类对应一个表这是最简单的映射方式。基类Employee没用映射，只需要为两个子类提供映射关系即可。看一下映射文件：                                                                                                                                                                                 可以看出，在这种映射方式中，每个子类除了映射自己的属性外，还需要映射从父类继承来下的属性，这是该映射方式的一个特点。  基类（根类）对应一个表这种映射方式只需为基类Employee创建一个表即可。在表中不仅提供与Employee所有属性的字段，还要提供与所有子类属性对应的字段，此外还需要一个字段用于区分子类的具体类型。此时的映射文件为：                                                                                                                                                                                可以看出，来个子类没有单独的映射，在DB中没有对应的表存在。而只有一个记录所有自身属性和子类所有属性的表，在子类为HourlyEmployee的时候，SALARY字段将为NULL，同样子类为SalarilyEmployee的时候，RATE字段将为NULL。那么，如果业务逻辑要求SalariedEmployee对象的rate属性不允许为null，显然无法在EMPLOYEES表中为SALARY字段定义notnull约束，可见这种映射方式无法保证关系数据模型的数据完整性。  每个类对应一个表这种方式为基类和子类分别创建表，即EMPLOYEES、HE和SE三个表。EMPLOYEES只包含Employee自己属性的字段，每个子类的表也同样只包含自己类属性的字段。此外，HE表和SE表都以EMPLOYEE_ID字段作为主键，该字段还同时作为外键参照EMPLOYEES表。HourlyEmployee和SalarilyEmployee没有独立的映射配置，但是在DB中有相应的表存在，这是其一个特点。                                                                                                                                                                                         可见，两个元素用于映射两个子类，元素的子元素指定HE表和SE表中既作为主键又作为外键的EMPLOYEE_ID字段。 三种映射方式的比较和选择为了方便说明为三种方式按顺序标号为[1][2][3]。1、复杂度：   [1]包含重复字段；   [2]简单；    [3]表较多且之间有外键约束；2、查询性能：   [1]若查询父类需查所有子类表；   [2]效率高；   [3]需要表内连接或左外连接；3、可维护性：   [1]若父类属性变化需要修改所有子类对应的表；   [2]只需修改一个表；   [3]若某个类属性变化只修改这个类对应的表；综上，选择时，可以参考以下原则：1、子类属性不是非常多时，优先考虑[2]，因为其性能最佳。2、子类属性非常多，且对性能要求不是很严格时，优先考虑[3]