Is this a good database design or transition? Normalize to Denormalized for Data Warehousing
(slightly medium size as of now)


You should be more precise than that when talking about data sizes. Generic words like small/medium/large will mean different things to different people, though in this instance it probably isn't significant.


  In the future, we are planning to turn this database into a data warehouse.


You shouldn't turn an application database into a data warehouse - keep the application database optimised for normal live application use and have data fed from it into the warehouse database for offline analysis.


  however in data warehousing normalization in not exactly needed.


Correct. Often warehouse solutions are explicitly denormlised in various ways to make certain reports easier to produce efficiently (especially by automated tools and relatively unskilled users).


  like extracting the data from the normalized table and putting it into a new database with the denormalized table?


This is generally the way to go.

Keep your live data structures optimised for the applications main workflows and data correctness (i.e. keep things in normal form to avoid data inconsistencies due to design issues or other bugs), and build &amp; update (or rebuild) your warehouse from those application databases using some form of ETL process. The live, normal form, data in the production databases is your source of truth from which you can rebuild the warehouse if something goes wrong. The warehouse should not live in one application instance's database because you may later want to combine data sourced from multiple applications (and/or multiple instances of the same application) in the warehouse, and the differing IO and locking requirements of live applications and large reporting tasks usually mean you want to keep those tasks separate and not competing for resources.

There are exceptions to this of course, as with everything. For instance you may want live reports in the application that you denormalise some data for, for instance, though in this case you would still have core application tables optimised for data consistency and the application's main activity, and the reporting structures built/updated/rebuilt from that source of truth.