• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
05 inheritance
 

05 inheritance

on

  • 611 views

 

Statistics

Views

Total Views
611
Views on SlideShare
611
Embed Views
0

Actions

Likes
0
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    05 inheritance 05 inheritance Presentation Transcript

    • Professional Open Source™ Mapping Inheritance© JBoss, Inc. 2003, 2004. 07/17/04 1
    • Mapping Class Inheritance Professional Open Source™  Inheritance is such a visible structural mismatch between the object- oriented and relational worlds because object-oriented systems model both is a and has a relationships.  SQL-based models provide only has a relationships between entities;  SQL database management systems don’t support type inheritance .  Four different approaches to representing an inheritance hierarchy: – Table per concrete class with implicit polymorphism—Use no explicit inheritance mapping, and default runtime polymorphic behavior. – Table per concrete class—Discard polymorphism and inheritance relationships completely from the SQL schema. – Table per class hierarchy—Enable polymorphism by denormalizing the SQL schema, and utilize a type discriminator column that holds type information. – Table per subclass—Represent is a (inheritance) relationships as has a (foreign key) relationships.© JBoss, Inc. 2003, 2004. 2
    • Table per concrete class with implicit polymorphism Professional Open Source™  The mapping for CreditCard and BankAccount is straightforward, each in its  own entity <class> element, as we have done already for classes without a superclass  (or persistent interfaces).  Hibernate still knows about the superclass (or any interface) because it scans the persistent classes on startup.© JBoss, Inc. 2003, 2004. 3
    • Problems with previous strategy Professional Open Source™  The main problem with this approach is that it doesn’t support polymorphic associations very well. In the database, associations are usually represented as foreign key relationships. As both the subclasses has different table which has a different foreign key, if we have to use superclass reference in any other class, it is difficult.  In previous figure, if the subclasses are all mapped to different  tables, a polymorphic association to their superclass (abstract BillingDetails in this example) can’t be represented as a simple foreign key relationship  Polymorphic queries (queries that return objects of all classes that match the interface of the queried class) are also problematic.  A query against the superclass must be executed as several SQL SELECTs, one for each concrete subclass.© JBoss, Inc. 2003, 2004. 4
    • Problems with previous strategy Professional Open Source™A further conceptual problem with this mapping strategy is thatseveral different columns, of different tables, share exactly thesame semantics. This makes schema evolution more complex. For example, a change to a superclass property results in changesto multiple columns. It also makes it much more difficult toimplement database integrity constraints that apply to allsubclasses.This approach is recommended where polymorphism isn’t usuallyrequired, and when modification of the superclass in the future isunlikely.© JBoss, Inc. 2003, 2004. 5
    • Table per concrete class with unions Professional Open Source™  In this situation, we again have two tables and duplicate superclass columns in both: CREDIT_CARD and BANK_ACCOUNT.© JBoss, Inc. 2003, 2004. 6
    • Advantages of this strategy Professional Open Source™  The first advantage you may notice with this strategy is the shared declaration of superclass (or interface) properties. No longer do you have to duplicate these mappings for all concrete classes—Hibernate takes care of this.  Keep in mind that the SQL schema still isn’t aware of the inheritance; effectively, we’ve mapped two unrelated tables to a more expressive class structure.  Polymorphic queries use union  Another much more important advantage is the ability to handle polymorphic associations; for example, an association mapping from User to BillingDetails would now be possible. Hibernate can use a UNION query to simulate a single table as the target of the association mapping© JBoss, Inc. 2003, 2004. 7
    • Table per class hierarchy Professional Open Source™  An entire class hierarchy can be mapped to a single table. This table includes columns for all properties of all classes in the hierarchy. The concrete subclass represented by a particular row is identified by the value of a type discriminator column.© JBoss, Inc. 2003, 2004. 8
    • Advantages of table per class hierarchy strategy Professional Open Source™  This mapping strategy is a winner in terms of both performance and simplicity.  It’s the best-performing way to represent polymorphism—both polymorphic and non polymorphic queries perform well—and it’s even easy to implement by hand.  Ad-hoc reporting is possible without complex joins or unions. Schema evolution is straightforward.  There is one major problem: Columns for properties declared by subclasses must be declared to be nullable. If your subclasses each define several non nullable properties, the loss of NOT NULL constraints may be a serious problem from the point of view of data integrity.  Another important issue is normalization.© JBoss, Inc. 2003, 2004. 9
    • Table per subclass Professional Open Source™  The fourth option is to represent inheritance relationships as relational foreign key associations.  Every class/subclass that declares persistent properties—including  abstract classes and even interfaces—has its own table.  Unlike the table per concrete class strategy we mapped first, the table here contains columns only for each non inherited property (each property declared by the subclass itself) along with a primary key that is also a foreign key of the superclass table.  See next page for diagram ..© JBoss, Inc. 2003, 2004. 10
    • Mapping all classes of the hierarchy to their own table Professional Open Source™© JBoss, Inc. 2003, 2004. 11
    • Professional Open Source™  If an instance of the CreditCard subclass is made persistent, the values of properties declared by the BillingDetails superclass are persisted to a new row of the BILLING_DETAILS table. Only the values of properties declared by the subclass are persisted to a new row of the CREDIT_CARD table. The two rows are linked together  by their shared primary key value. Later, the subclass instance may be retrieved from the database by joining the subclass table with the superclass table.  The primary advantage of this strategy is that the SQL schema is normalized. Schema evolution and integrity constraint definition are straightforward.  A polymorphic association to a particular subclass may be represented as a foreign key referencing the table of that particular subclass.© JBoss, Inc. 2003, 2004. 12
    • Choosing a strategy Professional Open Source™  If you don’t require polymorphic associations or queries, lean toward table per concrete-class—in other words, if you never or rarely query for BillingDetails and you have no class that has an association to BillingDetails(our model has).  An explicit UNION-based mapping should be preferred, because (optimized) polymorphic queries and associations will then be possible later. Implicit polymorphism is mostly useful for queries utilizing non-persistence-related interfaces.  If you do require polymorphic associations (an association to a superclass, hence to all classes in the hierarchy with dynamic resolution of the concrete class at runtime) or queries, and subclasses declare relatively few properties (particularly if the main difference between subclasses is in their behavior), lean toward table-per-class-hierarchy. Your goal is to minimize the number of nullable columns and to convince yourself (and your DBA) that a denormalized schema won’t create problems in the long run.© JBoss, Inc. 2003, 2004. 13
    • Professional Open Source™  If you do require polymorphic associations or queries, and subclasses  declare many properties (subclasses differ mainly by the data they hold), lean toward table-per-subclass. Or, depending on the width and depth of your inheritance hierarchy and the possible cost of joins versus unions, use table-per-concrete-class.© JBoss, Inc. 2003, 2004. 14