It depends on what you mean by that and how you want to class your entities. In the context of a database you could contrive a qualifying description of polymorphism, but in general, no. Relational database theory is built on the notion of a relation (manifested as a table in an RDBMS) representing a specific entity, and only one. In other words you would not store cars and trees in the same table even though they both inherit from 'System.Object' (drawing on .NET object hierarchy). You might store different models of cars or species of trees where car inherits from vehicle and tree inherits from plant. Or you might want a vehicle table with properties common to cars, trucks, airplanes, etc. with child tables for each of those I mentioned. It depends on how granular you want to get.

For example say you had a table that stored types of trees (named tree) and in that table you wanted to store a deciduous tree and an evergreen. You might have a column named 'max_recorded_height' and another named 'average_life_expectancy.' However, you may not want a column called 'average_needle_length' because deciduous trees do not have needles, only evergreens do. So, you may want to create a child table to tree called evergreen that would only be referred to by objects of type evergreen (who inherit from your tree object) that was instantiated within your application so it could fill those properties that only pertained to evergreens. That said, you would still look into having those properties normalized out of the tree table since not all trees will have needles.

I would suggest you do some reading on normalization, especially normal forms, start with 3NF, and read the article about the impedance mismatch I linked to above.