Q No. 1
Give at least four reasons why we De-Normalize the database.

Q No. 2
If de-normalization improves data warehouse processes, why fact table is in normal form?

Q No. 3
Is OLTP database design optimal for Data Warehouse?


Q No. 4
Why data warehouse and transaction databases need to be different.

Please HElp me

You need to go and read books.

Q1 -
1. Query Performance
2. Data loading performance
3. Ease of maintenance
4. When data integrity is less of a concern (such as in read-only databases) and query performance is a higher priority

Q2 -
Fact table is not always in normal form, especially if you need better query performance from grouping attributes on related dimensions. But, if it is in normal form then it is most likely to preserve data integrity.

Q3 -
Not generally. OLTP (assuming 3rd normal form) does not usually perform well on data warehouses where queries generally go after large amounts of data. OLTP is better suited where data integrity and transactional concurrency is a priority and most queries are focused to a relatively small subset of data. OLTP (3rd normal form) is designed to maximize data integrity, insert/update/delete concurrency.

Q4 -
Data warehouses and transactional databases are generally separate because they have competing requirements from hardware resources. Data warehouses generally drive a lot of CPU and memory utilization due to extensive use of aggregate functions and querying of large sets of data. Transactional databases need CPU and memory for lock management and handling a large number of insert/update/delete requests concurrently. Having the two on the same hardware is a recipe for poor performance and little or no scalability. There have been attempts to combine the two (HOLAP) but in my opinion those environments can handle medium size data sizes (less than 1 TB) and require a much higher level of monitoring and maintenance to keep performance where it needs to be.

I agree with the other poster - you should read some books. Look up Ralph Kimball or Bill Inmon to start with. They are the "fathers" of data warehouse design.