数据仓库实施之二 数据仓库设计以及实施
数据仓库的逻辑设计基于维度的模型
数据仓库设计的理念就是去解决业务的问题。在大多数情况下，业务人员和执行人员关心的是从某些角度（产品，客户，雇员，时间）来聚合有意义的值（销售额，成本，收益）。从这个角度出发，他们需要知道的基于的这些角度我们就称之为维度。
星型模型一种传统的设计模式（star schema）
通常来说，一个事实表会与多个维度表相关联，维度表围绕在事实表的周围，像星星的节点一样，因此我们称这种模型为星型模型
维度表的注意点非范式化键众所周知，在OLTP系统中的三个范式，就是为了消除冗余和重复字段的。好处是当有更新或者删除的时候可以最小化修改的记录条数以及节省磁盘空间。但是在OLAP系统中数据通常是很少改动甚至不改动的，使用者通常情况下更关心的是效率的问题。在这样的前提下，OLAP的架构应采用非范式化的设计，表尽量的宽，尽量使用重复字段而不使用join去进行表连接。
在维度表中，每一行记录都应该使用一个主键来标识。通常情况下，维度表的数据来源于应用程序，这些表里面已经有主键标识了。在数据仓库中，这种来自原有的表的主键我们多数把它设置为业务主键（business key）。
沿用原表中的键来作为数据仓库表中的主键，看起来很明智，但是实际上，我们更倾向于设计一个新的键来作为主键我们称之为代理键（surrogate key）。我们使用代理键基于以下原因：
基于上述， 我们通常使用代理键（surrogate key）来作为主键，同时我们保留业务主键（business key）作为一列作为备用，这个时候我们称业务主键为备用键（alternative key）
事实表的注意点粒度键粒度就决定了你需要聚合的基础。所有的聚合数据都是基于最细的粒度，使用维度来进行聚合。实际上，由于业务的需求，很多事实表都需要基于不同的粒度建立。
度量值事实表的主键通常是包含了链接到维度表外键的联合主键。某些时候我们也会在主键里包含一些业务字段来达到唯一的目的。
度量值通常分为以下三种：
事实表连接的维度表都是非范式化的结构我们称之为星型模型。相反，有些情况下，维度表也是基于范式来设计的，这种情况下的模型，我们称之为雪花模型。在以下情况里面，可以考虑雪花模型：
有某个子维度关联到多个维度有某个维度里面几个字段经常会修改一个疏散的维度表内包含太多的子类，例如：产品维度，有些属性是所有产品共有的而有些产品有大小，颜色，其他的却没有当多个不同粒度的事实表链接到一个维度表中的不同层次的时候时间维度时间维度通常在数据分析和展现的时候都会存在。当你要建立一个时间维度的时候，你需要注意以下的方面，
在一个适当的粒度下建立包含时序层次包含业务所需要的时间层次考虑怎样生成一个时序维度的时候，通常不是从数据源中抽取出来，而是基于时间本身创建，因此通过T-SQL语句来创建，使用函数datepart，datename，month，year等使用excel包含的方法创建使用BI工具创建数据仓库的物理设计数据的物理存放数据仓库的设计中，物理存放占据很重要的部分，直接影响到执行查询的速度和效率，在制定一个数据仓库的设计的时候，我们需要考虑以下几点：
源于SQLServer多线程的技术，可以将数据分布式的存放到多个存储中，使用RAID技术来分别存放，或直使用SQLServer中的文件以及文件组的概念去分别存放将日志文件单独区别存放将临时表和文件单独存放，减少因为重建和删除产生的索引碎片预先分配空间以及禁止自动增长索引大家应该都了解，使用索引可以大大的减少查询时间。因此在数据仓库中使用合适索引也是非常必要的
维度表索引在代理键上建立非聚集索引在业务键（备用键）上建立聚集索引在经常使用查询过滤的列上面建立非聚集索引事实表索引由于几乎所有的事实表都基于时间，并且会按时间来进行分区，所以在时间列上建立聚集索引在各个外键上面建立非聚集索引列存储索引SQLServer提供了新的基于xVelocity压缩技术的列存储索引，但是注意使用
每个表只能使用一个列索引加了列索引的表变为只读在表分区上建立列索引只能基于分区字段只能在表上建立（视图不可以）分区数据仓库通常用来存储海量数据，做分区有以下好处
提高查询效率加快数据加载和删除提高索引管理性增加备份和还原的灵活性数据压缩数据压缩可以减少磁盘存放空间，提高IO查询效率，在IO作为当今IT的最大瓶颈的情况下，压缩是非常必要的
数据压缩的形式行压缩页压缩
