It all depends on requirements, database model and frontend tool.

If you're porting an existing project to ORM, you should first create low level objects that match database objects and implement database storage then use them to build higher level objects.

For example: customer can be broken to several several sub-entities as needed like bare data and addresses. Address is a low level object, a customer can have more than one (snail mail, email, phone,...) so it naturally fits on address detail table. Another object is customer name - it may change, so you might need history, so if used with an old invoice, it can pull the customer name active at that time, otherwise it uses current name.

Objects can just fine fit into a normalized data model, but need not to and details are encapsulated on low level, so users/developers don't care much about storage implementation.

Some ORM use database as storage only, no foreign keys, no triggers, no stored procs. No database logic, all logic in application. I'd recommend against this. It gives you the flexibility to change the backend database without hassle, but that's the only advantage. In this scenario all database access can be done exclusively though object model, which can have serious performance impact on bigger transactions like reports.

So, how do reports perform, depends solely on database design. You can design the database model and object model on top of it, or design objects and let them design the database. I prefer and recommend the first. It has some portability issues depending on used servers, but ensures optimal work regardless of going through object model or not.

Ops. Here I assumed ORM to be "Object-relational mapping". Google reveals it's the acronym for many other things. Also reveals there's a lot of info in wikipedia.

Hope it helps.