Q:

Is it acceptable to have a database for direct queries and a second database for SSAS if they use the same data?

I am working on a server that will be used by many, many users across a large corporation and I have two databases storing the same information in different ways.
Databases:

DB1 = Simple relational for direct queries
DB2 = Star schema with facts and dimensions for the cubes

End Users:

Analysts - create reports(crystal)/query data directly (using db 1)
Management - use analysis cubes to look at data (using db 2)

Both are created/updated daily through two steps:

The production source data is imported and transformed into understandable, "common sense" relational tables stored in DB1.  
This step transforms the DB1 tables into fact/dimension tables and stores them in DB2.  The SSAS cubes are then created based on these tables and stored here.

Question
Based on that description, is this acceptable from a design standpoint? Would it be better to ditch the "simple" database and then use views to assemble the data in "simple tables" for analysts to query?  

A:

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.

