How about both? Have your cake and eat it too!
There's another option somewhere between the "one big table" and the "fully normalized" DB that really combines the best of both worlds: You can use something called materialized views, which are like views in that they are just as flexible and you query as many tables as needed, setting up all the joins etc., but they're also like tables in that the results are actually stored in a table.
The nice thing about this is that once you set this up and decide when it is to be refreshed (everytime one of the underlying table sis changes, or maybe just once per night) you don't have worry about it anymore. You can query the materialized view as if it were one big table (because it is), and performance will be fast (faster than using the select statement that is behind it). Most importantly, you don't have the headaches of maintaining data integrity. That's what the DB is there to handle.
If you don't have a DB that supports this out of the box, you can still use this idea by building a table out of the results of the view as a batch job each night.
