In this strategy there is one table for each class in the class hierarchy.
Each table represents a class in the hierarchy, and columns in the table are associated to the properties declared in the class itself. Even abstract classes have their own table, since they might have declared properties as well.
Tables are joined together using foreign keys. Each table representing a child class has a foreign key referencing the table representing the parent class. The foreign key is also the primary key, so the relationship cardinality between the tables is 1:1. In the previous illustration, the table Cricketer has a foreign key referencing the primary key in table Player.
The advantage of this strategy is that the database is normalized and the database model is very similar to the class model. Also, unlike the Single Table Strategy, all columns in tables are relevant to all table rows.
One disadvantage is performance. To retrieve a single object several inner or left joins might be required, becoming even worse when complex queries are used. Database refactoring is also more difficult - if you need to move a property to a different class in hierarchy, for example, more than one table needs to be updated.