It's never a good idea to have just the data warehouse (your "DB 2"). When you denormalize data into a data warehouse or cube for reporting, you are "throwing away" information. Summarizing away details means that the detailed information is lost.
Let's say that you suffer damage or loss of your cube/data warehouse. Or alternatively, let's say that new types of analysis are needed which require you to recalculate your cubes. If you've thrown away your raw, detailed data then you won't be able to recreate your summarized data.
For this reason, and perhaps because some kinds of queries may require or be more efficient against your transactional details, it's a good idea to load your raw data into a relational data store and then build your summarized cubes/star schemas out of that.
Note that whenever you have two data stores, you have the potential for the results to get out of sync. You need to have rules and processes in place to handle these situations. One data store should always be the "book of record". Typically this will be the most detailed information (your DB 1). You also want to have detective controls in place that look for discrepancies and recalculate your summarized data whenever the two data stores become out of sync.