前面几种关系我们曾经就常常常使用，对于继承我们也并不陌生，常常接触的类与类之间的继承用extendskeyword，那么在表与表的关系中怎样表示呢？以下我们来讲继承映射。

继承有三种实现的策略，单表继承，详细表继承，类表继承。以下来分析一下这三种方式

 

 继承关联类关系

 单表继承

         每棵类继承树使用一个表，可知，这三个类在一张表中。例如以下表：

            这张表包含了父类，子类的全部属性，通过Type来区分是哪个子类。

 

            对象模型映射到关系模型：

 

      每棵类继承树一张表，类继承树相应多个类，要把多个类的信息放到一张表中，必须有某种机制来区分哪些记录是属于哪个类的。也就是上面discriminator字段，用这个字段的值来区分。

 

      优缺点：表中引入了用来区分子类的字段；假设某个子类的属性不能为空，那么在数据库中不能设置该字段非空，灵活性差；维护方便，仅仅须要改动一张表；假设子类添加，那么表中的冗余字段也会随着增多。假设数据不是非常多的话，效率是最好的。

 

详细表继承

       每一个子类一个表，与父类所相应的表以一对一主键关联的方式关联起来，例如以下

          animal表中存储了子类的全部记录，仅仅记录公共信息。它们独有的信息存储在子类表中。通过父表与子表的id来进行关联。

 

       对象模型映射到关系模型

       该类继承映射用<joined-subclass>标签,用于指示父类与子类的关联字段。

 

      优缺点：这样的方式符合关系模型的设计原则，不存在冗余，维护起来较方便，对每一个类的改动仅仅须要改动其相应的表，灵活性好；全然參照对象继承的方式进行配置。另外层次清晰，可是假设类继承的层次特别多，表特别多时，效率会非常低，所以假设层次少的能够用此方式。

 

类表继承

       每一个详细类一个表，依据上面的类图看，共同拥有两张表，pig，bird各一张

 

       每一个子类相应的数据库表不仅包含自身的属性还包含父类的属性。

       对象模型映射到关系模型

       该类型的继承映射用<union-subclass>标签，用于指示出该hbm文件所表示的类的子类

       优缺点：该方式符合关系模型的设计原则，可是表中存在反复字段，假设对公共属性部分进行改动则须要改动全部子类所相应表中的属性值，映射的灵活性非常大。另外对于子类的查询仅仅须要訪问单独的表，对于父类的查询须要检索全部的表。

 

小结

       

通过上面三种方式优缺点的总结，再总结一下：

          从复杂度的角度，方式1简单（子类属性不多）；方式2主外键；方式3有反复字段；

         从查询性能，方式1效率高；方式2须要表内连接或左外连接；方式3若查询父类须要查询全部类表；

         从可维护性，方式1仅仅须要改动一张表；方式2若某个属性发生变化改动此类相应的表；方式3若父类属性变化须要改动全部子类相应的表。

         也就是说，当子类属性不多时，优先选择方式1,；子类属性多，要求不严格时，优先选择方式2。

        看完后后，继承映射是不是没有那么深奥了。三种方式听起来非常厉害，事实上还是环绕着我们之前所学过的主外键，第三张表，各种连接等。这些都是基础。