图2-1本课题针对的分析对象是服装产品销售及库存信息数据，其基础表数据来源于业务数据库。
2.2    OLTP和OLAP
有人可能在数据存储领域听说过OLTP和OLAP这两个术语。对于这两个系统的确切含义以及针对特定需求使用它们的意义，必须有正确的认识。
本课题中，源数据库中的数据已经是进行OLTP分析处理过的源表，所以不作设计讨论。
2.2.1    联机事务处理
OLTP是联机事务处理（online traditional processing）的缩写，它用来描述为了处理事务性活动而设计和优化的关系数据存储。事务性活动指的是在表中插入，更新和删除行。这类数据存储系统的典型设计是在一个源数据库中创建大量规范化表。
就目前来看，我们要查询的OLTP数据存储通常包含成百上千的源表。相关的查询处理器必须对来自多个相关数据表的数百万条记录进行筛选，排序和聚合。开发人员需要精通数据存储的查询语言，以便针对这么复杂的结构编写行之有效的查询，他们还需要知道如何捕捉和翻译报表方面的每个业务需求。开发人员还需要采用其他措施来改善查询的性能，包括用优化的查询语法重写查询，分析查询执行计划，强行采用某个查询执行路径，为关系源表添加索引等。虽然这些策略能够有一定的效果，但是要实现这些策略需要开发人员具备相当高的技能，并需要投入大量时间。
2.2.2    联机分析处理
OLAP是联机分析处理（online analytical processing）的缩写，它表示为了分析活动而设计和优化的数据结构。分析活动指的是侧重于数据读取方面应用的活动，而不是为了更有效的修改数据而对数据进行的优化活动。实际上，许多OLAP数据存储在实现时都是只读的。对于针对OLAP应用设置和优化的数据结构来说，常用的其他术语还有决策支持系统，报表数据库，数据仓库和多文数据集。
同OLTP一样，OLAP数据存储也有着多种多样的定义，不过大多数专家基本都同意OLAP数据存储采用反规范化的方式建模。在反规范化时，使用的数据表汇总包含非常宽泛的关系，其中包含有意为之的重复信息，采用这种方式，可以减少查询时必须连接的表以及需要建立的索引数量。查询牵涉面的减少会提高查询的速度。针对OLAP应用建模的数据存储通常采用一种特定的反规范化建模方式（即星形模式）进行反建模。
虽然使用反规范化的关系存储可以解决一些查询OLTP数据存储时遇到的问题，但反规范化的关系存储仍然以关系表为基础，所以只是在部分程度上缓解了瓶颈问题。开发人员仍然必须针对每一种业务报表需求编写复杂查询，并用手动方式对OLTP存储的副本进行反规范化，还要进一步根据性能要求对查询进行优化。执行这些任务所需要投入的工作量是相当惊人的。
2.3    数据仓库
数据仓库是个单一结构，通常是由一个或多个多文数据集构成。图2-2显示了构成一个OLAP多文数据集的各种数据源。数据仓库用于保存聚合起来的或者滚动（普遍的形式）积累起来的主要组织数据的只读视图。这个结构包括客户端查询工具。在规划和实现公司的数据仓库时，需要决定将哪些数据包含在内，需要包含的详细程度（或粒度）如何。
图2-2
OLAP和数据仓库这两者有时候会交换使用，但这样做过于简单化了，因为OLAP存储被建模成多文数据集，而数据仓库既可以使用反规范化的OLTP数据也可以使用OLAP。
2.4    提取，转换和加载系统
提取，转换和加载（extrac，transforrm，and load）通常缩写为ETL，指的是一整套协助将各类源数据（例如，关系的，半结构化的，非结构化的）提取，转换并加载到OLAP多文数据集或数据挖掘结构中的服务。SQL Server中包含了丰富的工具集，可以实现与ETL相关的操作，包括初始时将数据加载进多文数据集，后续将数据增量插入多文数据集，更新多文数据集的数据，以及删除多文数据集的数据。BI解决方案中常犯的一个错误就是低估了初始OLAP多文数据集加载和数据挖掘结构加载需要的ETL工作量以及后续插入，更新，删除数据的文护工作量。可以毫不夸张的讲，高达75%的BI项目初始工作时间都会花在项目的ETL工作上。来自不同源系统的数据所具有的脏，复杂和不完整等问题，是在规划阶段经常被忽视的因素。这里的脏指的是数据无效之类的问题，包括类型，格式，长度等方面的不正确数据。 VS商业智能系统设计+文献综述(3):http://www.youerw.com/jisuanji/lunwen_9480.html