员工表中把所属部门的ID和Name都包括了，这显然不符合
数据库范式的要求。
--------------------------------------------
正确. 经理说这是因为数据量大，为提高查询效率所做的反模式应用
------------------------------------------------------
错误，建议深入阅读<<Expert One-On-One>>第一章. 良好的数据库设计是基于数据库的大型系统成功的前提，当然，
在某些条件下，盲目遵从数据库范式也是不对的。 最简单的例子:
进销存业务中的发票明细表，应不应该设置"单价"字段? 从范式的角度来看是不需要的;
但是从用户的使用来看，又是必需的?
数据库范式的要求。
--------------------------------------------
正确. 经理说这是因为数据量大，为提高查询效率所做的反模式应用
------------------------------------------------------
错误，建议深入阅读<<Expert One-On-One>>第一章. 良好的数据库设计是基于数据库的大型系统成功的前提，当然，
在某些条件下，盲目遵从数据库范式也是不对的。 最简单的例子:
进销存业务中的发票明细表，应不应该设置"单价"字段? 从范式的角度来看是不需要的;
但是从用户的使用来看，又是必需的?
对于数据仓库项目或查询量大的项目，这样做是可以的。且有时是必须的！
还是让楼主把基本的架构说说吧? OLTP or OLAP ?
并发用户数 ?
Session数 ?
基础表(像提到过的员工表/部门表)基本架构 ?
活跃表的数据增长频度 ?
不做/做表连接时的具体效率指标 ? 这些都必须考虑，否则, 讨论数据库是否应遵从按范式去设计
没有意义.
To flysnowing(飞雪) :
SQL Server 处理海量数据的效率没法和Oracle/DB2 比
SQL Server 的锁定机制比较烂，经常会导致锁的升级
SQL Server 自身的内存管理机制也不是很科学 选择那种数据库不是看表数目多少来定,需要考虑的因素太多太多.
分析设计不是一个人说了就算,要针对项目需求而定,楼主的系统存在不合理性(个人意见)
从我个人的感觉来说:
员工表，部门表，可能还包括仓库表等等属于小的基础数据表;
而客户，供应商，商品等属于数据量大的基础数据表 业务表与小数据量的表进行表连接，开销不是很大；但是与
大数据量的表进行表间关联时,开销会非常大，因此在这种情况下,
业务表中多一些冗余，存放一些基础表的数据是可行的. 同意Beckhamboo的说法，楼主的系统架构设计可能存在问题.
查询效率可以通过实例视图，索引，分区表等方式来解决。
当然这些对OLTP系统不见得合适。
员工表会达到海量？千万条记录表做一些必要的冗余是可以的，但好像对效率影响不会太大，
因为通常这个表不会构成更大的乘积表，也就是，通常在组成结果集之前完成了条件选择
关键是查询语句要充分优化
所以通常还是尽量满足范式要求
------------------------------------------------------------------
当然了，那是系统保存你当时发言时候的状态，有些论坛还保存签名，是否使用url自动解析，是否解析多样式代码等等你说的这个问题和本文讨论的不是一回事！
数据仓库的数据量够大了吧，可是事实表仍然是遵循模式的，只有维表才是反模式的。
查询效率可以通过实例视图，索引，分区表等方式来解决。
当然这些对OLTP系统不见得合适。-------------------------------------------------------------------------------
事实表的数据一共能多大，几千万条？olap早完蛋了。事实表就是纬度+指标。拿纬度、指标去冗余，会大量增加olap空间，由于现在olap并不是很好，增加空间就降低效率。在dw中冗余数据毫无意义。
在数据仓库的ODS,STAGE中存在大量的冗余数据。在上亿条纪录的情况下，数据仓库的冗余是oltp无法想象的。
在中国现阶段还没有把olap,oltp分开处理
是产生争论的最大问题
单价是必须的，除非你的系统中的物品从不调价
'最简单的例子:
进销存业务中的发票明细表，应不应该设置"单价"字段? 从范式的角度来看是不需要的;'
我个人认为发票明细表中的单价从范式的角度来看是需要的，并不是总价除数量就是单价，因为有四舍五入的问题。
数据量与用多少个报表无关。
to frogdan (阿蛋)：
从业务的角度，若要记录员工连续所在部门的信息（即可查以前在那部门），部门的ID和Name同时记录是必须的，公司部门可能重组，原ID号会继续使用，但名称变了。