Doctrine and Propel both make use of single and concrete table inheritance to map object relationships. The former sees all possible fields in the class tree mapped to a single table - whereas the latter maps each class to a specific table, duplicating common fields in the inheritance hierarchy.
While this facilitates the ORM apparatus, it suggests bad database design to me. Are these bad design patterns to enforce on a database?
It's impossible to say whether a particular database design is bad without knowing what the application is doing, the shape of the data, the performance expectations and so on. While generally normalisation (to some degree) is seen as best practice, it's pretty common to denormalise areas of databases for performance reasons so good and bad are very much open for discussion without a lot more data than most people have when they start out.
Add in the many approaches that can be taken to object to relational mappings and things become even more complex as the "best" database structure will depend on the specific object model, the level of inheritance and so on.
By taking a one size fits all approach ORM persistence libraries will almost always produce a non-optimal database structure for any given situation and will use some things which can be seen as bad practice for that a given situation.
You certainly could write an ORM that normalised but you'd see fairly hefty performance implications as for every insert into a main table it needed to scan the various look up tables to see if values existed, if they did obtain their keys and if they didn't carry out the relevant inserts.
(When you do this by hand you can short cut some of this as you know you presented them with a drop down containing only valid value so you don't need to do these look ups, you can just use the key happy that it's going to be valid, the ORM couldn't make that assumption as it doesn't control the UI.)
But what you have to remember is that they aren't aiming to optimise for database performance or data integrity, they're optimising for development speed. If the specific structure of your data is important to you then you either need to code your object / RDBMS mappings by hand, or at the very least do a detailed assessment of all the libraries available and select the one which most closely meets your needs (if one exists).
Essentially it comes down to requirements and the trade off between well structured data, database performance and development speed. As with many trade-offs you don't get to pick all three.
I don't agree that ORM promotes de-normalisation or bad database design. In fact, the worst designed databases I've seen has been done without ORM's. By making it simple to have proper relations based on row id instead of making a relation based on the value of a random field, it rather promotes good database design.
Possibly it doesn't promote normalization, but then again an ORM where it's easy to make tables/objects and relations could almost be seen to promote that as well. It's not much more work in an ORM to make a "location" table with addresses and link employees to the location instead of adding the address to the employee table. But without the ORM, separating out the location means that everytime you want to access the location as well, you need to make a join.
So my answer is: No, I don't think so. It's possibly in fact other other way around, a good ORMs encourages good database design, at least about those who have little experience.
As a rule of thumb, never model your data to meet the need of the developer (You can use Views or Sp for that, But not the Data Model).
The Data Model should be based on the Business rules of the application and performance needs.
