...
If you are modeling inheritance and you don't already have your subentities modeled, then you may probably want to use entity modeler's subclass widget. To use it, just select the entity you want to subclass and click the subclass button in the toolbar. The rest is self explanatory. Entity modeler does a good job creating Horizontal and Single Table entities for you. Vertical Inheritance will require a bit more work.
Manual Inheritance Modeling
Horizontal Inheritance
By far the easiest form of inheritance to model is Horizontal Inheritance. If you've already modeled a subentity, just select the entity then in the properties panel, select a parent entity and you're done. Yes, it really is that easy. When you save your model, Entity Modeler warns that you forgot to copy parent relationships and attributes to your new child entity. Then it kindly does the job for you.
...
You will find the Owns Destination checkbox in the Advanced properties panel of the relationship.
Now that you have your to-one relationship, you can use it to flatten the appropriate attributes and relationships into your subentity. To do that, turn down the arrow beside the to-one relationship, select the attribute or relationship you would like flattened and then click the flatten button on your toolbar. You will need to rename your flattened property so that it matches the property name of the parent's property.
...
If you are flattening a to-one relationship from the parent into the child entity, you MUST also flatten the foreign key for that relationship as well. You also MUST lock that foreign key. Your relationship will fail unless you do both these things. Furthermore, the flattening MUST be done with the "shortest hop" from your subentity. The reason for this is the way EOF expands the relationship definition vs attribute definition. In the VBear example, if the zooVID were modeled as vBearvWild.zooVID and the zooV relationship definition was vBearvWild.zooV instead of vAnimal.zooVID and vAnimal.zooV, then the expanded key path for the attribute will be vAnimal.zooVID and the expanded key path for the relationship join will be vWild.vAnimal.zooVID.
Gotchas: Due to the way the PKs are modeled, you must have a database that supports deferred constraints, or you must handle the order of the commit operations. I have tried VI in three different databases and it only worked in Postgresql so far. Maybe MySQL would work if the operations were ordered. I didn't try it.