ETL学习笔记之三：MS SQL DTS

对于MS SQL-Server的DTS，在使用MS SQL-Server2000时，有最基本的接触，但仅限时简单的数据导入/导出。当开始了解ETL时，才发现DTS原来就是ETL的应用之一。
先不谈论DTS的好坏，但它至少MS产品的特点，易学，易用。所以，要了解ETL的应用，从DTS开始，在我看来，是个不错的选择。我只是学习，所以我没 有能耐去评价它，下面，只能讲DTS的功能一一列举出来，可能这些与SQL-Server的联机帮助有些重复，但对我来说，是一个加深记忆的方法。
一：概念
自完全不同源的数据析取、转换并合并到单个或多个目的。主要应用于企业数据仓库的数据抽取过程，完成从源数据库/文件到数据仓库的抽取和转换过程。
看看，这不就是ETL要做的事儿。
二：特征
2.1：基于OLE DB，很方便从不同的数据源复制和转换数据。
是了，MS总是首要支持自已的其它产品，所以，它选择了最通用的Windows的标准。
2.2：有图形化设计器，也可通过编程二次开发。
这也是MS的长项，并且能把其它的东西一股脑儿的集成进来。
2.3：执行效率高于普通ADO(SQL)操作
据说是这样地，我做过简单的比较，确实不是一个数量级，原理呢？估计可能有较多特殊处理，比如批量插入bcp，传输前的数据压缩等技术……，当然，这只是我的猜测。
2.4：可调度。
这对于Windows系统，那很容易了，可以利用现成的系统级调度。
三：详细
来说点详细的东东，当然，这里的详细并不指全部，实际上，我也只能挑出比较有代表性的功能点列举一下，要是全部，那还不如抄袭联机帮助了。
3.1：包——最小的可调度单元
包是基本任务，由工作流连接而成。包可以嵌套(包中的单个任务可以是执行另一个已存在的包)。
包是调度的直接管理对象，嵌套包保证包任务的重用。
3.2：任务——最小的工作流连接单元
分为以下几种任务：
导出和导入数据任务、转换任务、复制数据库对象、邮件/消息发送、Transact-SQL 语句或 Microsoft ActiveX® 脚本执行包、采用COM自定义任务。
其中，最常用的应该是普通转换任务。这等同于ETL中的T。
3.3： 数据连接——定义数据源和目的地
分为以下几种：
标准数据库（如 Microsoft SQL Server 2000、Microsoft Access 2000、Oracle、dBase、Paradox）；与 ODBC 数据源的 OLE DB 连接；Microsoft Excel 2000 电子表格数据；HTML 源；以及其它 OLE DB 提供程序
文件连接数据链接连接(比较特殊)
注意：SQL-Server作为Windows应用产品，DTS自然也不支持Java。
对于标准数据库是最基本的应用，易于实现。文件连接涉及格式定义，还不算复杂。
3.4：转换——数据转换
数据转换，指列进行，有多种方式：
3.4.1：简单复制方式。
3.4.2：简单转换(如，数据格式化，取字符串子串等……)
3.4.3：ActiveX脚本(实际上是vbScript和JavaScript)
3.4.4：调用自定的COM对象进行转换。
通常会采用一二方式。如果要将DTS集成到你的应用中，可以第三种方式。
3.5：工作流
工作流包括成功，失败，完成。工作流支持脚本控制。可编程控制。
工作流方式对于纯数据抽取意义不大，但是考虑到任务包含收发邮件，信息，上/下传文件，那就有必要了。当然，你也可以将这些任务单独提出到应用端执行，而不采用DTS中的任务。
3.6：元数据
元数据方式更多的留备扩展，最基础的应用是用来预定义数据表。
3.7：数据驱动的查询任务——(一种特珠的转换方式)
一种很特殊的转换方式，支持参数。这里，单独把它提出来，因为它不是那么容易理解，我花了一些时间，才将其弄明白。
3.7.1：根据源数据的特征决定之后的查询方式(指增，删，改，查询操作)。
3.7.2：支持参数，参数通过定义绑定表来关联，通过定义转换脚本，可以计算出绑定列参数。
3.7.3：转换时可以定义批量处理。
3.7.4：转换支持多阶段抽取，可以定义阶段代码，阶段分为：行转换，转换失败，插入成功，插入失败，批处理完成，抽取完成。
此种应用异常复杂，应属高级应用。简单的看，当转换任务需要根据数据源来确定动作，这是非常有用的。比如你的应用存在多表存储，就可能根据表内的时间来确定之后的动作，达到数据分多表存储的目的。
3.8： 查找查询
作为转换数据任务和数据驱动的查询任务的一种功能。
查找查询使您得以对源和目的之外的其它连接运行查询和存储过程。例如，通过使用查找查询，可以在查询过程中进行单独的连接，并在目的表中包括来自连接的数据。
作为一种扩充功能，实现更复杂的查询操作。
3.9： 多任务支持事务处理
除了顺序执行，可以进行并行执行步骤，且支持检查点回滚。
当然，任务的事务仍然依赖于数据源所在所据库是否支持事务。一般情况下，顺序执行已经可以满足抽取需求。
好了，不管对错，还是说说我的看法：
首先：DTS中抽取流程定义比较清晰，数据转换功能丰富，可视的设计工具强大，有一定的可扩展性(COM定制，脚本支持)。
但是：但学习下来，隐隐约约觉得它有MS产品的通病，就是大而全，如果进行小型应用的集成，它是很方便和够用的，但如果要在大型项目中集成DTS，它提供的二次开发方式，就显得有些散乱，缺少一个总体的框架指导。当然，这可能与它的定位有关。
对了，我看的SQL-Sever2000的DTS，对于2005，我不知有哪些方面的改进。