现在决大多数企业已在其一个或多个部门内采用了计算机商务管理系统，也累积了相当的商业数据。然而，正如业内的那句老话“rich data, poor information”，以前累积的数据，并没有很好的得到利用。Why?并不是企业高层管理人员没有想到，而是这些数据来源太广，格式不统一，并且其中极少量的数据记录格式不正确；同时，累计的数据量相当庞大，上百万条记录才刚起步，某些大型公司每天所产生的商业记录已过千万；而且，某些细节对高层管理人员来说并不重要。他们需要的是一份站在战略层角度统观全局，及时的，在短时间内可以读完，为企业决策服务的统计报表。
为了实现这一艰巨的目标，BI专家把任务分解成了三个子任务：
1)为了整合各种格式的数据，清除原有数据中的错误记录，专家们提出了数据预处理的要求——STL(数据抽取、转换、装载)；
2)对预处理过数据，应该统一集中起来，由此产生了元数据(Meta data)、数据仓库(Data Warehouse)；
3)最后，对于集中起来的庞大的数据集，还应进行相应的专业统计，从中发掘出对企业决策有价值的新的机会，这就是OLAP(联机事务分析)和数据挖掘(Data Mining)。
下面具体介绍一下每个子任务所需要用到的专业技术和辅助工具。
1)数据预处理(STL：Extraction，Transformation，Load)
当早期大型的在线事务处理系统(OLTP)问世后不久，就出现了一种用于“抽取”处理的简单程序，其作用是搜索整个文件和数据库，使用某些标准选择合乎要求的数据，将其复制拷贝出来，用于总体分析。因为这样做不会影响正在使用的在线事务处理系统，降低其性能，同时，用户可以自行控制抽取出来的数据。但是，现在情况发生了巨大的变化，企业同时采用了多个在线事务处理系统，而这些系统之间的数据定义格式不尽相同，即使采用同一软件厂商提供的不同软件产品，或者仅仅是产品版本不同，之间的数据定义格式也有少许差距。由此，我们必须先定义一个统一的数据格式，然后把各个来源的数据按新的统一的格式进行转换，然后集中装载入数据仓库中。
其中，尤其要注意的一点时，并不是各个来源的不同格式的所有数据都能被新的统一格式包容，我们也不应强求非要把所有数据源的数据全部集中起来。Why?原因很多。有可能原来录入的数据中，少量的记录使用了错误的数据，这类数据如果无法校正，应该被舍去。某些数据记录是非结构化的，很难将其转化成新定义的统一格式，而且从中抽取信息必须读取整个文件，效率极低，如大容量的二进制数据文件，多媒体文件等，这类数据如果对企业决策不大，可以舍去。
目前已有一部分软件厂商开发出专门的ETL工具，其中包括：
·Ardent DataStage
·Evolutionary Technologies,Inc. (ETI) Extract
·Information Powermart
·Sagent Solution
·SAS Institute
·Oracle Warehouse Builder
·MSSQL Server2000 DTS
2)数据仓库
上面提到，在进行STL之前，需要先定义一个统一的数据格式。那么，定义出来的统一的数据格式是否需要保存起来，以便在数据仓库日后的演化中使用呢？Yes!随着企业不断变化的商业模式和业务规则，肯定需要对系统进行修改和功能升级。如果弄不清楚之前定义的数据格式的具体含义，我们将无从下手。所以，我们需要一种用来描述数据的数据。早期我们使用的是数据字典(Data Dictionary)，数据字典一般包括数据的定义、关系、来源、作用域、格式和用法。但是，随着时间的推移，专家们发现，越来越多的已搭建好的数据仓库希望方便的包容最新的各种格式的结构化和非结构化数据，而传统的基于关系型数据库的数据字典并不能达成这一目标。
xml出世之后，这种自描述，可无限嵌套扩展，平台独立性的文本数据格式为数据字典的进化提供了相当重要的技术支持，由此产生了基于xml的元数据的概念。并且，目前已有不少的软件系统和数据仓库都采用了xml格的元数据。如微软的.Net，P2P的EMule等。由此可见，元数据并不单单局限运用在数据仓库中。
由于基于xml的元数据相当灵活，我们可以用元数据来描述复杂的商业业务定义。所以，现在数据仓库中的元数据分为两种：技术元数据和业务元数据。技术元数据(technical meta data)是为企业技术用户和IT部门的员工提供支持的元数据，对于维护和改进系统来所至关重要。而业务元数据(business meta data)是为企业业务用户提供支持的元数据，使业务用户更容易理解统计报表中的信息。
元数据工具分为两类：一类是将各种元数据集成到集中式仓储的集成工具，另一类是在仓储上执行查询访问的访问工具。一般来说，大多数软件厂商所提供的数据仓库、BI系统中都捆绑了相应的工具。其中包括：
·Ardent MetaStage (Infomix)
·IBM information Catalog
·Brio Enterprise
·Business Objects
·Cognos Impromptu及Powerplau
·Information Advantage Business Intelligence
·Microsoft OLAP Services ("Plato")
·Microstrategy DSS Web and Server
数据仓库是BI的基础，就好比厨师的食材。各个数据源的数据经ETL的预处理后，就被送进了数据仓库中。数据仓库有如下４个重要特性：
①面向主题的：不同类型的公司，其主题集合是不相同的。
②集成的：数据仓库的数据来源很广，数据仓库最重要的目的就是为了集成这些不同数据源的数据。
③非易失的：和传统的操作型数据库系统相比，数据仓库通常是以批量方式载入和访问。而且，对于数据仓库中的记录，并不进行一般意义上的数据更新，删除。所有的历史数据都会被保留，通常我们只是不停的批量导入新的数据。
④随时间变化的：操作型数据库系统出于性能上的考虑，并不保存系统投入运行后所产生的所有数据，一般只保留最新的60~90天内所产生的数据记录。而且，通常情况下，操作型数据库中一项业务活动只占用一条记录。当业务状况发生变化后，我们只需更新相应的记录。而为了按时间变化发掘业务活动的时序规律，数据仓库中，该业务活动可能同时存在多条记录，除了相应字段的内容不同外，其业务活动的时间记录也不相同。数据仓库中的数据是一系列在某时某刻生成的复杂的快照，由此可见，数据仓库的数据是高度冗余且必须的。
而且，由于数据仓库的使用对象不尽相同，数据仓库的设计需要考虑其数据单元的细节程度，即粒度。细节程度越高，粒度级就越低，反之亦然。例如：一个简单的交易处于低粒度级，而每个月所有交易的汇总则处于一个高粒度级。通常，数据分析人员使用的数据粒度较低，而高层管理人员所使用的数据粒度较高。粒度同时决定了数据仓库所占用的物理空间的大小，尽管一条交易记录可能只占用200个字节，但是一个月所累积的10万条交易记录就占用了20M个字节。如果按月对每月的所有交易记录进行综合，所得到的记录可能只占用500个字节。
数据仓库通常的活动是批量载入和查询访问，并不进行一般意义的数据更新，而且其数据冗余程度较高。为了提高查询效率，我们可以采用一些非常规的方法来进行数据分区存储。而且，我们需要对数据仓库中的数据进行方便且有效的监控。
提供数据仓库技术服务的软件厂商大多是从操作型数据库系统发展起来，其推出的数据仓库都是基于其自身研发的大型数据库产品上，且捆绑了相应的ETL，元数据，OLAP，报表等工具，如IBM的DM2，SAS，Sybase，Oracle，Informix，MSSQL Server等。
在本节末要说明一下数据集市(Data Mark)。如果说数据仓库是建立在企业级的数据模型之上的话。那么数据集市就是企业级数据仓库的一个子集，他主要面向部门级业务，并且只面向某个特定的主题。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。然而，由于各个数据集市之间彼此独立，从而形成新的“信息孤岛”，也造成了重复投资。所以，目前越来越多的数据仓库厂商开始提供帮助企业用户整合原有数据集市，构建集中数据仓库的技术服务。在实际项目中，到底是选择数据仓库，还是选择数据集市，应取决于该项目的主要商业驱动。如果企业正忍受糟糕的数据管理和不一致的数据，希望为今后打下良好的基础，则数据仓库的方案比较好。如果该企业迫切需要给用户提供信息，那么可以先构建一个数据集市。而一旦满足了迫切的信息需求后，就应该考虑包含独立数据仓库的数据体系结构的转换计划。
(待续)
