Joel Brown has summed up the nature of a data warehouse. I'll add something here about reporting requirements.
What is a data warehouse good for
A data warehouse is good for analytical reports where you want to calculate aggregates, trends or other statistical or financial metrics over a large volume of data. Generally a periodic load is best for this sort of application. Near-realtime loads for a data warehouse have two major drawbacks:
They're much, much more complex to implement.
Having financal data that changes from moment to moment can generate a whole class of spurious reconciliation bunfights. Unless you actually have a requirement for real-time data (see below) it's often better to have a system that can report a fixed as-at position that doesn't generate any ambiguity.
Operational vs. Analytic reports
If you have genuine realtime requirements then you have a requirement for an operational report. Generally, reports with genuine realtime requirements are not analytic in nature. Typically they are logs of work done, exception reports or to-do lists and the user needs to be able to do some work on the system and periodically re-run the report to see whether they still have anything outstanding that needs attention. Usually, they are also tied to a specific process on a specific operational system.
Usually, reports of this type can be run off the base system, or a replicated copy, and tend not to involve large volumes of data. In most cases this type of report is best run as an operational system, or a system that is replicated from that system.
Real time aggregate reporting
Occasionally people do have genuine requirements for analytics on data with low latency (near-realtime). Some examples of requirements for this system are:
Market data analytics where you have ticker data loaded directly to a trading floor system.
Accounts reporting systems where the users need to journal an entry and then report on it straight away
Web server log analytics.
For a typical enterprise data warehouse application, near-realtime feeds are almost always an anti-pattern as they greatly increase the complexity, generate moving targets for reconciliation and don't actually fulfil a genuine requirement. In this case batched loads are generally the way to go.
One characteristic found on realtime systems is that the data being reported n is almost always quite simple (market data feeds, accounting journals, web server log entries). This simplicity makes the realtime reporting feasible. Trying to get clever and do it on an enterprise wide scale is going to land you in a world of pain to achieve something for which there is almost certainly not a genuine requirement.
Separate operational and analytic reporting requirements
Operational and analytic reporting requirements are almost always in direct conflict with each other, and youre almost always better off managing them separately. Run your operational reports of a replicated copy of your production database and use a data warehouse for your analytic reports.
Unless you have a genuine requirement for near-realtime analytics, this is by far the best approach.
