etl流程,数据流图及etl过程解决方案.ppt43篇一：ETL设计过程本文将介绍设计和实现仓库 ETL 过程，并了解仓库的性能和安全问题。
简介数据集成是数据仓库中的关键概念。
ETL(数据的提取、转换和加载)过程的设计和实现是数据仓库解决方案中极其重要的一部分。
ETL 过程用于从多个源提取业务数据，清理数据，然后集成这些数据，并将它们装入数据仓库数据库中，为数据分析做好准备。
ETL 过程设计尽管实际的 ETL 设计和实现在很大程度上取决于为数据仓库项目选择的 ETL 工具，但是高级的系统化 ETL 设计将有助于构建高效灵活的 ETL 过程。
在深入研究数据仓库 ETL 过程的设计之前，请记住ETL 的经验法则：―ETL 过程不应修改数据，而应该优化数据。
‖如果您发现需要对业务数据进行修改，但不确定这些修改是否会更改数据本身的含义，那么请在开始 ETL 过程之前咨询您的客户。
调制的 ETL 过程设计由于其过程化特性以及进行数百或数千个操作的可能性，所以以精确方式设计 ETL 过程，从而使它们变得高效、可伸缩并且可维护就极为重要。
ETL 数据转换操作大致可以分为 6 个组或模块：数据的提取、验证、清理、集成、聚集和装入。
要安排好这些组，按照使这一过程获得最大简化、具有最佳性能和易于修改的逻辑次序来执行操作。
下图中展示了执行的次序。
图 1. ETL 数据转换过程的功能模块设计在项目的业务需求和数据分析阶段，我们创建了数据映射信息。
有许多中记录数据映射的方式;ETL 数据映射表是指导 ETL 过程设计的最佳方式。
您还可以将该表用作与业务客户就数据映射和 ETL 过程问题进行交流的方式。
ETL 数据映射表有不同的级别，如实体级别和属性级别。
每个级别中都具有不同级别的详细数据映射信息。
下表是一个实体级别的 ETL 数据映射表的简化例子。
该表中的每个―X‖表示到操作细节或较低级数据映射文档的链接。
表 1. ETL 实体映射表源验证清理转换集成聚集目标账户客户 X X ? X X 客户信贷客户 X X X借贷客户 X ? X支票账户 X X ? X X 账户储蓄账户 X ? X信贷账户 X ? X借贷账户 X X ?在 DB2 数据仓库中实现 ETL 过程DB2? Universal Database? Data Warehouse Editions为数据仓库功能提供了改进的性能和可用性。
DB2 Data Warehouse Center(DWC)是一个可视化的 ETL 设计和实现工具，它是 DB2 UDB 中的组成部分。
这一节将查看如何使用DB2 UDB(Version )Data Warehouse Center 设计和实现仓库 ETL 过程。
创建仓库控制数据库仓库控制数据库包含存储数据仓库中心(Data Warehouse Center)元数据所必需的控制表。
在Data Warehouse Center 的 Version 或更新的版本中，仓库控制数据库必须是 UTF-8(UnicodeTransformation Format 或 Unicode)的数据库。
这一需求为 Data Warehouse Center 提供了扩展的语言支持。
如果尝试使用非Unicode 格式的数据库登录Data Warehouse Center，那么您会收到无法登录的错误消息。
您可以使用 Warehouse Control Database Management 工具，将元数据从指定的数据库迁移到新的 Unicode 数据库中。
下面是创建和启动新的仓库控制数据库的步骤：确保启动了 DB2 仓库(Warehouse)服务器和相关的服务。
在仓库控制数据库的管理窗口中，填入控制数据库名、模式名(IWH)、用户 ID 和密码，并创建该仓库控制数据库。
如果在以前版本的 DB2 DWE 上已经有一个仓库，那么还可以使用此过程将仓库控制数据库迁移到当前版本中。
通过新创建的或迁移的控制数据库登录到 DB2 DataWarehouse Center，如图 2所示。
确保使用与步骤 1 相同的用户 ID 和密码。
如果仓库控制数据库是一个远程数据库，则必须对该节点和控制数据库进行编目。
图 2. 登录 DB2 DWE 仓库中心注意：DB2 Data Warehouse Center 的登录窗口将允许您在多个仓库控制数据库中进行切换。
当有许多项目或开发人员在同一 DB2 数据仓库(Data Warehouse)服务器上工作时，此功能极其有用。
定义代理站点仓库代理(agent)管理数据源和目标仓库之间的数据流。
仓库代理可用于 AIX?、Linux、iSeries?、z/OS?、Windows? NT、Windows XX 和 Windows XP 操作系统，以及 Solaris? 操作环境(Operating Environment)。
这些代理使用 Open Database Connectivity(ODBC)驱动程序或 DB2 CLI 与不同的数据库进行通信。
只需要几个代理就可以处理源仓库和目标仓库之间的数据迁移。
您所使用的代理数目取决于现有的连接配置，以及计划迁移到仓库中的数据量。
如果需要同一代理的多个进程同时运行，则可以生成附加的代理实例。
代理站点是安装了代理软件的工作站的逻辑名称。
代理站点的名称与 TCP/IP 主机名不同。
一个工作站可以只有一个 TCP/IP 主机名。
不过，您可以在一个工作站上定义多个代理站点。
逻辑名称将标识每个代理站点。
在设置数据仓库时，必须定义仓库将用来访问源数据库和目标数据库的代理站点。
Data Warehouse Center 使用本地代理作为所有 Data Warehouse Center 活动的默认代理。
但是，您可能需要使用来自包含仓库服务器的工作站的另一站点上的仓库代理。
您必须在 Data Warehouse Center 中定义该代理站点，从而标识安装了该代理的工作站。
Data Warehouse Center 使用这一定义来标识启动代理的工作站。
图 3. DB2 仓库代理上图说明了仓库代理、数据源、目标和仓库服务器之间的关系。
定义仓库源仓库源指定将为仓库提供数据的表和文件。
Data Warehouse Center 使用仓库源中的说明来访问数据。
DB2 Data Warehouse Center 支持所有主要平台上的大量关系数据源和非关系数据源，如下图所示。
图 4. 仓库数据源这使得配置从 DB2 Data Warehouse Center 到所支持数据源的连接变得极其容易。
在建立到数据源的连接并确定需要使用哪些源表之后，就可以在 Data Warehouse Center 中定义 DB2 仓库数据源了。
如果使用相对仓库代理的远程源数据库，就必须在包含仓库代理的工作站上注册这些数据库。
定义仓库数据源的过程会根据数据源类型的不同而有所不同。
下面是一个在 DB2 Data Warehouse Center 中定义关系仓库数据源的例子。
为了在 Data Warehouse Center 中定义关系数据源，要执行以下操作：在 Data Warehouse Center 中打开 Define Warehouse Source 记事本。
添加有关仓库源的信息。
指定访问仓库源的代理站点。
指定有关源数据库的信息，如下图 5 所示。
将源表和视图导入仓库源中。
授权仓库组，以访问仓库源。
图 5. 定义仓库关系数据源定义仓库目标仓库目标是指包含已转换数据的数据库表或文件。
您可以使用仓库目标给其他仓库目标提供数据。
例如，一个中心仓库可以向部门级服务器上的数据集市提供数据。
有两种创建仓库目标的方法。
一种是从现有的表或文件进行导入，另一种则是通过使用仓库系统生成目标。
图 6. 定义仓库目标表正如从图 6中可以看到的，在定义 DB2 仓库目标表时，可以指定是否由 DB2 Data Warehouse Center 创建该表，以及该表是否是 OLAP 模式中的一部分，这意味着它可能最终被用作多诸如星型模型之类的维数据模型中的一个维度或事实表。
定义仓库主题领域、过程和步骤仓库步骤是对仓库中单独某一操作的定义。
仓库步骤定义如何移动和转换数据。
可以在 DB2 Data Warehouse Center 中使用的仓库步骤类型有很多：SQL(插入、更新和替换)文件(FTP，文件数据的导入和导出)DB2 程序(数据导出、装入、表重组和统计数据更新)仓库转换器(数据清理、键表和时间表的生成，以及翻转和透视数据)统计信息转换器在运行一个步骤时，可能发生仓库源和仓库目标之间的数据迁移或转换。
其中一个步骤就是 Data Warehouse Center 中的一个逻辑实体，该实体定义了以下内容：到源数据的链接。
对输出表或文件的定义和链接。
用来填充输出表或文件机制(SQL 语句或程序)和定义。
填充输出表或文件的处理选项或时间表。
仓库过程包含为特定仓库执行数据转换和移动的一系列步骤。
一个过程可以产生一个表或一组总结表(summary table)。
过程还可以执行一些特定类型的数据转换。
图 7. 定义仓库过程篇二：一步一步学习ETL一步一步学习SQL Server BI一步一步学习sqlserver BI--数据仓库设计因为项目还没有真正开始，但是接触BI已有半年多，手痒，这几天准备搞一个简化版本的BI项目。
一方面给刚BI入门的朋友一个参考，另外一方面也为自己的将要开始的项目做个准备，让自己能够考虑到一些项目的细节。
同时也希望对BI有研究的朋友提供一些建议和经验。
因为我们的这个案例是采用微软的sqlserverXX的BI平台开发的，所以这里先贴一张WebCast里面截来的图，这张图主要反映了采用sqlserverXX的BI项目的架构。
好了，咱们开始吧。
我说的这个项目需求很简单，因为是简化版本的么。
这是一个游戏中使用到的物品的销售分析软件。
里面包括几个概念，游戏，销售部门，物品，交易金额，交易笔数，发布单数等。
我们要做的事情就是按游戏，按部门，按物品来实现对交易金额，笔数等的数据交叉分析。
在我们这个系统里面，我们的数据颗粒度是天。
好了，既然是简化版，我们也就不用那么罗嗦，什么需求分析，分析设计都省了吧，下面直接进入数据库设计。
我们的数据库一共包括四张维度表（部门维度，游戏维度，物品维度，时间维度），一张事实表（游戏交易数据事实表）。
部门维度表游戏维度表物品维度表时间维度表交易数据事实表由于我们的这个案例比较简单，所以维度与事实表之间的关系也比较简单，是一个简单的星型架构。
这一节我们就先写到这里，下一节我将会详细的写这个项目的ETL部分。