It depends ( :) ) a bit on what OR mapper you're using, so spend some time researching what db features the OR mapper in question support/don't support.
E.g. Microsoft's OR mappers don't support all of SQL Server's built-in datatypes, don't support some of the newer/advanced TSQL features (recursive queries, optimizer hints etc spring to mind).
In theory, a good OR mapper should be flexible enough to overcome (and allow you to map) a well designed relational database schema to a good object model. In reality, we still have a bit to go before all pieces of the puzzle are in place; although many OR mappers support advanced mapping it often comes at the expense of complex queries and performance issues.
For good db performance (and to preserve the dba's sanity :) ) you should still follow best practices when it comes to db schema design; normalize first and denormalize where [/if] necessary. On the code-side, don't go overboard with your object model; even if the OR mapper support complex inheritance models and entities that merge many tables together, these are also the areas where you risk running into trouble with overly complex queries hitting the database etc. Profile, profile, profile and don't just take the ORM generated queries for granted. Keep in mind that OR mapper generated queries can often be tweaked just like normal SQL queries and that two functionally equivalent queries on the object side (e.g. linq queries) can sometimes result in vastly different SQL queries.