书评 -- Microsoft SQL Server 2005 Integration Services

＠小标：数据转换的需求

当我们要把其它系统的数据如以往 dBase/Clipper/FoxPro 的 dbf、Excel 的 xls、csv、Access/Jet 的 mdb 乃至于 SQL Server/Oracle/DB 2/Teradata  等大型数据库，或是 html/XML 档案彼此互转时，往往需要搭配工具，辅之以自己动手撰写简单的指令码或程序。

除了弹性与效率两大重点外，这些转换的动作往往还特别需要注意错误处理，将有错误的记录另外存放起来供事后检视。因为老旧系统或是其它非数据库系统在设计时，大都没有注意到关连式数据库的正规划，以及一些相关的限制式(如 unique、default、check、primary key等)，所以数据内容很可能不会完全符合我们利用关系型数据库所定义的数据规格。而多个系统的数据汇聚时，还会发生数据重复、格式不一致、内容冲突、数据过时...等等问题。

上述情况在一般中大型的企业非常普遍，由于信息系统经年累月地开发与使用，各个单位与历代的资讯工程师对数据处理方式的偏好不同，加上信息技术日新月异，自然导致全公司的数据储存与使用方式千奇百怪。但若要让信息系统发挥最大效用，又往往要让这些系统能够沟通无阻，彼此简单地交换数据以提供整合方便的信息。

近几年来，数据仓储(Data warehouse)/在线分析(OLAP)/数据采矿(Data Mining)等系统开始流行，因为企业已能够利用各型数据库系统累积在线交易(OLTP)数据，而这些累积的数据大多潜藏着公司的营运指针或是客户的行为逻辑。为了找出其中的模式，必须将存在各交易子系统的数据；其中符合分析主题之内容，以一致的表现方式集中储存到数据仓储。

＠小标：困难处

这时第一个技术上的难题就是容易上手、有弹性且高效率的数据转换工具。其主要的困难点如下：

l           异质型资料来源：用来集中储存数据的数据仓储一般就是一个超大型关系型数据库，如专属的 NCR Teradata 或通用的 MS SQL Server...等，而提供转进数据的各交易系统却可能多所不同，设计师要同时了解多种数据存取机制并不容易。

l           商业逻辑运算与弹性：一般在汇入数据至目的端之前，可能会先完成分割、过滤、查阅(将代码转成值)、汇总、联集、排序...等动作。且在流程中辅之以优先级、条件判断、交易管理、数据库对象的维护、错误处理、讯息发布...等。
且随着数据来源增加，数据目的地用途变异与扩增，设计用来转换数据的对象要能容易修改与重用。

l           效率：弹性与效率基本上是两个互相冲突的面向，弹性代表着工具本身会做广泛地测试，让使用者简单设定完毕后，它会自己找到正确的处理解决方式，但这也代表需要较复杂的准备工作。而效率则需要以最简单直观的方式处理单一事情，这意涵着一点设定错误就全毁了。
在广泛地整合时，我们需要弹性，但对于大量数据的加载，又必须有效率。笔者曾碰过需要转换数天，以 tera 为单位的数据量。而在转换过程中，一般只能干等，我们称此为数据处理的空窗期。空窗期越长，代表数据及时性越糟，延误下一个数据使用阶段，这是大家所不乐见的。

l           校正与一致化：凡是要转进数据仓储的数据应先求得格式与意义之一致，在不同的交易系统中，如公司人事数据可能用「男」、「女」来标示性别，但客户数据却可能用「0」、「1」，其它系统的性别字段还可能使用 True、False 或 Female、Male 等等，随着当时的系统开发人员喜好而定。但这在数据仓储内一定要一致。另外，某个系统的地址相关字段可能是五栏，另一个可能是六栏或四栏，但你的分析可能只需要三栏，因此转到数据仓储时需要合并或分割字段，更有甚者是原来三栏的数据可能要改成三列，或着反之。种种语意、格式、数据的正确性等诸多问题要在转换时期解决；这不是一件容易的事情。

l           周期性处理与管理：从在线交易系统将数据转进数据仓储是周期性的工作，绝不是累一次就可以一劳永逸，要让整个转换工作可以轻易地批次执行，如此系统才可能长久。另外，就笔者接触过的大型企业，其 DTS 封装从 50 多个到 700 多个都有，平均而言有 2~300 个封装，而参与使用该数据转换技术的工程师规模从 2~3 人到几十人。因此，如何妥善管理，其面向包含部署、备份、版本控管、灾难复原、教育训练...等，都需要考虑。

l           安全：按照安全的最小接触面原理，整合就有可能增加安全漏洞。由于是多种数据汇集，一定会碰上各系统的存取接口、网络流通、彼此系统的账号登入、机密性数据处理、经手人的授权、背景批次执行的账号、加解密数据的流程等问题。

微软的 SQL Server 小组将数据整合纳入该产品线需要满足的目标，其解决方案为何呢？

＠小标：需求无法满足，SSIS 应运而生

SQL Server 自 7.0 版首次导入的数据转换服务(Data Transformation Services)是一个容易上手的数据搬移和转换工具，让不同的资料来源与目的可以透过 ODBC/OLE DB 来互相转换资料。当你有各型数据格式或内容需要转换，将数据搬有运无时，DTS 是可轻易上手的工具。SQL Server 2000 之后，更是强化了它，使其成为最普遍的数据处理工具。

DTS 之所以称为数据转换(Data Transformation)，就是因为它主要的目的在「转换」，而不只是搬移数据。若仅搬移数据，光是 SQL Server 就不下五六种方法，如复制(Replication)、卸离/附加(Detach/Attach)、备份/还原(Backup/Restore)、Bulk Insert/Select Into/BCP、Log Shipping等等，都可以将数据从一处搬到另一处，但它们的特色大都是原封不动地搬移，且不整合其它非数据处理功能，只有 DTS 讲究转换与流程。

随着企业规模扩大、企业体内整体系统的数量递增、单一系统数据量累积，系统间数据整合之需求提升，以及上述几点难题让旧架构的 DTS 显得力不从心，微软必须以全新架构的 SSIS 来提供解决之道。

SQL Server 2005 放弃了之前相当成功的 DTS，完全重新设计与改写。在这个版本推出了 SQL Server Integration Services(SSIS) ，务求提升效能和增添更丰富的功能。而企图心从改变名称就可以看得出来，它不仅仅要做两个系统间的数据转换，还要提供多个系统间的数据整合。

SSIS 从核心重新开发，成为脱胎换骨的新产品。其中最大的变革之一是将流程(Integration Services run-time engine)与数据转换(Integration Services data flow engine)分成两大引擎来处理。这提供了较佳的流程控管与数据处理细节之可见度，同时增加了使用者自行撰写程序延伸 SSIS 的标准化与方便性。

新版本在封装执行的流程控管、错误处理、对象设定、除错、部署、执行记录、安全架构、效率，以及开发者透过微软版本控管机制(如 Visual SourceSafe VSS、Visual Studio Team System VSTS)控管 SSIS 封装的版本、自行以 .NET 语言延伸开发…等等方面都有长足的进步。若你有存放在不同系统的数据需要交换，例如从甲数据库转到乙档案格式，便可以考虑这个工具，倒是不一定要有 SQL Server 的参与。

SSIS 的开发小组让这个产品具有更开放的架构、更多功能、更具弹性、以及更高的执行效率。

＠小标：听听产品开发者怎么说

若你想要熟悉 SSIS，在此介绍一本好书：「Microsoft SQL Server 2005 Integration Services」，作者Kirk Haselden(网志地址：http://sqljunkies.com/weblog/knight_reign/) 本身就是 SSIS 的开发经理(Development Manager)，所以其著作应该算是官方说法了J

本书围绕在前述笔者所列的主题上；为你详加介绍这个全新的产品。书中除了说明 SSIS 的 what 和 how，也就是它所提供的某项功能是什么，以及如何使用外，也稍微谈了 why，叙述设计该项功能的缘由。

这本书不算入门书，但也不是深奥的进阶书，逐章读过后，应可以充分运用 SSIS。但你最好稍有用过微软的相关产品，如 DTS、SQL Server，写过 SQL 语言、简单的 Script、VB.NET 与 C#。当然，若你不想自己开发执行在 SSIS 平台上的对象，可以跳过本书的第六部份 Programming Integration Services，也就不需要熟悉 C# 语言了。

最后，笔者觉得稍为可惜的是本书未提供所有 SSIS 控制流程工作(control flow task)与数据流组件(data flow component)的说明，让我们在使用 SSIS 的某个对象时，可以如同翻阅字典一类的工具书，参照说明与简单的实例[1]。对于这些独立的对象，作者只举其大者，以范例说明，且略过了与 Analysis Services 整合的部份。

@小标：相关阅读

除了本书之外，若你觉得还需要其它的免费资源，可以参考以下的网址：

l           http://msdn.microsoft.com/sql/bi/integration/default.aspx：关于 SSIS 的官方网站，有非常多的资源。

l           http://blogs.msdn.com/ashvinis/、http://sqljunkies.com/WebLog/ashvinis/default.aspx：此网志的作者 Ashvini Sharma 是 SSIS 小组的 Development Lead。这里有一些不错的技术说明。可惜，他似乎不再维护这两个网志了。而上述 MSDN 网址提供了其它技术人员的网志连结(包含本书作者)，你都可以逛逛J

l           http://www.sqlis.com、http://www.sqldts.com：这两个姐妹站有许多关于 DTS 与 SSIS 的技术文件。

l           http://www.dbworld.com.tw：笔者在此处也撰写了大量关于 SSIS 的技术文章。

 

＠小标：数据转换的需求

当我们要把其它系统的数据如以往 dBase/Clipper/FoxPro 的 dbf、Excel 的 xls、csv、Access/Jet 的 mdb 乃至于 SQL Server/Oracle/DB 2/Teradata  等大型数据库，或是 html/XML 档案彼此互转时，往往需要搭配工具，辅之以自己动手撰写简单的指令码或程序。

除了弹性与效率两大重点外，这些转换的动作往往还特别需要注意错误处理，将有错误的记录另外存放起来供事后检视。因为老旧系统或是其它非数据库系统在设计时，大都没有注意到关连式数据库的正规划，以及一些相关的限制式(如 unique、default、check、primary key等)，所以数据内容很可能不会完全符合我们利用关系型数据库所定义的数据规格。而多个系统的数据汇聚时，还会发生数据重复、格式不一致、内容冲突、数据过时...等等问题。

上述情况在一般中大型的企业非常普遍，由于信息系统经年累月地开发与使用，各个单位与历代的资讯工程师对数据处理方式的偏好不同，加上信息技术日新月异，自然导致全公司的数据储存与使用方式千奇百怪。但若要让信息系统发挥最大效用，又往往要让这些系统能够沟通无阻，彼此简单地交换数据以提供整合方便的信息。

近几年来，数据仓储(Data warehouse)/在线分析(OLAP)/数据采矿(Data Mining)等系统开始流行，因为企业已能够利用各型数据库系统累积在线交易(OLTP)数据，而这些累积的数据大多潜藏着公司的营运指针或是客户的行为逻辑。为了找出其中的模式，必须将存在各交易子系统的数据；其中符合分析主题之内容，以一致的表现方式集中储存到数据仓储。

＠小标：困难处

这时第一个技术上的难题就是容易上手、有弹性且高效率的数据转换工具。其主要的困难点如下：

l           异质型资料来源：用来集中储存数据的数据仓储一般就是一个超大型关系型数据库，如专属的 NCR Teradata 或通用的 MS SQL Server...等，而提供转进数据的各交易系统却可能多所不同，设计师要同时了解多种数据存取机制并不容易。

l           商业逻辑运算与弹性：一般在汇入数据至目的端之前，可能会先完成分割、过滤、查阅(将代码转成值)、汇总、联集、排序...等动作。且在流程中辅之以优先级、条件判断、交易管理、数据库对象的维护、错误处理、讯息发布...等。
且随着数据来源增加，数据目的地用途变异与扩增，设计用来转换数据的对象要能容易修改与重用。

l           效率：弹性与效率基本上是两个互相冲突的面向，弹性代表着工具本身会做广泛地测试，让使用者简单设定完毕后，它会自己找到正确的处理解决方式，但这也代表需要较复杂的准备工作。而效率则需要以最简单直观的方式处理单一事情，这意涵着一点设定错误就全毁了。
在广泛地整合时，我们需要弹性，但对于大量数据的加载，又必须有效率。笔者曾碰过需要转换数天，以 tera 为单位的数据量。而在转换过程中，一般只能干等，我们称此为数据处理的空窗期。空窗期越长，代表数据及时性越糟，延误下一个数据使用阶段，这是大家所不乐见的。

l           校正与一致化：凡是要转进数据仓储的数据应先求得格式与意义之一致，在不同的交易系统中，如公司人事数据可能用「男」、「女」来标示性别，但客户数据却可能用「0」、「1」，其它系统的性别字段还可能使用 True、False 或 Female、Male 等等，随着当时的系统开发人员喜好而定。但这在数据仓储内一定要一致。另外，某个系统的地址相关字段可能是五栏，另一个可能是六栏或四栏，但你的分析可能只需要三栏，因此转到数据仓储时需要合并或分割字段，更有甚者是原来三栏的数据可能要改成三列，或着反之。种种语意、格式、数据的正确性等诸多问题要在转换时期解决；这不是一件容易的事情。

l           周期性处理与管理：从在线交易系统将数据转进数据仓储是周期性的工作，绝不是累一次就可以一劳永逸，要让整个转换工作可以轻易地批次执行，如此系统才可能长久。另外，就笔者接触过的大型企业，其 DTS 封装从 50 多个到 700 多个都有，平均而言有 2~300 个封装，而参与使用该数据转换技术的工程师规模从 2~3 人到几十人。因此，如何妥善管理，其面向包含部署、备份、版本控管、灾难复原、教育训练...等，都需要考虑。

l           安全：按照安全的最小接触面原理，整合就有可能增加安全漏洞。由于是多种数据汇集，一定会碰上各系统的存取接口、网络流通、彼此系统的账号登入、机密性数据处理、经手人的授权、背景批次执行的账号、加解密数据的流程等问题。

微软的 SQL Server 小组将数据整合纳入该产品线需要满足的目标，其解决方案为何呢？

＠小标：需求无法满足，SSIS 应运而生

SQL Server 自 7.0 版首次导入的数据转换服务(Data Transformation Services)是一个容易上手的数据搬移和转换工具，让不同的资料来源与目的可以透过 ODBC/OLE DB 来互相转换资料。当你有各型数据格式或内容需要转换，将数据搬有运无时，DTS 是可轻易上手的工具。SQL Server 2000 之后，更是强化了它，使其成为最普遍的数据处理工具。

DTS 之所以称为数据转换(Data Transformation)，就是因为它主要的目的在「转换」，而不只是搬移数据。若仅搬移数据，光是 SQL Server 就不下五六种方法，如复制(Replication)、卸离/附加(Detach/Attach)、备份/还原(Backup/Restore)、Bulk Insert/Select Into/BCP、Log Shipping等等，都可以将数据从一处搬到另一处，但它们的特色大都是原封不动地搬移，且不整合其它非数据处理功能，只有 DTS 讲究转换与流程。

随着企业规模扩大、企业体内整体系统的数量递增、单一系统数据量累积，系统间数据整合之需求提升，以及上述几点难题让旧架构的 DTS 显得力不从心，微软必须以全新架构的 SSIS 来提供解决之道。

SQL Server 2005 放弃了之前相当成功的 DTS，完全重新设计与改写。在这个版本推出了 SQL Server Integration Services(SSIS) ，务求提升效能和增添更丰富的功能。而企图心从改变名称就可以看得出来，它不仅仅要做两个系统间的数据转换，还要提供多个系统间的数据整合。

SSIS 从核心重新开发，成为脱胎换骨的新产品。其中最大的变革之一是将流程(Integration Services run-time engine)与数据转换(Integration Services data flow engine)分成两大引擎来处理。这提供了较佳的流程控管与数据处理细节之可见度，同时增加了使用者自行撰写程序延伸 SSIS 的标准化与方便性。

新版本在封装执行的流程控管、错误处理、对象设定、除错、部署、执行记录、安全架构、效率，以及开发者透过微软版本控管机制(如 Visual SourceSafe VSS、Visual Studio Team System VSTS)控管 SSIS 封装的版本、自行以 .NET 语言延伸开发…等等方面都有长足的进步。若你有存放在不同系统的数据需要交换，例如从甲数据库转到乙档案格式，便可以考虑这个工具，倒是不一定要有 SQL Server 的参与。

SSIS 的开发小组让这个产品具有更开放的架构、更多功能、更具弹性、以及更高的执行效率。

＠小标：听听产品开发者怎么说

若你想要熟悉 SSIS，在此介绍一本好书：「Microsoft SQL Server 2005 Integration Services」，作者Kirk Haselden(网志地址：http://sqljunkies.com/weblog/knight_reign/) 本身就是 SSIS 的开发经理(Development Manager)，所以其著作应该算是官方说法了J

本书围绕在前述笔者所列的主题上；为你详加介绍这个全新的产品。书中除了说明 SSIS 的 what 和 how，也就是它所提供的某项功能是什么，以及如何使用外，也稍微谈了 why，叙述设计该项功能的缘由。

这本书不算入门书，但也不是深奥的进阶书，逐章读过后，应可以充分运用 SSIS。但你最好稍有用过微软的相关产品，如 DTS、SQL Server，写过 SQL 语言、简单的 Script、VB.NET 与 C#。当然，若你不想自己开发执行在 SSIS 平台上的对象，可以跳过本书的第六部份 Programming Integration Services，也就不需要熟悉 C# 语言了。

最后，笔者觉得稍为可惜的是本书未提供所有 SSIS 控制流程工作(control flow task)与数据流组件(data flow component)的说明，让我们在使用 SSIS 的某个对象时，可以如同翻阅字典一类的工具书，参照说明与简单的实例[1]。对于这些独立的对象，作者只举其大者，以范例说明，且略过了与 Analysis Services 整合的部份。

@小标：相关阅读

除了本书之外，若你觉得还需要其它的免费资源，可以参考以下的网址：

l           http://msdn.microsoft.com/sql/bi/integration/default.aspx：关于 SSIS 的官方网站，有非常多的资源。

l           http://blogs.msdn.com/ashvinis/、http://sqljunkies.com/WebLog/ashvinis/default.aspx：此网志的作者 Ashvini Sharma 是 SSIS 小组的 Development Lead。这里有一些不错的技术说明。可惜，他似乎不再维护这两个网志了。而上述 MSDN 网址提供了其它技术人员的网志连结(包含本书作者)，你都可以逛逛J

l           http://www.sqlis.com、http://www.sqldts.com：这两个姐妹站有许多关于 DTS 与 SSIS 的技术文件。

l           http://www.dbworld.com.tw：笔者在此处也撰写了大量关于 SSIS 的技术文章。

 

＠小标：数据转换的需求

当我们要把其它系统的数据如以往 dBase/Clipper/FoxPro 的 dbf、Excel 的 xls、csv、Access/Jet 的 mdb 乃至于 SQL Server/Oracle/DB 2/Teradata  等大型数据库，或是 html/XML 档案彼此互转时，往往需要搭配工具，辅之以自己动手撰写简单的指令码或程序。

除了弹性与效率两大重点外，这些转换的动作往往还特别需要注意错误处理，将有错误的记录另外存放起来供事后检视。因为老旧系统或是其它非数据库系统在设计时，大都没有注意到关连式数据库的正规划，以及一些相关的限制式(如 unique、default、check、primary key等)，所以数据内容很可能不会完全符合我们利用关系型数据库所定义的数据规格。而多个系统的数据汇聚时，还会发生数据重复、格式不一致、内容冲突、数据过时...等等问题。

上述情况在一般中大型的企业非常普遍，由于信息系统经年累月地开发与使用，各个单位与历代的资讯工程师对数据处理方式的偏好不同，加上信息技术日新月异，自然导致全公司的数据储存与使用方式千奇百怪。但若要让信息系统发挥最大效用，又往往要让这些系统能够沟通无阻，彼此简单地交换数据以提供整合方便的信息。

近几年来，数据仓储(Data warehouse)/在线分析(OLAP)/数据采矿(Data Mining)等系统开始流行，因为企业已能够利用各型数据库系统累积在线交易(OLTP)数据，而这些累积的数据大多潜藏着公司的营运指针或是客户的行为逻辑。为了找出其中的模式，必须将存在各交易子系统的数据；其中符合分析主题之内容，以一致的表现方式集中储存到数据仓储。

＠小标：困难处

这时第一个技术上的难题就是容易上手、有弹性且高效率的数据转换工具。其主要的困难点如下：

l           异质型资料来源：用来集中储存数据的数据仓储一般就是一个超大型关系型数据库，如专属的 NCR Teradata 或通用的 MS SQL Server...等，而提供转进数据的各交易系统却可能多所不同，设计师要同时了解多种数据存取机制并不容易。

l           商业逻辑运算与弹性：一般在汇入数据至目的端之前，可能会先完成分割、过滤、查阅(将代码转成值)、汇总、联集、排序...等动作。且在流程中辅之以优先级、条件判断、交易管理、数据库对象的维护、错误处理、讯息发布...等。
且随着数据来源增加，数据目的地用途变异与扩增，设计用来转换数据的对象要能容易修改与重用。

l           效率：弹性与效率基本上是两个互相冲突的面向，弹性代表着工具本身会做广泛地测试，让使用者简单设定完毕后，它会自己找到正确的处理解决方式，但这也代表需要较复杂的准备工作。而效率则需要以最简单直观的方式处理单一事情，这意涵着一点设定错误就全毁了。
在广泛地整合时，我们需要弹性，但对于大量数据的加载，又必须有效率。笔者曾碰过需要转换数天，以 tera 为单位的数据量。而在转换过程中，一般只能干等，我们称此为数据处理的空窗期。空窗期越长，代表数据及时性越糟，延误下一个数据使用阶段，这是大家所不乐见的。

l           校正与一致化：凡是要转进数据仓储的数据应先求得格式与意义之一致，在不同的交易系统中，如公司人事数据可能用「男」、「女」来标示性别，但客户数据却可能用「0」、「1」，其它系统的性别字段还可能使用 True、False 或 Female、Male 等等，随着当时的系统开发人员喜好而定。但这在数据仓储内一定要一致。另外，某个系统的地址相关字段可能是五栏，另一个可能是六栏或四栏，但你的分析可能只需要三栏，因此转到数据仓储时需要合并或分割字段，更有甚者是原来三栏的数据可能要改成三列，或着反之。种种语意、格式、数据的正确性等诸多问题要在转换时期解决；这不是一件容易的事情。

l           周期性处理与管理：从在线交易系统将数据转进数据仓储是周期性的工作，绝不是累一次就可以一劳永逸，要让整个转换工作可以轻易地批次执行，如此系统才可能长久。另外，就笔者接触过的大型企业，其 DTS 封装从 50 多个到 700 多个都有，平均而言有 2~300 个封装，而参与使用该数据转换技术的工程师规模从 2~3 人到几十人。因此，如何妥善管理，其面向包含部署、备份、版本控管、灾难复原、教育训练...等，都需要考虑。

l           安全：按照安全的最小接触面原理，整合就有可能增加安全漏洞。由于是多种数据汇集，一定会碰上各系统的存取接口、网络流通、彼此系统的账号登入、机密性数据处理、经手人的授权、背景批次执行的账号、加解密数据的流程等问题。

微软的 SQL Server 小组将数据整合纳入该产品线需要满足的目标，其解决方案为何呢？

＠小标：需求无法满足，SSIS 应运而生

SQL Server 自 7.0 版首次导入的数据转换服务(Data Transformation Services)是一个容易上手的数据搬移和转换工具，让不同的资料来源与目的可以透过 ODBC/OLE DB 来互相转换资料。当你有各型数据格式或内容需要转换，将数据搬有运无时，DTS 是可轻易上手的工具。SQL Server 2000 之后，更是强化了它，使其成为最普遍的数据处理工具。

DTS 之所以称为数据转换(Data Transformation)，就是因为它主要的目的在「转换」，而不只是搬移数据。若仅搬移数据，光是 SQL Server 就不下五六种方法，如复制(Replication)、卸离/附加(Detach/Attach)、备份/还原(Backup/Restore)、Bulk Insert/Select Into/BCP、Log Shipping等等，都可以将数据从一处搬到另一处，但它们的特色大都是原封不动地搬移，且不整合其它非数据处理功能，只有 DTS 讲究转换与流程。

随着企业规模扩大、企业体内整体系统的数量递增、单一系统数据量累积，系统间数据整合之需求提升，以及上述几点难题让旧架构的 DTS 显得力不从心，微软必须以全新架构的 SSIS 来提供解决之道。

SQL Server 2005 放弃了之前相当成功的 DTS，完全重新设计与改写。在这个版本推出了 SQL Server Integration Services(SSIS) ，务求提升效能和增添更丰富的功能。而企图心从改变名称就可以看得出来，它不仅仅要做两个系统间的数据转换，还要提供多个系统间的数据整合。

SSIS 从核心重新开发，成为脱胎换骨的新产品。其中最大的变革之一是将流程(Integration Services run-time engine)与数据转换(Integration Services data flow engine)分成两大引擎来处理。这提供了较佳的流程控管与数据处理细节之可见度，同时增加了使用者自行撰写程序延伸 SSIS 的标准化与方便性。

新版本在封装执行的流程控管、错误处理、对象设定、除错、部署、执行记录、安全架构、效率，以及开发者透过微软版本控管机制(如 Visual SourceSafe VSS、Visual Studio Team System VSTS)控管 SSIS 封装的版本、自行以 .NET 语言延伸开发…等等方面都有长足的进步。若你有存放在不同系统的数据需要交换，例如从甲数据库转到乙档案格式，便可以考虑这个工具，倒是不一定要有 SQL Server 的参与。

SSIS 的开发小组让这个产品具有更开放的架构、更多功能、更具弹性、以及更高的执行效率。

＠小标：听听产品开发者怎么说

若你想要熟悉 SSIS，在此介绍一本好书：「Microsoft SQL Server 2005 Integration Services」，作者Kirk Haselden(网志地址：http://sqljunkies.com/weblog/knight_reign/) 本身就是 SSIS 的开发经理(Development Manager)，所以其著作应该算是官方说法了J

本书围绕在前述笔者所列的主题上；为你详加介绍这个全新的产品。书中除了说明 SSIS 的 what 和 how，也就是它所提供的某项功能是什么，以及如何使用外，也稍微谈了 why，叙述设计该项功能的缘由。

这本书不算入门书，但也不是深奥的进阶书，逐章读过后，应可以充分运用 SSIS。但你最好稍有用过微软的相关产品，如 DTS、SQL Server，写过 SQL 语言、简单的 Script、VB.NET 与 C#。当然，若你不想自己开发执行在 SSIS 平台上的对象，可以跳过本书的第六部份 Programming Integration Services，也就不需要熟悉 C# 语言了。

最后，笔者觉得稍为可惜的是本书未提供所有 SSIS 控制流程工作(control flow task)与数据流组件(data flow component)的说明，让我们在使用 SSIS 的某个对象时，可以如同翻阅字典一类的工具书，参照说明与简单的实例[1]。对于这些独立的对象，作者只举其大者，以范例说明，且略过了与 Analysis Services 整合的部份。

@小标：相关阅读

除了本书之外，若你觉得还需要其它的免费资源，可以参考以下的网址：

l           http://msdn.microsoft.com/sql/bi/integration/default.aspx：关于 SSIS 的官方网站，有非常多的资源。

l           http://blogs.msdn.com/ashvinis/、http://sqljunkies.com/WebLog/ashvinis/default.aspx：此网志的作者 Ashvini Sharma 是 SSIS 小组的 Development Lead。这里有一些不错的技术说明。可惜，他似乎不再维护这两个网志了。而上述 MSDN 网址提供了其它技术人员的网志连结(包含本书作者)，你都可以逛逛J

l           http://www.sqlis.com、http://www.sqldts.com：这两个姐妹站有许多关于 DTS 与 SSIS 的技术文件。

l           http://www.dbworld.com.tw：笔者在此处也撰写了大量关于 SSIS 的技术文章。

 

＠小标：数据转换的需求

当我们要把其它系统的数据如以往 dBase/Clipper/FoxPro 的 dbf、Excel 的 xls、csv、Access/Jet 的 mdb 乃至于 SQL Server/Oracle/DB 2/Teradata  等大型数据库，或是 html/XML 档案彼此互转时，往往需要搭配工具，辅之以自己动手撰写简单的指令码或程序。

除了弹性与效率两大重点外，这些转换的动作往往还特别需要注意错误处理，将有错误的记录另外存放起来供事后检视。因为老旧系统或是其它非数据库系统在设计时，大都没有注意到关连式数据库的正规划，以及一些相关的限制式(如 unique、default、check、primary key等)，所以数据内容很可能不会完全符合我们利用关系型数据库所定义的数据规格。而多个系统的数据汇聚时，还会发生数据重复、格式不一致、内容冲突、数据过时...等等问题。

上述情况在一般中大型的企业非常普遍，由于信息系统经年累月地开发与使用，各个单位与历代的资讯工程师对数据处理方式的偏好不同，加上信息技术日新月异，自然导致全公司的数据储存与使用方式千奇百怪。但若要让信息系统发挥最大效用，又往往要让这些系统能够沟通无阻，彼此简单地交换数据以提供整合方便的信息。

近几年来，数据仓储(Data warehouse)/在线分析(OLAP)/数据采矿(Data Mining)等系统开始流行，因为企业已能够利用各型数据库系统累积在线交易(OLTP)数据，而这些累积的数据大多潜藏着公司的营运指针或是客户的行为逻辑。为了找出其中的模式，必须将存在各交易子系统的数据；其中符合分析主题之内容，以一致的表现方式集中储存到数据仓储。

＠小标：困难处

这时第一个技术上的难题就是容易上手、有弹性且高效率的数据转换工具。其主要的困难点如下：

l           异质型资料来源：用来集中储存数据的数据仓储一般就是一个超大型关系型数据库，如专属的 NCR Teradata 或通用的 MS SQL Server...等，而提供转进数据的各交易系统却可能多所不同，设计师要同时了解多种数据存取机制并不容易。

l           商业逻辑运算与弹性：一般在汇入数据至目的端之前，可能会先完成分割、过滤、查阅(将代码转成值)、汇总、联集、排序...等动作。且在流程中辅之以优先级、条件判断、交易管理、数据库对象的维护、错误处理、讯息发布...等。
且随着数据来源增加，数据目的地用途变异与扩增，设计用来转换数据的对象要能容易修改与重用。

l           效率：弹性与效率基本上是两个互相冲突的面向，弹性代表着工具本身会做广泛地测试，让使用者简单设定完毕后，它会自己找到正确的处理解决方式，但这也代表需要较复杂的准备工作。而效率则需要以最简单直观的方式处理单一事情，这意涵着一点设定错误就全毁了。
在广泛地整合时，我们需要弹性，但对于大量数据的加载，又必须有效率。笔者曾碰过需要转换数天，以 tera 为单位的数据量。而在转换过程中，一般只能干等，我们称此为数据处理的空窗期。空窗期越长，代表数据及时性越糟，延误下一个数据使用阶段，这是大家所不乐见的。

l           校正与一致化：凡是要转进数据仓储的数据应先求得格式与意义之一致，在不同的交易系统中，如公司人事数据可能用「男」、「女」来标示性别，但客户数据却可能用「0」、「1」，其它系统的性别字段还可能使用 True、False 或 Female、Male 等等，随着当时的系统开发人员喜好而定。但这在数据仓储内一定要一致。另外，某个系统的地址相关字段可能是五栏，另一个可能是六栏或四栏，但你的分析可能只需要三栏，因此转到数据仓储时需要合并或分割字段，更有甚者是原来三栏的数据可能要改成三列，或着反之。种种语意、格式、数据的正确性等诸多问题要在转换时期解决；这不是一件容易的事情。

l           周期性处理与管理：从在线交易系统将数据转进数据仓储是周期性的工作，绝不是累一次就可以一劳永逸，要让整个转换工作可以轻易地批次执行，如此系统才可能长久。另外，就笔者接触过的大型企业，其 DTS 封装从 50 多个到 700 多个都有，平均而言有 2~300 个封装，而参与使用该数据转换技术的工程师规模从 2~3 人到几十人。因此，如何妥善管理，其面向包含部署、备份、版本控管、灾难复原、教育训练...等，都需要考虑。

l           安全：按照安全的最小接触面原理，整合就有可能增加安全漏洞。由于是多种数据汇集，一定会碰上各系统的存取接口、网络流通、彼此系统的账号登入、机密性数据处理、经手人的授权、背景批次执行的账号、加解密数据的流程等问题。

微软的 SQL Server 小组将数据整合纳入该产品线需要满足的目标，其解决方案为何呢？

＠小标：需求无法满足，SSIS 应运而生

SQL Server 自 7.0 版首次导入的数据转换服务(Data Transformation Services)是一个容易上手的数据搬移和转换工具，让不同的资料来源与目的可以透过 ODBC/OLE DB 来互相转换资料。当你有各型数据格式或内容需要转换，将数据搬有运无时，DTS 是可轻易上手的工具。SQL Server 2000 之后，更是强化了它，使其成为最普遍的数据处理工具。

DTS 之所以称为数据转换(Data Transformation)，就是因为它主要的目的在「转换」，而不只是搬移数据。若仅搬移数据，光是 SQL Server 就不下五六种方法，如复制(Replication)、卸离/附加(Detach/Attach)、备份/还原(Backup/Restore)、Bulk Insert/Select Into/BCP、Log Shipping等等，都可以将数据从一处搬到另一处，但它们的特色大都是原封不动地搬移，且不整合其它非数据处理功能，只有 DTS 讲究转换与流程。

随着企业规模扩大、企业体内整体系统的数量递增、单一系统数据量累积，系统间数据整合之需求提升，以及上述几点难题让旧架构的 DTS 显得力不从心，微软必须以全新架构的 SSIS 来提供解决之道。

SQL Server 2005 放弃了之前相当成功的 DTS，完全重新设计与改写。在这个版本推出了 SQL Server Integration Services(SSIS) ，务求提升效能和增添更丰富的功能。而企图心从改变名称就可以看得出来，它不仅仅要做两个系统间的数据转换，还要提供多个系统间的数据整合。

SSIS 从核心重新开发，成为脱胎换骨的新产品。其中最大的变革之一是将流程(Integration Services run-time engine)与数据转换(Integration Services data flow engine)分成两大引擎来处理。这提供了较佳的流程控管与数据处理细节之可见度，同时增加了使用者自行撰写程序延伸 SSIS 的标准化与方便性。

新版本在封装执行的流程控管、错误处理、对象设定、除错、部署、执行记录、安全架构、效率，以及开发者透过微软版本控管机制(如 Visual SourceSafe VSS、Visual Studio Team System VSTS)控管 SSIS 封装的版本、自行以 .NET 语言延伸开发…等等方面都有长足的进步。若你有存放在不同系统的数据需要交换，例如从甲数据库转到乙档案格式，便可以考虑这个工具，倒是不一定要有 SQL Server 的参与。

SSIS 的开发小组让这个产品具有更开放的架构、更多功能、更具弹性、以及更高的执行效率。

＠小标：听听产品开发者怎么说

若你想要熟悉 SSIS，在此介绍一本好书：「Microsoft SQL Server 2005 Integration Services」，作者Kirk Haselden(网志地址：http://sqljunkies.com/weblog/knight_reign/) 本身就是 SSIS 的开发经理(Development Manager)，所以其著作应该算是官方说法了J

本书围绕在前述笔者所列的主题上；为你详加介绍这个全新的产品。书中除了说明 SSIS 的 what 和 how，也就是它所提供的某项功能是什么，以及如何使用外，也稍微谈了 why，叙述设计该项功能的缘由。

这本书不算入门书，但也不是深奥的进阶书，逐章读过后，应可以充分运用 SSIS。但你最好稍有用过微软的相关产品，如 DTS、SQL Server，写过 SQL 语言、简单的 Script、VB.NET 与 C#。当然，若你不想自己开发执行在 SSIS 平台上的对象，可以跳过本书的第六部份 Programming Integration Services，也就不需要熟悉 C# 语言了。

最后，笔者觉得稍为可惜的是本书未提供所有 SSIS 控制流程工作(control flow task)与数据流组件(data flow component)的说明，让我们在使用 SSIS 的某个对象时，可以如同翻阅字典一类的工具书，参照说明与简单的实例[1]。对于这些独立的对象，作者只举其大者，以范例说明，且略过了与 Analysis Services 整合的部份。

@小标：相关阅读

除了本书之外，若你觉得还需要其它的免费资源，可以参考以下的网址：

l           http://msdn.microsoft.com/sql/bi/integration/default.aspx：关于 SSIS 的官方网站，有非常多的资源。

l           http://blogs.msdn.com/ashvinis/、http://sqljunkies.com/WebLog/ashvinis/default.aspx：此网志的作者 Ashvini Sharma 是 SSIS 小组的 Development Lead。这里有一些不错的技术说明。可惜，他似乎不再维护这两个网志了。而上述 MSDN 网址提供了其它技术人员的网志连结(包含本书作者)，你都可以逛逛J

l           http://www.sqlis.com、http://www.sqldts.com：这两个姐妹站有许多关于 DTS 与 SSIS 的技术文件。

l           http://www.dbworld.com.tw：笔者在此处也撰写了大量关于 SSIS 的技术文章。

 

＠小标：数据转换的需求

当我们要把其它系统的数据如以往 dBase/Clipper/FoxPro 的 dbf、Excel 的 xls、csv、Access/Jet 的 mdb 乃至于 SQL Server/Oracle/DB 2/Teradata  等大型数据库，或是 html/XML 档案彼此互转时，往往需要搭配工具，辅之以自己动手撰写简单的指令码或程序。

除了弹性与效率两大重点外，这些转换的动作往往还特别需要注意错误处理，将有错误的记录另外存放起来供事后检视。因为老旧系统或是其它非数据库系统在设计时，大都没有注意到关连式数据库的正规划，以及一些相关的限制式(如 unique、default、check、primary key等)，所以数据内容很可能不会完全符合我们利用关系型数据库所定义的数据规格。而多个系统的数据汇聚时，还会发生数据重复、格式不一致、内容冲突、数据过时...等等问题。

上述情况在一般中大型的企业非常普遍，由于信息系统经年累月地开发与使用，各个单位与历代的资讯工程师对数据处理方式的偏好不同，加上信息技术日新月异，自然导致全公司的数据储存与使用方式千奇百怪。但若要让信息系统发挥最大效用，又往往要让这些系统能够沟通无阻，彼此简单地交换数据以提供整合方便的信息。

近几年来，数据仓储(Data warehouse)/在线分析(OLAP)/数据采矿(Data Mining)等系统开始流行，因为企业已能够利用各型数据库系统累积在线交易(OLTP)数据，而这些累积的数据大多潜藏着公司的营运指针或是客户的行为逻辑。为了找出其中的模式，必须将存在各交易子系统的数据；其中符合分析主题之内容，以一致的表现方式集中储存到数据仓储。

＠小标：困难处

这时第一个技术上的难题就是容易上手、有弹性且高效率的数据转换工具。其主要的困难点如下：

l           异质型资料来源：用来集中储存数据的数据仓储一般就是一个超大型关系型数据库，如专属的 NCR Teradata 或通用的 MS SQL Server...等，而提供转进数据的各交易系统却可能多所不同，设计师要同时了解多种数据存取机制并不容易。

l           商业逻辑运算与弹性：一般在汇入数据至目的端之前，可能会先完成分割、过滤、查阅(将代码转成值)、汇总、联集、排序...等动作。且在流程中辅之以优先级、条件判断、交易管理、数据库对象的维护、错误处理、讯息发布...等。
且随着数据来源增加，数据目的地用途变异与扩增，设计用来转换数据的对象要能容易修改与重用。

l           效率：弹性与效率基本上是两个互相冲突的面向，弹性代表着工具本身会做广泛地测试，让使用者简单设定完毕后，它会自己找到正确的处理解决方式，但这也代表需要较复杂的准备工作。而效率则需要以最简单直观的方式处理单一事情，这意涵着一点设定错误就全毁了。
在广泛地整合时，我们需要弹性，但对于大量数据的加载，又必须有效率。笔者曾碰过需要转换数天，以 tera 为单位的数据量。而在转换过程中，一般只能干等，我们称此为数据处理的空窗期。空窗期越长，代表数据及时性越糟，延误下一个数据使用阶段，这是大家所不乐见的。

l           校正与一致化：凡是要转进数据仓储的数据应先求得格式与意义之一致，在不同的交易系统中，如公司人事数据可能用「男」、「女」来标示性别，但客户数据却可能用「0」、「1」，其它系统的性别字段还可能使用 True、False 或 Female、Male 等等，随着当时的系统开发人员喜好而定。但这在数据仓储内一定要一致。另外，某个系统的地址相关字段可能是五栏，另一个可能是六栏或四栏，但你的分析可能只需要三栏，因此转到数据仓储时需要合并或分割字段，更有甚者是原来三栏的数据可能要改成三列，或着反之。种种语意、格式、数据的正确性等诸多问题要在转换时期解决；这不是一件容易的事情。

l           周期性处理与管理：从在线交易系统将数据转进数据仓储是周期性的工作，绝不是累一次就可以一劳永逸，要让整个转换工作可以轻易地批次执行，如此系统才可能长久。另外，就笔者接触过的大型企业，其 DTS 封装从 50 多个到 700 多个都有，平均而言有 2~300 个封装，而参与使用该数据转换技术的工程师规模从 2~3 人到几十人。因此，如何妥善管理，其面向包含部署、备份、版本控管、灾难复原、教育训练...等，都需要考虑。

l           安全：按照安全的最小接触面原理，整合就有可能增加安全漏洞。由于是多种数据汇集，一定会碰上各系统的存取接口、网络流通、彼此系统的账号登入、机密性数据处理、经手人的授权、背景批次执行的账号、加解密数据的流程等问题。

微软的 SQL Server 小组将数据整合纳入该产品线需要满足的目标，其解决方案为何呢？

＠小标：需求无法满足，SSIS 应运而生

SQL Server 自 7.0 版首次导入的数据转换服务(Data Transformation Services)是一个容易上手的数据搬移和转换工具，让不同的资料来源与目的可以透过 ODBC/OLE DB 来互相转换资料。当你有各型数据格式或内容需要转换，将数据搬有运无时，DTS 是可轻易上手的工具。SQL Server 2000 之后，更是强化了它，使其成为最普遍的数据处理工具。

DTS 之所以称为数据转换(Data Transformation)，就是因为它主要的目的在「转换」，而不只是搬移数据。若仅搬移数据，光是 SQL Server 就不下五六种方法，如复制(Replication)、卸离/附加(Detach/Attach)、备份/还原(Backup/Restore)、Bulk Insert/Select Into/BCP、Log Shipping等等，都可以将数据从一处搬到另一处，但它们的特色大都是原封不动地搬移，且不整合其它非数据处理功能，只有 DTS 讲究转换与流程。

随着企业规模扩大、企业体内整体系统的数量递增、单一系统数据量累积，系统间数据整合之需求提升，以及上述几点难题让旧架构的 DTS 显得力不从心，微软必须以全新架构的 SSIS 来提供解决之道。

SQL Server 2005 放弃了之前相当成功的 DTS，完全重新设计与改写。在这个版本推出了 SQL Server Integration Services(SSIS) ，务求提升效能和增添更丰富的功能。而企图心从改变名称就可以看得出来，它不仅仅要做两个系统间的数据转换，还要提供多个系统间的数据整合。

SSIS 从核心重新开发，成为脱胎换骨的新产品。其中最大的变革之一是将流程(Integration Services run-time engine)与数据转换(Integration Services data flow engine)分成两大引擎来处理。这提供了较佳的流程控管与数据处理细节之可见度，同时增加了使用者自行撰写程序延伸 SSIS 的标准化与方便性。

新版本在封装执行的流程控管、错误处理、对象设定、除错、部署、执行记录、安全架构、效率，以及开发者透过微软版本控管机制(如 Visual SourceSafe VSS、Visual Studio Team System VSTS)控管 SSIS 封装的版本、自行以 .NET 语言延伸开发…等等方面都有长足的进步。若你有存放在不同系统的数据需要交换，例如从甲数据库转到乙档案格式，便可以考虑这个工具，倒是不一定要有 SQL Server 的参与。

SSIS 的开发小组让这个产品具有更开放的架构、更多功能、更具弹性、以及更高的执行效率。

＠小标：听听产品开发者怎么说

若你想要熟悉 SSIS，在此介绍一本好书：「Microsoft SQL Server 2005 Integration Services」，作者Kirk Haselden(网志地址：http://sqljunkies.com/weblog/knight_reign/) 本身就是 SSIS 的开发经理(Development Manager)，所以其著作应该算是官方说法了J

本书围绕在前述笔者所列的主题上；为你详加介绍这个全新的产品。书中除了说明 SSIS 的 what 和 how，也就是它所提供的某项功能是什么，以及如何使用外，也稍微谈了 why，叙述设计该项功能的缘由。

这本书不算入门书，但也不是深奥的进阶书，逐章读过后，应可以充分运用 SSIS。但你最好稍有用过微软的相关产品，如 DTS、SQL Server，写过 SQL 语言、简单的 Script、VB.NET 与 C#。当然，若你不想自己开发执行在 SSIS 平台上的对象，可以跳过本书的第六部份 Programming Integration Services，也就不需要熟悉 C# 语言了。

最后，笔者觉得稍为可惜的是本书未提供所有 SSIS 控制流程工作(control flow task)与数据流组件(data flow component)的说明，让我们在使用 SSIS 的某个对象时，可以如同翻阅字典一类的工具书，参照说明与简单的实例[1]。对于这些独立的对象，作者只举其大者，以范例说明，且略过了与 Analysis Services 整合的部份。

@小标：相关阅读

除了本书之外，若你觉得还需要其它的免费资源，可以参考以下的网址：

l           http://msdn.microsoft.com/sql/bi/integration/default.aspx：关于 SSIS 的官方网站，有非常多的资源。

l           http://blogs.msdn.com/ashvinis/、http://sqljunkies.com/WebLog/ashvinis/default.aspx：此网志的作者 Ashvini Sharma 是 SSIS 小组的 Development Lead。这里有一些不错的技术说明。可惜，他似乎不再维护这两个网志了。而上述 MSDN 网址提供了其它技术人员的网志连结(包含本书作者)，你都可以逛逛J

l           http://www.sqlis.com、http://www.sqldts.com：这两个姐妹站有许多关于 DTS 与 SSIS 的技术文件。

l           http://www.dbworld.com.tw：笔者在此处也撰写了大量关于 SSIS 的技术文章。

 

＠小标：数据转换的需求

当我们要把其它系统的数据如以往 dBase/Clipper/FoxPro 的 dbf、Excel 的 xls、csv、Access/Jet 的 mdb 乃至于 SQL Server/Oracle/DB 2/Teradata  等大型数据库，或是 html/XML 档案彼此互转时，往往需要搭配工具，辅之以自己动手撰写简单的指令码或程序。

除了弹性与效率两大重点外，这些转换的动作往往还特别需要注意错误处理，将有错误的记录另外存放起来供事后检视。因为老旧系统或是其它非数据库系统在设计时，大都没有注意到关连式数据库的正规划，以及一些相关的限制式(如 unique、default、check、primary key等)，所以数据内容很可能不会完全符合我们利用关系型数据库所定义的数据规格。而多个系统的数据汇聚时，还会发生数据重复、格式不一致、内容冲突、数据过时...等等问题。

上述情况在一般中大型的企业非常普遍，由于信息系统经年累月地开发与使用，各个单位与历代的资讯工程师对数据处理方式的偏好不同，加上信息技术日新月异，自然导致全公司的数据储存与使用方式千奇百怪。但若要让信息系统发挥最大效用，又往往要让这些系统能够沟通无阻，彼此简单地交换数据以提供整合方便的信息。

近几年来，数据仓储(Data warehouse)/在线分析(OLAP)/数据采矿(Data Mining)等系统开始流行，因为企业已能够利用各型数据库系统累积在线交易(OLTP)数据，而这些累积的数据大多潜藏着公司的营运指针或是客户的行为逻辑。为了找出其中的模式，必须将存在各交易子系统的数据；其中符合分析主题之内容，以一致的表现方式集中储存到数据仓储。

＠小标：困难处

这时第一个技术上的难题就是容易上手、有弹性且高效率的数据转换工具。其主要的困难点如下：

l           异质型资料来源：用来集中储存数据的数据仓储一般就是一个超大型关系型数据库，如专属的 NCR Teradata 或通用的 MS SQL Server...等，而提供转进数据的各交易系统却可能多所不同，设计师要同时了解多种数据存取机制并不容易。

l           商业逻辑运算与弹性：一般在汇入数据至目的端之前，可能会先完成分割、过滤、查阅(将代码转成值)、汇总、联集、排序...等动作。且在流程中辅之以优先级、条件判断、交易管理、数据库对象的维护、错误处理、讯息发布...等。
且随着数据来源增加，数据目的地用途变异与扩增，设计用来转换数据的对象要能容易修改与重用。

l           效率：弹性与效率基本上是两个互相冲突的面向，弹性代表着工具本身会做广泛地测试，让使用者简单设定完毕后，它会自己找到正确的处理解决方式，但这也代表需要较复杂的准备工作。而效率则需要以最简单直观的方式处理单一事情，这意涵着一点设定错误就全毁了。
在广泛地整合时，我们需要弹性，但对于大量数据的加载，又必须有效率。笔者曾碰过需要转换数天，以 tera 为单位的数据量。而在转换过程中，一般只能干等，我们称此为数据处理的空窗期。空窗期越长，代表数据及时性越糟，延误下一个数据使用阶段，这是大家所不乐见的。

l           校正与一致化：凡是要转进数据仓储的数据应先求得格式与意义之一致，在不同的交易系统中，如公司人事数据可能用「男」、「女」来标示性别，但客户数据却可能用「0」、「1」，其它系统的性别字段还可能使用 True、False 或 Female、Male 等等，随着当时的系统开发人员喜好而定。但这在数据仓储内一定要一致。另外，某个系统的地址相关字段可能是五栏，另一个可能是六栏或四栏，但你的分析可能只需要三栏，因此转到数据仓储时需要合并或分割字段，更有甚者是原来三栏的数据可能要改成三列，或着反之。种种语意、格式、数据的正确性等诸多问题要在转换时期解决；这不是一件容易的事情。

l           周期性处理与管理：从在线交易系统将数据转进数据仓储是周期性的工作，绝不是累一次就可以一劳永逸，要让整个转换工作可以轻易地批次执行，如此系统才可能长久。另外，就笔者接触过的大型企业，其 DTS 封装从 50 多个到 700 多个都有，平均而言有 2~300 个封装，而参与使用该数据转换技术的工程师规模从 2~3 人到几十人。因此，如何妥善管理，其面向包含部署、备份、版本控管、灾难复原、教育训练...等，都需要考虑。

l           安全：按照安全的最小接触面原理，整合就有可能增加安全漏洞。由于是多种数据汇集，一定会碰上各系统的存取接口、网络流通、彼此系统的账号登入、机密性数据处理、经手人的授权、背景批次执行的账号、加解密数据的流程等问题。

微软的 SQL Server 小组将数据整合纳入该产品线需要满足的目标，其解决方案为何呢？

＠小标：需求无法满足，SSIS 应运而生

SQL Server 自 7.0 版首次导入的数据转换服务(Data Transformation Services)是一个容易上手的数据搬移和转换工具，让不同的资料来源与目的可以透过 ODBC/OLE DB 来互相转换资料。当你有各型数据格式或内容需要转换，将数据搬有运无时，DTS 是可轻易上手的工具。SQL Server 2000 之后，更是强化了它，使其成为最普遍的数据处理工具。

DTS 之所以称为数据转换(Data Transformation)，就是因为它主要的目的在「转换」，而不只是搬移数据。若仅搬移数据，光是 SQL Server 就不下五六种方法，如复制(Replication)、卸离/附加(Detach/Attach)、备份/还原(Backup/Restore)、Bulk Insert/Select Into/BCP、Log Shipping等等，都可以将数据从一处搬到另一处，但它们的特色大都是原封不动地搬移，且不整合其它非数据处理功能，只有 DTS 讲究转换与流程。

随着企业规模扩大、企业体内整体系统的数量递增、单一系统数据量累积，系统间数据整合之需求提升，以及上述几点难题让旧架构的 DTS 显得力不从心，微软必须以全新架构的 SSIS 来提供解决之道。

SQL Server 2005 放弃了之前相当成功的 DTS，完全重新设计与改写。在这个版本推出了 SQL Server Integration Services(SSIS) ，务求提升效能和增添更丰富的功能。而企图心从改变名称就可以看得出来，它不仅仅要做两个系统间的数据转换，还要提供多个系统间的数据整合。

SSIS 从核心重新开发，成为脱胎换骨的新产品。其中最大的变革之一是将流程(Integration Services run-time engine)与数据转换(Integration Services data flow engine)分成两大引擎来处理。这提供了较佳的流程控管与数据处理细节之可见度，同时增加了使用者自行撰写程序延伸 SSIS 的标准化与方便性。

新版本在封装执行的流程控管、错误处理、对象设定、除错、部署、执行记录、安全架构、效率，以及开发者透过微软版本控管机制(如 Visual SourceSafe VSS、Visual Studio Team System VSTS)控管 SSIS 封装的版本、自行以 .NET 语言延伸开发…等等方面都有长足的进步。若你有存放在不同系统的数据需要交换，例如从甲数据库转到乙档案格式，便可以考虑这个工具，倒是不一定要有 SQL Server 的参与。

SSIS 的开发小组让这个产品具有更开放的架构、更多功能、更具弹性、以及更高的执行效率。

＠小标：听听产品开发者怎么说

若你想要熟悉 SSIS，在此介绍一本好书：「Microsoft SQL Server 2005 Integration Services」，作者Kirk Haselden(网志地址：http://sqljunkies.com/weblog/knight_reign/) 本身就是 SSIS 的开发经理(Development Manager)，所以其著作应该算是官方说法了J

本书围绕在前述笔者所列的主题上；为你详加介绍这个全新的产品。书中除了说明 SSIS 的 what 和 how，也就是它所提供的某项功能是什么，以及如何使用外，也稍微谈了 why，叙述设计该项功能的缘由。

这本书不算入门书，但也不是深奥的进阶书，逐章读过后，应可以充分运用 SSIS。但你最好稍有用过微软的相关产品，如 DTS、SQL Server，写过 SQL 语言、简单的 Script、VB.NET 与 C#。当然，若你不想自己开发执行在 SSIS 平台上的对象，可以跳过本书的第六部份 Programming Integration Services，也就不需要熟悉 C# 语言了。

最后，笔者觉得稍为可惜的是本书未提供所有 SSIS 控制流程工作(control flow task)与数据流组件(data flow component)的说明，让我们在使用 SSIS 的某个对象时，可以如同翻阅字典一类的工具书，参照说明与简单的实例[1]。对于这些独立的对象，作者只举其大者，以范例说明，且略过了与 Analysis Services 整合的部份。

@小标：相关阅读

除了本书之外，若你觉得还需要其它的免费资源，可以参考以下的网址：

l           http://msdn.microsoft.com/sql/bi/integration/default.aspx：关于 SSIS 的官方网站，有非常多的资源。

l           http://blogs.msdn.com/ashvinis/、http://sqljunkies.com/WebLog/ashvinis/default.aspx：此网志的作者 Ashvini Sharma 是 SSIS 小组的 Development Lead。这里有一些不错的技术说明。可惜，他似乎不再维护这两个网志了。而上述 MSDN 网址提供了其它技术人员的网志连结(包含本书作者)，你都可以逛逛J

l           http://www.sqlis.com、http://www.sqldts.com：这两个姐妹站有许多关于 DTS 与 SSIS 的技术文件。

l           http://www.dbworld.com.tw：笔者在此处也撰写了大量关于 SSIS 的技术文章。

 

＠小标：数据转换的需求

当我们要把其它系统的数据如以往 dBase/Clipper/FoxPro 的 dbf、Excel 的 xls、csv、Access/Jet 的 mdb 乃至于 SQL Server/Oracle/DB 2/Teradata  等大型数据库，或是 html/XML 档案彼此互转时，往往需要搭配工具，辅之以自己动手撰写简单的指令码或程序。

除了弹性与效率两大重点外，这些转换的动作往往还特别需要注意错误处理，将有错误的记录另外存放起来供事后检视。因为老旧系统或是其它非数据库系统在设计时，大都没有注意到关连式数据库的正规划，以及一些相关的限制式(如 unique、default、check、primary key等)，所以数据内容很可能不会完全符合我们利用关系型数据库所定义的数据规格。而多个系统的数据汇聚时，还会发生数据重复、格式不一致、内容冲突、数据过时...等等问题。

上述情况在一般中大型的企业非常普遍，由于信息系统经年累月地开发与使用，各个单位与历代的资讯工程师对数据处理方式的偏好不同，加上信息技术日新月异，自然导致全公司的数据储存与使用方式千奇百怪。但若要让信息系统发挥最大效用，又往往要让这些系统能够沟通无阻，彼此简单地交换数据以提供整合方便的信息。

近几年来，数据仓储(Data warehouse)/在线分析(OLAP)/数据采矿(Data Mining)等系统开始流行，因为企业已能够利用各型数据库系统累积在线交易(OLTP)数据，而这些累积的数据大多潜藏着公司的营运指针或是客户的行为逻辑。为了找出其中的模式，必须将存在各交易子系统的数据；其中符合分析主题之内容，以一致的表现方式集中储存到数据仓储。

＠小标：困难处

这时第一个技术上的难题就是容易上手、有弹性且高效率的数据转换工具。其主要的困难点如下：

l           异质型资料来源：用来集中储存数据的数据仓储一般就是一个超大型关系型数据库，如专属的 NCR Teradata 或通用的 MS SQL Server...等，而提供转进数据的各交易系统却可能多所不同，设计师要同时了解多种数据存取机制并不容易。

l           商业逻辑运算与弹性：一般在汇入数据至目的端之前，可能会先完成分割、过滤、查阅(将代码转成值)、汇总、联集、排序...等动作。且在流程中辅之以优先级、条件判断、交易管理、数据库对象的维护、错误处理、讯息发布...等。
且随着数据来源增加，数据目的地用途变异与扩增，设计用来转换数据的对象要能容易修改与重用。

l           效率：弹性与效率基本上是两个互相冲突的面向，弹性代表着工具本身会做广泛地测试，让使用者简单设定完毕后，它会自己找到正确的处理解决方式，但这也代表需要较复杂的准备工作。而效率则需要以最简单直观的方式处理单一事情，这意涵着一点设定错误就全毁了。
在广泛地整合时，我们需要弹性，但对于大量数据的加载，又必须有效率。笔者曾碰过需要转换数天，以 tera 为单位的数据量。而在转换过程中，一般只能干等，我们称此为数据处理的空窗期。空窗期越长，代表数据及时性越糟，延误下一个数据使用阶段，这是大家所不乐见的。

l           校正与一致化：凡是要转进数据仓储的数据应先求得格式与意义之一致，在不同的交易系统中，如公司人事数据可能用「男」、「女」来标示性别，但客户数据却可能用「0」、「1」，其它系统的性别字段还可能使用 True、False 或 Female、Male 等等，随着当时的系统开发人员喜好而定。但这在数据仓储内一定要一致。另外，某个系统的地址相关字段可能是五栏，另一个可能是六栏或四栏，但你的分析可能只需要三栏，因此转到数据仓储时需要合并或分割字段，更有甚者是原来三栏的数据可能要改成三列，或着反之。种种语意、格式、数据的正确性等诸多问题要在转换时期解决；这不是一件容易的事情。

l           周期性处理与管理：从在线交易系统将数据转进数据仓储是周期性的工作，绝不是累一次就可以一劳永逸，要让整个转换工作可以轻易地批次执行，如此系统才可能长久。另外，就笔者接触过的大型企业，其 DTS 封装从 50 多个到 700 多个都有，平均而言有 2~300 个封装，而参与使用该数据转换技术的工程师规模从 2~3 人到几十人。因此，如何妥善管理，其面向包含部署、备份、版本控管、灾难复原、教育训练...等，都需要考虑。

l           安全：按照安全的最小接触面原理，整合就有可能增加安全漏洞。由于是多种数据汇集，一定会碰上各系统的存取接口、网络流通、彼此系统的账号登入、机密性数据处理、经手人的授权、背景批次执行的账号、加解密数据的流程等问题。

微软的 SQL Server 小组将数据整合纳入该产品线需要满足的目标，其解决方案为何呢？

＠小标：需求无法满足，SSIS 应运而生

SQL Server 自 7.0 版首次导入的数据转换服务(Data Transformation Services)是一个容易上手的数据搬移和转换工具，让不同的资料来源与目的可以透过 ODBC/OLE DB 来互相转换资料。当你有各型数据格式或内容需要转换，将数据搬有运无时，DTS 是可轻易上手的工具。SQL Server 2000 之后，更是强化了它，使其成为最普遍的数据处理工具。

DTS 之所以称为数据转换(Data Transformation)，就是因为它主要的目的在「转换」，而不只是搬移数据。若仅搬移数据，光是 SQL Server 就不下五六种方法，如复制(Replication)、卸离/附加(Detach/Attach)、备份/还原(Backup/Restore)、Bulk Insert/Select Into/BCP、Log Shipping等等，都可以将数据从一处搬到另一处，但它们的特色大都是原封不动地搬移，且不整合其它非数据处理功能，只有 DTS 讲究转换与流程。

随着企业规模扩大、企业体内整体系统的数量递增、单一系统数据量累积，系统间数据整合之需求提升，以及上述几点难题让旧架构的 DTS 显得力不从心，微软必须以全新架构的 SSIS 来提供解决之道。

SQL Server 2005 放弃了之前相当成功的 DTS，完全重新设计与改写。在这个版本推出了 SQL Server Integration Services(SSIS) ，务求提升效能和增添更丰富的功能。而企图心从改变名称就可以看得出来，它不仅仅要做两个系统间的数据转换，还要提供多个系统间的数据整合。

SSIS 从核心重新开发，成为脱胎换骨的新产品。其中最大的变革之一是将流程(Integration Services run-time engine)与数据转换(Integration Services data flow engine)分成两大引擎来处理。这提供了较佳的流程控管与数据处理细节之可见度，同时增加了使用者自行撰写程序延伸 SSIS 的标准化与方便性。

新版本在封装执行的流程控管、错误处理、对象设定、除错、部署、执行记录、安全架构、效率，以及开发者透过微软版本控管机制(如 Visual SourceSafe VSS、Visual Studio Team System VSTS)控管 SSIS 封装的版本、自行以 .NET 语言延伸开发…等等方面都有长足的进步。若你有存放在不同系统的数据需要交换，例如从甲数据库转到乙档案格式，便可以考虑这个工具，倒是不一定要有 SQL Server 的参与。

SSIS 的开发小组让这个产品具有更开放的架构、更多功能、更具弹性、以及更高的执行效率。

＠小标：听听产品开发者怎么说

若你想要熟悉 SSIS，在此介绍一本好书：「Microsoft SQL Server 2005 Integration Services」，作者Kirk Haselden(网志地址：http://sqljunkies.com/weblog/knight_reign/) 本身就是 SSIS 的开发经理(Development Manager)，所以其著作应该算是官方说法了J

本书围绕在前述笔者所列的主题上；为你详加介绍这个全新的产品。书中除了说明 SSIS 的 what 和 how，也就是它所提供的某项功能是什么，以及如何使用外，也稍微谈了 why，叙述设计该项功能的缘由。

这本书不算入门书，但也不是深奥的进阶书，逐章读过后，应可以充分运用 SSIS。但你最好稍有用过微软的相关产品，如 DTS、SQL Server，写过 SQL 语言、简单的 Script、VB.NET 与 C#。当然，若你不想自己开发执行在 SSIS 平台上的对象，可以跳过本书的第六部份 Programming Integration Services，也就不需要熟悉 C# 语言了。

最后，笔者觉得稍为可惜的是本书未提供所有 SSIS 控制流程工作(control flow task)与数据流组件(data flow component)的说明，让我们在使用 SSIS 的某个对象时，可以如同翻阅字典一类的工具书，参照说明与简单的实例[1]。对于这些独立的对象，作者只举其大者，以范例说明，且略过了与 Analysis Services 整合的部份。

@小标：相关阅读

除了本书之外，若你觉得还需要其它的免费资源，可以参考以下的网址：

l           http://msdn.microsoft.com/sql/bi/integration/default.aspx：关于 SSIS 的官方网站，有非常多的资源。

l           http://blogs.msdn.com/ashvinis/、http://sqljunkies.com/WebLog/ashvinis/default.aspx：此网志的作者 Ashvini Sharma 是 SSIS 小组的 Development Lead。这里有一些不错的技术说明。可惜，他似乎不再维护这两个网志了。而上述 MSDN 网址提供了其它技术人员的网志连结(包含本书作者)，你都可以逛逛J

l           http://www.sqlis.com、http://www.sqldts.com：这两个姐妹站有许多关于 DTS 与 SSIS 的技术文件。

l           http://www.dbworld.com.tw：笔者在此处也撰写了大量关于 SSIS 的技术文章。

 

＠小标：数据转换的需求

当我们要把其它系统的数据如以往 dBase/Clipper/FoxPro 的 dbf、Excel 的 xls、csv、Access/Jet 的 mdb 乃至于 SQL Server/Oracle/DB 2/Teradata  等大型数据库，或是 html/XML 档案彼此互转时，往往需要搭配工具，辅之以自己动手撰写简单的指令码或程序。

除了弹性与效率两大重点外，这些转换的动作往往还特别需要注意错误处理，将有错误的记录另外存放起来供事后检视。因为老旧系统或是其它非数据库系统在设计时，大都没有注意到关连式数据库的正规划，以及一些相关的限制式(如 unique、default、check、primary key等)，所以数据内容很可能不会完全符合我们利用关系型数据库所定义的数据规格。而多个系统的数据汇聚时，还会发生数据重复、格式不一致、内容冲突、数据过时...等等问题。

上述情况在一般中大型的企业非常普遍，由于信息系统经年累月地开发与使用，各个单位与历代的资讯工程师对数据处理方式的偏好不同，加上信息技术日新月异，自然导致全公司的数据储存与使用方式千奇百怪。但若要让信息系统发挥最大效用，又往往要让这些系统能够沟通无阻，彼此简单地交换数据以提供整合方便的信息。

近几年来，数据仓储(Data warehouse)/在线分析(OLAP)/数据采矿(Data Mining)等系统开始流行，因为企业已能够利用各型数据库系统累积在线交易(OLTP)数据，而这些累积的数据大多潜藏着公司的营运指针或是客户的行为逻辑。为了找出其中的模式，必须将存在各交易子系统的数据；其中符合分析主题之内容，以一致的表现方式集中储存到数据仓储。

＠小标：困难处

这时第一个技术上的难题就是容易上手、有弹性且高效率的数据转换工具。其主要的困难点如下：

l           异质型资料来源：用来集中储存数据的数据仓储一般就是一个超大型关系型数据库，如专属的 NCR Teradata 或通用的 MS SQL Server...等，而提供转进数据的各交易系统却可能多所不同，设计师要同时了解多种数据存取机制并不容易。

l           商业逻辑运算与弹性：一般在汇入数据至目的端之前，可能会先完成分割、过滤、查阅(将代码转成值)、汇总、联集、排序...等动作。且在流程中辅之以优先级、条件判断、交易管理、数据库对象的维护、错误处理、讯息发布...等。
且随着数据来源增加，数据目的地用途变异与扩增，设计用来转换数据的对象要能容易修改与重用。

l           效率：弹性与效率基本上是两个互相冲突的面向，弹性代表着工具本身会做广泛地测试，让使用者简单设定完毕后，它会自己找到正确的处理解决方式，但这也代表需要较复杂的准备工作。而效率则需要以最简单直观的方式处理单一事情，这意涵着一点设定错误就全毁了。
在广泛地整合时，我们需要弹性，但对于大量数据的加载，又必须有效率。笔者曾碰过需要转换数天，以 tera 为单位的数据量。而在转换过程中，一般只能干等，我们称此为数据处理的空窗期。空窗期越长，代表数据及时性越糟，延误下一个数据使用阶段，这是大家所不乐见的。

l           校正与一致化：凡是要转进数据仓储的数据应先求得格式与意义之一致，在不同的交易系统中，如公司人事数据可能用「男」、「女」来标示性别，但客户数据却可能用「0」、「1」，其它系统的性别字段还可能使用 True、False 或 Female、Male 等等，随着当时的系统开发人员喜好而定。但这在数据仓储内一定要一致。另外，某个系统的地址相关字段可能是五栏，另一个可能是六栏或四栏，但你的分析可能只需要三栏，因此转到数据仓储时需要合并或分割字段，更有甚者是原来三栏的数据可能要改成三列，或着反之。种种语意、格式、数据的正确性等诸多问题要在转换时期解决；这不是一件容易的事情。

l           周期性处理与管理：从在线交易系统将数据转进数据仓储是周期性的工作，绝不是累一次就可以一劳永逸，要让整个转换工作可以轻易地批次执行，如此系统才可能长久。另外，就笔者接触过的大型企业，其 DTS 封装从 50 多个到 700 多个都有，平均而言有 2~300 个封装，而参与使用该数据转换技术的工程师规模从 2~3 人到几十人。因此，如何妥善管理，其面向包含部署、备份、版本控管、灾难复原、教育训练...等，都需要考虑。

l           安全：按照安全的最小接触面原理，整合就有可能增加安全漏洞。由于是多种数据汇集，一定会碰上各系统的存取接口、网络流通、彼此系统的账号登入、机密性数据处理、经手人的授权、背景批次执行的账号、加解密数据的流程等问题。

微软的 SQL Server 小组将数据整合纳入该产品线需要满足的目标，其解决方案为何呢？

＠小标：需求无法满足，SSIS 应运而生

SQL Server 自 7.0 版首次导入的数据转换服务(Data Transformation Services)是一个容易上手的数据搬移和转换工具，让不同的资料来源与目的可以透过 ODBC/OLE DB 来互相转换资料。当你有各型数据格式或内容需要转换，将数据搬有运无时，DTS 是可轻易上手的工具。SQL Server 2000 之后，更是强化了它，使其成为最普遍的数据处理工具。

DTS 之所以称为数据转换(Data Transformation)，就是因为它主要的目的在「转换」，而不只是搬移数据。若仅搬移数据，光是 SQL Server 就不下五六种方法，如复制(Replication)、卸离/附加(Detach/Attach)、备份/还原(Backup/Restore)、Bulk Insert/Select Into/BCP、Log Shipping等等，都可以将数据从一处搬到另一处，但它们的特色大都是原封不动地搬移，且不整合其它非数据处理功能，只有 DTS 讲究转换与流程。

随着企业规模扩大、企业体内整体系统的数量递增、单一系统数据量累积，系统间数据整合之需求提升，以及上述几点难题让旧架构的 DTS 显得力不从心，微软必须以全新架构的 SSIS 来提供解决之道。

SQL Server 2005 放弃了之前相当成功的 DTS，完全重新设计与改写。在这个版本推出了 SQL Server Integration Services(SSIS) ，务求提升效能和增添更丰富的功能。而企图心从改变名称就可以看得出来，它不仅仅要做两个系统间的数据转换，还要提供多个系统间的数据整合。

SSIS 从核心重新开发，成为脱胎换骨的新产品。其中最大的变革之一是将流程(Integration Services run-time engine)与数据转换(Integration Services data flow engine)分成两大引擎来处理。这提供了较佳的流程控管与数据处理细节之可见度，同时增加了使用者自行撰写程序延伸 SSIS 的标准化与方便性。

新版本在封装执行的流程控管、错误处理、对象设定、除错、部署、执行记录、安全架构、效率，以及开发者透过微软版本控管机制(如 Visual SourceSafe VSS、Visual Studio Team System VSTS)控管 SSIS 封装的版本、自行以 .NET 语言延伸开发…等等方面都有长足的进步。若你有存放在不同系统的数据需要交换，例如从甲数据库转到乙档案格式，便可以考虑这个工具，倒是不一定要有 SQL Server 的参与。

SSIS 的开发小组让这个产品具有更开放的架构、更多功能、更具弹性、以及更高的执行效率。

＠小标：听听产品开发者怎么说

若你想要熟悉 SSIS，在此介绍一本好书：「Microsoft SQL Server 2005 Integration Services」，作者Kirk Haselden(网志地址：http://sqljunkies.com/weblog/knight_reign/) 本身就是 SSIS 的开发经理(Development Manager)，所以其著作应该算是官方说法了J

本书围绕在前述笔者所列的主题上；为你详加介绍这个全新的产品。书中除了说明 SSIS 的 what 和 how，也就是它所提供的某项功能是什么，以及如何使用外，也稍微谈了 why，叙述设计该项功能的缘由。

这本书不算入门书，但也不是深奥的进阶书，逐章读过后，应可以充分运用 SSIS。但你最好稍有用过微软的相关产品，如 DTS、SQL Server，写过 SQL 语言、简单的 Script、VB.NET 与 C#。当然，若你不想自己开发执行在 SSIS 平台上的对象，可以跳过本书的第六部份 Programming Integration Services，也就不需要熟悉 C# 语言了。

最后，笔者觉得稍为可惜的是本书未提供所有 SSIS 控制流程工作(control flow task)与数据流组件(data flow component)的说明，让我们在使用 SSIS 的某个对象时，可以如同翻阅字典一类的工具书，参照说明与简单的实例[1]。对于这些独立的对象，作者只举其大者，以范例说明，且略过了与 Analysis Services 整合的部份。

@小标：相关阅读

除了本书之外，若你觉得还需要其它的免费资源，可以参考以下的网址：

l           http://msdn.microsoft.com/sql/bi/integration/default.aspx：关于 SSIS 的官方网站，有非常多的资源。

l           http://blogs.msdn.com/ashvinis/、http://sqljunkies.com/WebLog/ashvinis/default.aspx：此网志的作者 Ashvini Sharma 是 SSIS 小组的 Development Lead。这里有一些不错的技术说明。可惜，他似乎不再维护这两个网志了。而上述 MSDN 网址提供了其它技术人员的网志连结(包含本书作者)，你都可以逛逛J

l           http://www.sqlis.com、http://www.sqldts.com：这两个姐妹站有许多关于 DTS 与 SSIS 的技术文件。

l           http://www.dbworld.com.tw：笔者在此处也撰写了大量关于 SSIS 的技术文章。

 

＠小标：数据转换的需求

当我们要把其它系统的数据如以往 dBase/Clipper/FoxPro 的 dbf、Excel 的 xls、csv、Access/Jet 的 mdb 乃至于 SQL Server/Oracle/DB 2/Teradata  等大型数据库，或是 html/XML 档案彼此互转时，往往需要搭配工具，辅之以自己动手撰写简单的指令码或程序。

除了弹性与效率两大重点外，这些转换的动作往往还特别需要注意错误处理，将有错误的记录另外存放起来供事后检视。因为老旧系统或是其它非数据库系统在设计时，大都没有注意到关连式数据库的正规划，以及一些相关的限制式(如 unique、default、check、primary key等)，所以数据内容很可能不会完全符合我们利用关系型数据库所定义的数据规格。而多个系统的数据汇聚时，还会发生数据重复、格式不一致、内容冲突、数据过时...等等问题。

上述情况在一般中大型的企业非常普遍，由于信息系统经年累月地开发与使用，各个单位与历代的资讯工程师对数据处理方式的偏好不同，加上信息技术日新月异，自然导致全公司的数据储存与使用方式千奇百怪。但若要让信息系统发挥最大效用，又往往要让这些系统能够沟通无阻，彼此简单地交换数据以提供整合方便的信息。

近几年来，数据仓储(Data warehouse)/在线分析(OLAP)/数据采矿(Data Mining)等系统开始流行，因为企业已能够利用各型数据库系统累积在线交易(OLTP)数据，而这些累积的数据大多潜藏着公司的营运指针或是客户的行为逻辑。为了找出其中的模式，必须将存在各交易子系统的数据；其中符合分析主题之内容，以一致的表现方式集中储存到数据仓储。

＠小标：困难处

这时第一个技术上的难题就是容易上手、有弹性且高效率的数据转换工具。其主要的困难点如下：

l           异质型资料来源：用来集中储存数据的数据仓储一般就是一个超大型关系型数据库，如专属的 NCR Teradata 或通用的 MS SQL Server...等，而提供转进数据的各交易系统却可能多所不同，设计师要同时了解多种数据存取机制并不容易。

l           商业逻辑运算与弹性：一般在汇入数据至目的端之前，可能会先完成分割、过滤、查阅(将代码转成值)、汇总、联集、排序...等动作。且在流程中辅之以优先级、条件判断、交易管理、数据库对象的维护、错误处理、讯息发布...等。
且随着数据来源增加，数据目的地用途变异与扩增，设计用来转换数据的对象要能容易修改与重用。

l           效率：弹性与效率基本上是两个互相冲突的面向，弹性代表着工具本身会做广泛地测试，让使用者简单设定完毕后，它会自己找到正确的处理解决方式，但这也代表需要较复杂的准备工作。而效率则需要以最简单直观的方式处理单一事情，这意涵着一点设定错误就全毁了。
在广泛地整合时，我们需要弹性，但对于大量数据的加载，又必须有效率。笔者曾碰过需要转换数天，以 tera 为单位的数据量。而在转换过程中，一般只能干等，我们称此为数据处理的空窗期。空窗期越长，代表数据及时性越糟，延误下一个数据使用阶段，这是大家所不乐见的。

l           校正与一致化：凡是要转进数据仓储的数据应先求得格式与意义之一致，在不同的交易系统中，如公司人事数据可能用「男」、「女」来标示性别，但客户数据却可能用「0」、「1」，其它系统的性别字段还可能使用 True、False 或 Female、Male 等等，随着当时的系统开发人员喜好而定。但这在数据仓储内一定要一致。另外，某个系统的地址相关字段可能是五栏，另一个可能是六栏或四栏，但你的分析可能只需要三栏，因此转到数据仓储时需要合并或分割字段，更有甚者是原来三栏的数据可能要改成三列，或着反之。种种语意、格式、数据的正确性等诸多问题要在转换时期解决；这不是一件容易的事情。

l           周期性处理与管理：从在线交易系统将数据转进数据仓储是周期性的工作，绝不是累一次就可以一劳永逸，要让整个转换工作可以轻易地批次执行，如此系统才可能长久。另外，就笔者接触过的大型企业，其 DTS 封装从 50 多个到 700 多个都有，平均而言有 2~300 个封装，而参与使用该数据转换技术的工程师规模从 2~3 人到几十人。因此，如何妥善管理，其面向包含部署、备份、版本控管、灾难复原、教育训练...等，都需要考虑。

l           安全：按照安全的最小接触面原理，整合就有可能增加安全漏洞。由于是多种数据汇集，一定会碰上各系统的存取接口、网络流通、彼此系统的账号登入、机密性数据处理、经手人的授权、背景批次执行的账号、加解密数据的流程等问题。

微软的 SQL Server 小组将数据整合纳入该产品线需要满足的目标，其解决方案为何呢？

＠小标：需求无法满足，SSIS 应运而生

SQL Server 自 7.0 版首次导入的数据转换服务(Data Transformation Services)是一个容易上手的数据搬移和转换工具，让不同的资料来源与目的可以透过 ODBC/OLE DB 来互相转换资料。当你有各型数据格式或内容需要转换，将数据搬有运无时，DTS 是可轻易上手的工具。SQL Server 2000 之后，更是强化了它，使其成为最普遍的数据处理工具。

DTS 之所以称为数据转换(Data Transformation)，就是因为它主要的目的在「转换」，而不只是搬移数据。若仅搬移数据，光是 SQL Server 就不下五六种方法，如复制(Replication)、卸离/附加(Detach/Attach)、备份/还原(Backup/Restore)、Bulk Insert/Select Into/BCP、Log Shipping等等，都可以将数据从一处搬到另一处，但它们的特色大都是原封不动地搬移，且不整合其它非数据处理功能，只有 DTS 讲究转换与流程。

随着企业规模扩大、企业体内整体系统的数量递增、单一系统数据量累积，系统间数据整合之需求提升，以及上述几点难题让旧架构的 DTS 显得力不从心，微软必须以全新架构的 SSIS 来提供解决之道。

SQL Server 2005 放弃了之前相当成功的 DTS，完全重新设计与改写。在这个版本推出了 SQL Server Integration Services(SSIS) ，务求提升效能和增添更丰富的功能。而企图心从改变名称就可以看得出来，它不仅仅要做两个系统间的数据转换，还要提供多个系统间的数据整合。

SSIS 从核心重新开发，成为脱胎换骨的新产品。其中最大的变革之一是将流程(Integration Services run-time engine)与数据转换(Integration Services data flow engine)分成两大引擎来处理。这提供了较佳的流程控管与数据处理细节之可见度，同时增加了使用者自行撰写程序延伸 SSIS 的标准化与方便性。

新版本在封装执行的流程控管、错误处理、对象设定、除错、部署、执行记录、安全架构、效率，以及开发者透过微软版本控管机制(如 Visual SourceSafe VSS、Visual Studio Team System VSTS)控管 SSIS 封装的版本、自行以 .NET 语言延伸开发…等等方面都有长足的进步。若你有存放在不同系统的数据需要交换，例如从甲数据库转到乙档案格式，便可以考虑这个工具，倒是不一定要有 SQL Server 的参与。

SSIS 的开发小组让这个产品具有更开放的架构、更多功能、更具弹性、以及更高的执行效率。

＠小标：听听产品开发者怎么说

若你想要熟悉 SSIS，在此介绍一本好书：「Microsoft SQL Server 2005 Integration Services」，作者Kirk Haselden(网志地址：http://sqljunkies.com/weblog/knight_reign/) 本身就是 SSIS 的开发经理(Development Manager)，所以其著作应该算是官方说法了J

本书围绕在前述笔者所列的主题上；为你详加介绍这个全新的产品。书中除了说明 SSIS 的 what 和 how，也就是它所提供的某项功能是什么，以及如何使用外，也稍微谈了 why，叙述设计该项功能的缘由。

这本书不算入门书，但也不是深奥的进阶书，逐章读过后，应可以充分运用 SSIS。但你最好稍有用过微软的相关产品，如 DTS、SQL Server，写过 SQL 语言、简单的 Script、VB.NET 与 C#。当然，若你不想自己开发执行在 SSIS 平台上的对象，可以跳过本书的第六部份 Programming Integration Services，也就不需要熟悉 C# 语言了。

最后，笔者觉得稍为可惜的是本书未提供所有 SSIS 控制流程工作(control flow task)与数据流组件(data flow component)的说明，让我们在使用 SSIS 的某个对象时，可以如同翻阅字典一类的工具书，参照说明与简单的实例[1]。对于这些独立的对象，作者只举其大者，以范例说明，且略过了与 Analysis Services 整合的部份。

@小标：相关阅读

除了本书之外，若你觉得还需要其它的免费资源，可以参考以下的网址：

l           http://msdn.microsoft.com/sql/bi/integration/default.aspx：关于 SSIS 的官方网站，有非常多的资源。

l           http://blogs.msdn.com/ashvinis/、http://sqljunkies.com/WebLog/ashvinis/default.aspx：此网志的作者 Ashvini Sharma 是 SSIS 小组的 Development Lead。这里有一些不错的技术说明。可惜，他似乎不再维护这两个网志了。而上述 MSDN 网址提供了其它技术人员的网志连结(包含本书作者)，你都可以逛逛J

l           http://www.sqlis.com、http://www.sqldts.com：这两个姐妹站有许多关于 DTS 与 SSIS 的技术文件。

l           http://www.dbworld.com.tw：笔者在此处也撰写了大量关于 SSIS 的技术文章。

 

＠小标：数据转换的需求

当我们要把其它系统的数据如以往 dBase/Clipper/FoxPro 的 dbf、Excel 的 xls、csv、Access/Jet 的 mdb 乃至于 SQL Server/Oracle/DB 2/Teradata  等大型数据库，或是 html/XML 档案彼此互转时，往往需要搭配工具，辅之以自己动手撰写简单的指令码或程序。

除了弹性与效率两大重点外，这些转换的动作往往还特别需要注意错误处理，将有错误的记录另外存放起来供事后检视。因为老旧系统或是其它非数据库系统在设计时，大都没有注意到关连式数据库的正规划，以及一些相关的限制式(如 unique、default、check、primary key等)，所以数据内容很可能不会完全符合我们利用关系型数据库所定义的数据规格。而多个系统的数据汇聚时，还会发生数据重复、格式不一致、内容冲突、数据过时...等等问题。

上述情况在一般中大型的企业非常普遍，由于信息系统经年累月地开发与使用，各个单位与历代的资讯工程师对数据处理方式的偏好不同，加上信息技术日新月异，自然导致全公司的数据储存与使用方式千奇百怪。但若要让信息系统发挥最大效用，又往往要让这些系统能够沟通无阻，彼此简单地交换数据以提供整合方便的信息。

近几年来，数据仓储(Data warehouse)/在线分析(OLAP)/数据采矿(Data Mining)等系统开始流行，因为企业已能够利用各型数据库系统累积在线交易(OLTP)数据，而这些累积的数据大多潜藏着公司的营运指针或是客户的行为逻辑。为了找出其中的模式，必须将存在各交易子系统的数据；其中符合分析主题之内容，以一致的表现方式集中储存到数据仓储。

＠小标：困难处

这时第一个技术上的难题就是容易上手、有弹性且高效率的数据转换工具。其主要的困难点如下：

l           异质型资料来源：用来集中储存数据的数据仓储一般就是一个超大型关系型数据库，如专属的 NCR Teradata 或通用的 MS SQL Server...等，而提供转进数据的各交易系统却可能多所不同，设计师要同时了解多种数据存取机制并不容易。

l           商业逻辑运算与弹性：一般在汇入数据至目的端之前，可能会先完成分割、过滤、查阅(将代码转成值)、汇总、联集、排序...等动作。且在流程中辅之以优先级、条件判断、交易管理、数据库对象的维护、错误处理、讯息发布...等。
且随着数据来源增加，数据目的地用途变异与扩增，设计用来转换数据的对象要能容易修改与重用。

l           效率：弹性与效率基本上是两个互相冲突的面向，弹性代表着工具本身会做广泛地测试，让使用者简单设定完毕后，它会自己找到正确的处理解决方式，但这也代表需要较复杂的准备工作。而效率则需要以最简单直观的方式处理单一事情，这意涵着一点设定错误就全毁了。
在广泛地整合时，我们需要弹性，但对于大量数据的加载，又必须有效率。笔者曾碰过需要转换数天，以 tera 为单位的数据量。而在转换过程中，一般只能干等，我们称此为数据处理的空窗期。空窗期越长，代表数据及时性越糟，延误下一个数据使用阶段，这是大家所不乐见的。

l           校正与一致化：凡是要转进数据仓储的数据应先求得格式与意义之一致，在不同的交易系统中，如公司人事数据可能用「男」、「女」来标示性别，但客户数据却可能用「0」、「1」，其它系统的性别字段还可能使用 True、False 或 Female、Male 等等，随着当时的系统开发人员喜好而定。但这在数据仓储内一定要一致。另外，某个系统的地址相关字段可能是五栏，另一个可能是六栏或四栏，但你的分析可能只需要三栏，因此转到数据仓储时需要合并或分割字段，更有甚者是原来三栏的数据可能要改成三列，或着反之。种种语意、格式、数据的正确性等诸多问题要在转换时期解决；这不是一件容易的事情。

l           周期性处理与管理：从在线交易系统将数据转进数据仓储是周期性的工作，绝不是累一次就可以一劳永逸，要让整个转换工作可以轻易地批次执行，如此系统才可能长久。另外，就笔者接触过的大型企业，其 DTS 封装从 50 多个到 700 多个都有，平均而言有 2~300 个封装，而参与使用该数据转换技术的工程师规模从 2~3 人到几十人。因此，如何妥善管理，其面向包含部署、备份、版本控管、灾难复原、教育训练...等，都需要考虑。

l           安全：按照安全的最小接触面原理，整合就有可能增加安全漏洞。由于是多种数据汇集，一定会碰上各系统的存取接口、网络流通、彼此系统的账号登入、机密性数据处理、经手人的授权、背景批次执行的账号、加解密数据的流程等问题。

微软的 SQL Server 小组将数据整合纳入该产品线需要满足的目标，其解决方案为何呢？

＠小标：需求无法满足，SSIS 应运而生

SQL Server 自 7.0 版首次导入的数据转换服务(Data Transformation Services)是一个容易上手的数据搬移和转换工具，让不同的资料来源与目的可以透过 ODBC/OLE DB 来互相转换资料。当你有各型数据格式或内容需要转换，将数据搬有运无时，DTS 是可轻易上手的工具。SQL Server 2000 之后，更是强化了它，使其成为最普遍的数据处理工具。

DTS 之所以称为数据转换(Data Transformation)，就是因为它主要的目的在「转换」，而不只是搬移数据。若仅搬移数据，光是 SQL Server 就不下五六种方法，如复制(Replication)、卸离/附加(Detach/Attach)、备份/还原(Backup/Restore)、Bulk Insert/Select Into/BCP、Log Shipping等等，都可以将数据从一处搬到另一处，但它们的特色大都是原封不动地搬移，且不整合其它非数据处理功能，只有 DTS 讲究转换与流程。

随着企业规模扩大、企业体内整体系统的数量递增、单一系统数据量累积，系统间数据整合之需求提升，以及上述几点难题让旧架构的 DTS 显得力不从心，微软必须以全新架构的 SSIS 来提供解决之道。

SQL Server 2005 放弃了之前相当成功的 DTS，完全重新设计与改写。在这个版本推出了 SQL Server Integration Services(SSIS) ，务求提升效能和增添更丰富的功能。而企图心从改变名称就可以看得出来，它不仅仅要做两个系统间的数据转换，还要提供多个系统间的数据整合。

SSIS 从核心重新开发，成为脱胎换骨的新产品。其中最大的变革之一是将流程(Integration Services run-time engine)与数据转换(Integration Services data flow engine)分成两大引擎来处理。这提供了较佳的流程控管与数据处理细节之可见度，同时增加了使用者自行撰写程序延伸 SSIS 的标准化与方便性。

新版本在封装执行的流程控管、错误处理、对象设定、除错、部署、执行记录、安全架构、效率，以及开发者透过微软版本控管机制(如 Visual SourceSafe VSS、Visual Studio Team System VSTS)控管 SSIS 封装的版本、自行以 .NET 语言延伸开发…等等方面都有长足的进步。若你有存放在不同系统的数据需要交换，例如从甲数据库转到乙档案格式，便可以考虑这个工具，倒是不一定要有 SQL Server 的参与。

SSIS 的开发小组让这个产品具有更开放的架构、更多功能、更具弹性、以及更高的执行效率。

＠小标：听听产品开发者怎么说

若你想要熟悉 SSIS，在此介绍一本好书：「Microsoft SQL Server 2005 Integration Services」，作者Kirk Haselden(网志地址：http://sqljunkies.com/weblog/knight_reign/) 本身就是 SSIS 的开发经理(Development Manager)，所以其著作应该算是官方说法了J

本书围绕在前述笔者所列的主题上；为你详加介绍这个全新的产品。书中除了说明 SSIS 的 what 和 how，也就是它所提供的某项功能是什么，以及如何使用外，也稍微谈了 why，叙述设计该项功能的缘由。

这本书不算入门书，但也不是深奥的进阶书，逐章读过后，应可以充分运用 SSIS。但你最好稍有用过微软的相关产品，如 DTS、SQL Server，写过 SQL 语言、简单的 Script、VB.NET 与 C#。当然，若你不想自己开发执行在 SSIS 平台上的对象，可以跳过本书的第六部份 Programming Integration Services，也就不需要熟悉 C# 语言了。

最后，笔者觉得稍为可惜的是本书未提供所有 SSIS 控制流程工作(control flow task)与数据流组件(data flow component)的说明，让我们在使用 SSIS 的某个对象时，可以如同翻阅字典一类的工具书，参照说明与简单的实例[1]。对于这些独立的对象，作者只举其大者，以范例说明，且略过了与 Analysis Services 整合的部份。

@小标：相关阅读

除了本书之外，若你觉得还需要其它的免费资源，可以参考以下的网址：

l           http://msdn.microsoft.com/sql/bi/integration/default.aspx：关于 SSIS 的官方网站，有非常多的资源。

l           http://blogs.msdn.com/ashvinis/、http://sqljunkies.com/WebLog/ashvinis/default.aspx：此网志的作者 Ashvini Sharma 是 SSIS 小组的 Development Lead。这里有一些不错的技术说明。可惜，他似乎不再维护这两个网志了。而上述 MSDN 网址提供了其它技术人员的网志连结(包含本书作者)，你都可以逛逛J

l           http://www.sqlis.com、http://www.sqldts.com：这两个姐妹站有许多关于 DTS 与 SSIS 的技术文件。

l           http://www.dbworld.com.tw：笔者在此处也撰写了大量关于 SSIS 的技术文章。

 

＠小标：数据转换的需求

当我们要把其它系统的数据如以往 dBase/Clipper/FoxPro 的 dbf、Excel 的 xls、csv、Access/Jet 的 mdb 乃至于 SQL Server/Oracle/DB 2/Teradata  等大型数据库，或是 html/XML 档案彼此互转时，往往需要搭配工具，辅之以自己动手撰写简单的指令码或程序。

除了弹性与效率两大重点外，这些转换的动作往往还特别需要注意错误处理，将有错误的记录另外存放起来供事后检视。因为老旧系统或是其它非数据库系统在设计时，大都没有注意到关连式数据库的正规划，以及一些相关的限制式(如 unique、default、check、primary key等)，所以数据内容很可能不会完全符合我们利用关系型数据库所定义的数据规格。而多个系统的数据汇聚时，还会发生数据重复、格式不一致、内容冲突、数据过时...等等问题。

上述情况在一般中大型的企业非常普遍，由于信息系统经年累月地开发与使用，各个单位与历代的资讯工程师对数据处理方式的偏好不同，加上信息技术日新月异，自然导致全公司的数据储存与使用方式千奇百怪。但若要让信息系统发挥最大效用，又往往要让这些系统能够沟通无阻，彼此简单地交换数据以提供整合方便的信息。

近几年来，数据仓储(Data warehouse)/在线分析(OLAP)/数据采矿(Data Mining)等系统开始流行，因为企业已能够利用各型数据库系统累积在线交易(OLTP)数据，而这些累积的数据大多潜藏着公司的营运指针或是客户的行为逻辑。为了找出其中的模式，必须将存在各交易子系统的数据；其中符合分析主题之内容，以一致的表现方式集中储存到数据仓储。

＠小标：困难处

这时第一个技术上的难题就是容易上手、有弹性且高效率的数据转换工具。其主要的困难点如下：

l           异质型资料来源：用来集中储存数据的数据仓储一般就是一个超大型关系型数据库，如专属的 NCR Teradata 或通用的 MS SQL Server...等，而提供转进数据的各交易系统却可能多所不同，设计师要同时了解多种数据存取机制并不容易。

l           商业逻辑运算与弹性：一般在汇入数据至目的端之前，可能会先完成分割、过滤、查阅(将代码转成值)、汇总、联集、排序...等动作。且在流程中辅之以优先级、条件判断、交易管理、数据库对象的维护、错误处理、讯息发布...等。
且随着数据来源增加，数据目的地用途变异与扩增，设计用来转换数据的对象要能容易修改与重用。

l           效率：弹性与效率基本上是两个互相冲突的面向，弹性代表着工具本身会做广泛地测试，让使用者简单设定完毕后，它会自己找到正确的处理解决方式，但这也代表需要较复杂的准备工作。而效率则需要以最简单直观的方式处理单一事情，这意涵着一点设定错误就全毁了。
在广泛地整合时，我们需要弹性，但对于大量数据的加载，又必须有效率。笔者曾碰过需要转换数天，以 tera 为单位的数据量。而在转换过程中，一般只能干等，我们称此为数据处理的空窗期。空窗期越长，代表数据及时性越糟，延误下一个数据使用阶段，这是大家所不乐见的。

l           校正与一致化：凡是要转进数据仓储的数据应先求得格式与意义之一致，在不同的交易系统中，如公司人事数据可能用「男」、「女」来标示性别，但客户数据却可能用「0」、「1」，其它系统的性别字段还可能使用 True、False 或 Female、Male 等等，随着当时的系统开发人员喜好而定。但这在数据仓储内一定要一致。另外，某个系统的地址相关字段可能是五栏，另一个可能是六栏或四栏，但你的分析可能只需要三栏，因此转到数据仓储时需要合并或分割字段，更有甚者是原来三栏的数据可能要改成三列，或着反之。种种语意、格式、数据的正确性等诸多问题要在转换时期解决；这不是一件容易的事情。

l           周期性处理与管理：从在线交易系统将数据转进数据仓储是周期性的工作，绝不是累一次就可以一劳永逸，要让整个转换工作可以轻易地批次执行，如此系统才可能长久。另外，就笔者接触过的大型企业，其 DTS 封装从 50 多个到 700 多个都有，平均而言有 2~300 个封装，而参与使用该数据转换技术的工程师规模从 2~3 人到几十人。因此，如何妥善管理，其面向包含部署、备份、版本控管、灾难复原、教育训练...等，都需要考虑。

l           安全：按照安全的最小接触面原理，整合就有可能增加安全漏洞。由于是多种数据汇集，一定会碰上各系统的存取接口、网络流通、彼此系统的账号登入、机密性数据处理、经手人的授权、背景批次执行的账号、加解密数据的流程等问题。

微软的 SQL Server 小组将数据整合纳入该产品线需要满足的目标，其解决方案为何呢？

＠小标：需求无法满足，SSIS 应运而生

SQL Server 自 7.0 版首次导入的数据转换服务(Data Transformation Services)是一个容易上手的数据搬移和转换工具，让不同的资料来源与目的可以透过 ODBC/OLE DB 来互相转换资料。当你有各型数据格式或内容需要转换，将数据搬有运无时，DTS 是可轻易上手的工具。SQL Server 2000 之后，更是强化了它，使其成为最普遍的数据处理工具。

DTS 之所以称为数据转换(Data Transformation)，就是因为它主要的目的在「转换」，而不只是搬移数据。若仅搬移数据，光是 SQL Server 就不下五六种方法，如复制(Replication)、卸离/附加(Detach/Attach)、备份/还原(Backup/Restore)、Bulk Insert/Select Into/BCP、Log Shipping等等，都可以将数据从一处搬到另一处，但它们的特色大都是原封不动地搬移，且不整合其它非数据处理功能，只有 DTS 讲究转换与流程。

随着企业规模扩大、企业体内整体系统的数量递增、单一系统数据量累积，系统间数据整合之需求提升，以及上述几点难题让旧架构的 DTS 显得力不从心，微软必须以全新架构的 SSIS 来提供解决之道。

SQL Server 2005 放弃了之前相当成功的 DTS，完全重新设计与改写。在这个版本推出了 SQL Server Integration Services(SSIS) ，务求提升效能和增添更丰富的功能。而企图心从改变名称就可以看得出来，它不仅仅要做两个系统间的数据转换，还要提供多个系统间的数据整合。

SSIS 从核心重新开发，成为脱胎换骨的新产品。其中最大的变革之一是将流程(Integration Services run-time engine)与数据转换(Integration Services data flow engine)分成两大引擎来处理。这提供了较佳的流程控管与数据处理细节之可见度，同时增加了使用者自行撰写程序延伸 SSIS 的标准化与方便性。

新版本在封装执行的流程控管、错误处理、对象设定、除错、部署、执行记录、安全架构、效率，以及开发者透过微软版本控管机制(如 Visual SourceSafe VSS、Visual Studio Team System VSTS)控管 SSIS 封装的版本、自行以 .NET 语言延伸开发…等等方面都有长足的进步。若你有存放在不同系统的数据需要交换，例如从甲数据库转到乙档案格式，便可以考虑这个工具，倒是不一定要有 SQL Server 的参与。

SSIS 的开发小组让这个产品具有更开放的架构、更多功能、更具弹性、以及更高的执行效率。

＠小标：听听产品开发者怎么说

若你想要熟悉 SSIS，在此介绍一本好书：「Microsoft SQL Server 2005 Integration Services」，作者Kirk Haselden(网志地址：http://sqljunkies.com/weblog/knight_reign/) 本身就是 SSIS 的开发经理(Development Manager)，所以其著作应该算是官方说法了J

本书围绕在前述笔者所列的主题上；为你详加介绍这个全新的产品。书中除了说明 SSIS 的 what 和 how，也就是它所提供的某项功能是什么，以及如何使用外，也稍微谈了 why，叙述设计该项功能的缘由。

这本书不算入门书，但也不是深奥的进阶书，逐章读过后，应可以充分运用 SSIS。但你最好稍有用过微软的相关产品，如 DTS、SQL Server，写过 SQL 语言、简单的 Script、VB.NET 与 C#。当然，若你不想自己开发执行在 SSIS 平台上的对象，可以跳过本书的第六部份 Programming Integration Services，也就不需要熟悉 C# 语言了。

最后，笔者觉得稍为可惜的是本书未提供所有 SSIS 控制流程工作(control flow task)与数据流组件(data flow component)的说明，让我们在使用 SSIS 的某个对象时，可以如同翻阅字典一类的工具书，参照说明与简单的实例[1]。对于这些独立的对象，作者只举其大者，以范例说明，且略过了与 Analysis Services 整合的部份。

@小标：相关阅读

除了本书之外，若你觉得还需要其它的免费资源，可以参考以下的网址：

l           http://msdn.microsoft.com/sql/bi/integration/default.aspx：关于 SSIS 的官方网站，有非常多的资源。

l           http://blogs.msdn.com/ashvinis/、http://sqljunkies.com/WebLog/ashvinis/default.aspx：此网志的作者 Ashvini Sharma 是 SSIS 小组的 Development Lead。这里有一些不错的技术说明。可惜，他似乎不再维护这两个网志了。而上述 MSDN 网址提供了其它技术人员的网志连结(包含本书作者)，你都可以逛逛J

l           http://www.sqlis.com、http://www.sqldts.com：这两个姐妹站有许多关于 DTS 与 SSIS 的技术文件。

l           http://www.dbworld.com.tw：笔者在此处也撰写了大量关于 SSIS 的技术文章。

 

＠小标：数据转换的需求

当我们要把其它系统的数据如以往 dBase/Clipper/FoxPro 的 dbf、Excel 的 xls、csv、Access/Jet 的 mdb 乃至于 SQL Server/Oracle/DB 2/Teradata  等大型数据库，或是 html/XML 档案彼此互转时，往往需要搭配工具，辅之以自己动手撰写简单的指令码或程序。

除了弹性与效率两大重点外，这些转换的动作往往还特别需要注意错误处理，将有错误的记录另外存放起来供事后检视。因为老旧系统或是其它非数据库系统在设计时，大都没有注意到关连式数据库的正规划，以及一些相关的限制式(如 unique、default、check、primary key等)，所以数据内容很可能不会完全符合我们利用关系型数据库所定义的数据规格。而多个系统的数据汇聚时，还会发生数据重复、格式不一致、内容冲突、数据过时...等等问题。

上述情况在一般中大型的企业非常普遍，由于信息系统经年累月地开发与使用，各个单位与历代的资讯工程师对数据处理方式的偏好不同，加上信息技术日新月异，自然导致全公司的数据储存与使用方式千奇百怪。但若要让信息系统发挥最大效用，又往往要让这些系统能够沟通无阻，彼此简单地交换数据以提供整合方便的信息。

近几年来，数据仓储(Data warehouse)/在线分析(OLAP)/数据采矿(Data Mining)等系统开始流行，因为企业已能够利用各型数据库系统累积在线交易(OLTP)数据，而这些累积的数据大多潜藏着公司的营运指针或是客户的行为逻辑。为了找出其中的模式，必须将存在各交易子系统的数据；其中符合分析主题之内容，以一致的表现方式集中储存到数据仓储。

＠小标：困难处

这时第一个技术上的难题就是容易上手、有弹性且高效率的数据转换工具。其主要的困难点如下：

l           异质型资料来源：用来集中储存数据的数据仓储一般就是一个超大型关系型数据库，如专属的 NCR Teradata 或通用的 MS SQL Server...等，而提供转进数据的各交易系统却可能多所不同，设计师要同时了解多种数据存取机制并不容易。

l           商业逻辑运算与弹性：一般在汇入数据至目的端之前，可能会先完成分割、过滤、查阅(将代码转成值)、汇总、联集、排序...等动作。且在流程中辅之以优先级、条件判断、交易管理、数据库对象的维护、错误处理、讯息发布...等。
且随着数据来源增加，数据目的地用途变异与扩增，设计用来转换数据的对象要能容易修改与重用。

l           效率：弹性与效率基本上是两个互相冲突的面向，弹性代表着工具本身会做广泛地测试，让使用者简单设定完毕后，它会自己找到正确的处理解决方式，但这也代表需要较复杂的准备工作。而效率则需要以最简单直观的方式处理单一事情，这意涵着一点设定错误就全毁了。
在广泛地整合时，我们需要弹性，但对于大量数据的加载，又必须有效率。笔者曾碰过需要转换数天，以 tera 为单位的数据量。而在转换过程中，一般只能干等，我们称此为数据处理的空窗期。空窗期越长，代表数据及时性越糟，延误下一个数据使用阶段，这是大家所不乐见的。

l           校正与一致化：凡是要转进数据仓储的数据应先求得格式与意义之一致，在不同的交易系统中，如公司人事数据可能用「男」、「女」来标示性别，但客户数据却可能用「0」、「1」，其它系统的性别字段还可能使用 True、False 或 Female、Male 等等，随着当时的系统开发人员喜好而定。但这在数据仓储内一定要一致。另外，某个系统的地址相关字段可能是五栏，另一个可能是六栏或四栏，但你的分析可能只需要三栏，因此转到数据仓储时需要合并或分割字段，更有甚者是原来三栏的数据可能要改成三列，或着反之。种种语意、格式、数据的正确性等诸多问题要在转换时期解决；这不是一件容易的事情。

l           周期性处理与管理：从在线交易系统将数据转进数据仓储是周期性的工作，绝不是累一次就可以一劳永逸，要让整个转换工作可以轻易地批次执行，如此系统才可能长久。另外，就笔者接触过的大型企业，其 DTS 封装从 50 多个到 700 多个都有，平均而言有 2~300 个封装，而参与使用该数据转换技术的工程师规模从 2~3 人到几十人。因此，如何妥善管理，其面向包含部署、备份、版本控管、灾难复原、教育训练...等，都需要考虑。

l           安全：按照安全的最小接触面原理，整合就有可能增加安全漏洞。由于是多种数据汇集，一定会碰上各系统的存取接口、网络流通、彼此系统的账号登入、机密性数据处理、经手人的授权、背景批次执行的账号、加解密数据的流程等问题。

微软的 SQL Server 小组将数据整合纳入该产品线需要满足的目标，其解决方案为何呢？

＠小标：需求无法满足，SSIS 应运而生

SQL Server 自 7.0 版首次导入的数据转换服务(Data Transformation Services)是一个容易上手的数据搬移和转换工具，让不同的资料来源与目的可以透过 ODBC/OLE DB 来互相转换资料。当你有各型数据格式或内容需要转换，将数据搬有运无时，DTS 是可轻易上手的工具。SQL Server 2000 之后，更是强化了它，使其成为最普遍的数据处理工具。

DTS 之所以称为数据转换(Data Transformation)，就是因为它主要的目的在「转换」，而不只是搬移数据。若仅搬移数据，光是 SQL Server 就不下五六种方法，如复制(Replication)、卸离/附加(Detach/Attach)、备份/还原(Backup/Restore)、Bulk Insert/Select Into/BCP、Log Shipping等等，都可以将数据从一处搬到另一处，但它们的特色大都是原封不动地搬移，且不整合其它非数据处理功能，只有 DTS 讲究转换与流程。

随着企业规模扩大、企业体内整体系统的数量递增、单一系统数据量累积，系统间数据整合之需求提升，以及上述几点难题让旧架构的 DTS 显得力不从心，微软必须以全新架构的 SSIS 来提供解决之道。

SQL Server 2005 放弃了之前相当成功的 DTS，完全重新设计与改写。在这个版本推出了 SQL Server Integration Services(SSIS) ，务求提升效能和增添更丰富的功能。而企图心从改变名称就可以看得出来，它不仅仅要做两个系统间的数据转换，还要提供多个系统间的数据整合。

SSIS 从核心重新开发，成为脱胎换骨的新产品。其中最大的变革之一是将流程(Integration Services run-time engine)与数据转换(Integration Services data flow engine)分成两大引擎来处理。这提供了较佳的流程控管与数据处理细节之可见度，同时增加了使用者自行撰写程序延伸 SSIS 的标准化与方便性。

新版本在封装执行的流程控管、错误处理、对象设定、除错、部署、执行记录、安全架构、效率，以及开发者透过微软版本控管机制(如 Visual SourceSafe VSS、Visual Studio Team System VSTS)控管 SSIS 封装的版本、自行以 .NET 语言延伸开发…等等方面都有长足的进步。若你有存放在不同系统的数据需要交换，例如从甲数据库转到乙档案格式，便可以考虑这个工具，倒是不一定要有 SQL Server 的参与。

SSIS 的开发小组让这个产品具有更开放的架构、更多功能、更具弹性、以及更高的执行效率。

＠小标：听听产品开发者怎么说

若你想要熟悉 SSIS，在此介绍一本好书：「Microsoft SQL Server 2005 Integration Services」，作者Kirk Haselden(网志地址：http://sqljunkies.com/weblog/knight_reign/) 本身就是 SSIS 的开发经理(Development Manager)，所以其著作应该算是官方说法了J

本书围绕在前述笔者所列的主题上；为你详加介绍这个全新的产品。书中除了说明 SSIS 的 what 和 how，也就是它所提供的某项功能是什么，以及如何使用外，也稍微谈了 why，叙述设计该项功能的缘由。

这本书不算入门书，但也不是深奥的进阶书，逐章读过后，应可以充分运用 SSIS。但你最好稍有用过微软的相关产品，如 DTS、SQL Server，写过 SQL 语言、简单的 Script、VB.NET 与 C#。当然，若你不想自己开发执行在 SSIS 平台上的对象，可以跳过本书的第六部份 Programming Integration Services，也就不需要熟悉 C# 语言了。

最后，笔者觉得稍为可惜的是本书未提供所有 SSIS 控制流程工作(control flow task)与数据流组件(data flow component)的说明，让我们在使用 SSIS 的某个对象时，可以如同翻阅字典一类的工具书，参照说明与简单的实例[1]。对于这些独立的对象，作者只举其大者，以范例说明，且略过了与 Analysis Services 整合的部份。

@小标：相关阅读

除了本书之外，若你觉得还需要其它的免费资源，可以参考以下的网址：

l           http://msdn.microsoft.com/sql/bi/integration/default.aspx：关于 SSIS 的官方网站，有非常多的资源。

l           http://blogs.msdn.com/ashvinis/、http://sqljunkies.com/WebLog/ashvinis/default.aspx：此网志的作者 Ashvini Sharma 是 SSIS 小组的 Development Lead。这里有一些不错的技术说明。可惜，他似乎不再维护这两个网志了。而上述 MSDN 网址提供了其它技术人员的网志连结(包含本书作者)，你都可以逛逛J

l           http://www.sqlis.com、http://www.sqldts.com：这两个姐妹站有许多关于 DTS 与 SSIS 的技术文件。

l           http://www.dbworld.com.tw：笔者在此处也撰写了大量关于 SSIS 的技术文章。

 

＠小标：数据转换的需求

当我们要把其它系统的数据如以往 dBase/Clipper/FoxPro 的 dbf、Excel 的 xls、csv、Access/Jet 的 mdb 乃至于 SQL Server/Oracle/DB 2/Teradata  等大型数据库，或是 html/XML 档案彼此互转时，往往需要搭配工具，辅之以自己动手撰写简单的指令码或程序。

除了弹性与效率两大重点外，这些转换的动作往往还特别需要注意错误处理，将有错误的记录另外存放起来供事后检视。因为老旧系统或是其它非数据库系统在设计时，大都没有注意到关连式数据库的正规划，以及一些相关的限制式(如 unique、default、check、primary key等)，所以数据内容很可能不会完全符合我们利用关系型数据库所定义的数据规格。而多个系统的数据汇聚时，还会发生数据重复、格式不一致、内容冲突、数据过时...等等问题。

上述情况在一般中大型的企业非常普遍，由于信息系统经年累月地开发与使用，各个单位与历代的资讯工程师对数据处理方式的偏好不同，加上信息技术日新月异，自然导致全公司的数据储存与使用方式千奇百怪。但若要让信息系统发挥最大效用，又往往要让这些系统能够沟通无阻，彼此简单地交换数据以提供整合方便的信息。

近几年来，数据仓储(Data warehouse)/在线分析(OLAP)/数据采矿(Data Mining)等系统开始流行，因为企业已能够利用各型数据库系统累积在线交易(OLTP)数据，而这些累积的数据大多潜藏着公司的营运指针或是客户的行为逻辑。为了找出其中的模式，必须将存在各交易子系统的数据；其中符合分析主题之内容，以一致的表现方式集中储存到数据仓储。

＠小标：困难处

这时第一个技术上的难题就是容易上手、有弹性且高效率的数据转换工具。其主要的困难点如下：

l           异质型资料来源：用来集中储存数据的数据仓储一般就是一个超大型关系型数据库，如专属的 NCR Teradata 或通用的 MS SQL Server...等，而提供转进数据的各交易系统却可能多所不同，设计师要同时了解多种数据存取机制并不容易。

l           商业逻辑运算与弹性：一般在汇入数据至目的端之前，可能会先完成分割、过滤、查阅(将代码转成值)、汇总、联集、排序...等动作。且在流程中辅之以优先级、条件判断、交易管理、数据库对象的维护、错误处理、讯息发布...等。
且随着数据来源增加，数据目的地用途变异与扩增，设计用来转换数据的对象要能容易修改与重用。

l           效率：弹性与效率基本上是两个互相冲突的面向，弹性代表着工具本身会做广泛地测试，让使用者简单设定完毕后，它会自己找到正确的处理解决方式，但这也代表需要较复杂的准备工作。而效率则需要以最简单直观的方式处理单一事情，这意涵着一点设定错误就全毁了。
在广泛地整合时，我们需要弹性，但对于大量数据的加载，又必须有效率。笔者曾碰过需要转换数天，以 tera 为单位的数据量。而在转换过程中，一般只能干等，我们称此为数据处理的空窗期。空窗期越长，代表数据及时性越糟，延误下一个数据使用阶段，这是大家所不乐见的。

l           校正与一致化：凡是要转进数据仓储的数据应先求得格式与意义之一致，在不同的交易系统中，如公司人事数据可能用「男」、「女」来标示性别，但客户数据却可能用「0」、「1」，其它系统的性别字段还可能使用 True、False 或 Female、Male 等等，随着当时的系统开发人员喜好而定。但这在数据仓储内一定要一致。另外，某个系统的地址相关字段可能是五栏，另一个可能是六栏或四栏，但你的分析可能只需要三栏，因此转到数据仓储时需要合并或分割字段，更有甚者是原来三栏的数据可能要改成三列，或着反之。种种语意、格式、数据的正确性等诸多问题要在转换时期解决；这不是一件容易的事情。

l           周期性处理与管理：从在线交易系统将数据转进数据仓储是周期性的工作，绝不是累一次就可以一劳永逸，要让整个转换工作可以轻易地批次执行，如此系统才可能长久。另外，就笔者接触过的大型企业，其 DTS 封装从 50 多个到 700 多个都有，平均而言有 2~300 个封装，而参与使用该数据转换技术的工程师规模从 2~3 人到几十人。因此，如何妥善管理，其面向包含部署、备份、版本控管、灾难复原、教育训练...等，都需要考虑。

l           安全：按照安全的最小接触面原理，整合就有可能增加安全漏洞。由于是多种数据汇集，一定会碰上各系统的存取接口、网络流通、彼此系统的账号登入、机密性数据处理、经手人的授权、背景批次执行的账号、加解密数据的流程等问题。

微软的 SQL Server 小组将数据整合纳入该产品线需要满足的目标，其解决方案为何呢？

＠小标：需求无法满足，SSIS 应运而生

SQL Server 自 7.0 版首次导入的数据转换服务(Data Transformation Services)是一个容易上手的数据搬移和转换工具，让不同的资料来源与目的可以透过 ODBC/OLE DB 来互相转换资料。当你有各型数据格式或内容需要转换，将数据搬有运无时，DTS 是可轻易上手的工具。SQL Server 2000 之后，更是强化了它，使其成为最普遍的数据处理工具。

DTS 之所以称为数据转换(Data Transformation)，就是因为它主要的目的在「转换」，而不只是搬移数据。若仅搬移数据，光是 SQL Server 就不下五六种方法，如复制(Replication)、卸离/附加(Detach/Attach)、备份/还原(Backup/Restore)、Bulk Insert/Select Into/BCP、Log Shipping等等，都可以将数据从一处搬到另一处，但它们的特色大都是原封不动地搬移，且不整合其它非数据处理功能，只有 DTS 讲究转换与流程。

随着企业规模扩大、企业体内整体系统的数量递增、单一系统数据量累积，系统间数据整合之需求提升，以及上述几点难题让旧架构的 DTS 显得力不从心，微软必须以全新架构的 SSIS 来提供解决之道。

SQL Server 2005 放弃了之前相当成功的 DTS，完全重新设计与改写。在这个版本推出了 SQL Server Integration Services(SSIS) ，务求提升效能和增添更丰富的功能。而企图心从改变名称就可以看得出来，它不仅仅要做两个系统间的数据转换，还要提供多个系统间的数据整合。

SSIS 从核心重新开发，成为脱胎换骨的新产品。其中最大的变革之一是将流程(Integration Services run-time engine)与数据转换(Integration Services data flow engine)分成两大引擎来处理。这提供了较佳的流程控管与数据处理细节之可见度，同时增加了使用者自行撰写程序延伸 SSIS 的标准化与方便性。

新版本在封装执行的流程控管、错误处理、对象设定、除错、部署、执行记录、安全架构、效率，以及开发者透过微软版本控管机制(如 Visual SourceSafe VSS、Visual Studio Team System VSTS)控管 SSIS 封装的版本、自行以 .NET 语言延伸开发…等等方面都有长足的进步。若你有存放在不同系统的数据需要交换，例如从甲数据库转到乙档案格式，便可以考虑这个工具，倒是不一定要有 SQL Server 的参与。

SSIS 的开发小组让这个产品具有更开放的架构、更多功能、更具弹性、以及更高的执行效率。

＠小标：听听产品开发者怎么说

若你想要熟悉 SSIS，在此介绍一本好书：「Microsoft SQL Server 2005 Integration Services」，作者Kirk Haselden(网志地址：http://sqljunkies.com/weblog/knight_reign/) 本身就是 SSIS 的开发经理(Development Manager)，所以其著作应该算是官方说法了J

本书围绕在前述笔者所列的主题上；为你详加介绍这个全新的产品。书中除了说明 SSIS 的 what 和 how，也就是它所提供的某项功能是什么，以及如何使用外，也稍微谈了 why，叙述设计该项功能的缘由。

这本书不算入门书，但也不是深奥的进阶书，逐章读过后，应可以充分运用 SSIS。但你最好稍有用过微软的相关产品，如 DTS、SQL Server，写过 SQL 语言、简单的 Script、VB.NET 与 C#。当然，若你不想自己开发执行在 SSIS 平台上的对象，可以跳过本书的第六部份 Programming Integration Services，也就不需要熟悉 C# 语言了。

最后，笔者觉得稍为可惜的是本书未提供所有 SSIS 控制流程工作(control flow task)与数据流组件(data flow component)的说明，让我们在使用 SSIS 的某个对象时，可以如同翻阅字典一类的工具书，参照说明与简单的实例[1]。对于这些独立的对象，作者只举其大者，以范例说明，且略过了与 Analysis Services 整合的部份。

@小标：相关阅读

除了本书之外，若你觉得还需要其它的免费资源，可以参考以下的网址：

l           http://msdn.microsoft.com/sql/bi/integration/default.aspx：关于 SSIS 的官方网站，有非常多的资源。

l           http://blogs.msdn.com/ashvinis/、http://sqljunkies.com/WebLog/ashvinis/default.aspx：此网志的作者 Ashvini Sharma 是 SSIS 小组的 Development Lead。这里有一些不错的技术说明。可惜，他似乎不再维护这两个网志了。而上述 MSDN 网址提供了其它技术人员的网志连结(包含本书作者)，你都可以逛逛J

l           http://www.sqlis.com、http://www.sqldts.com：这两个姐妹站有许多关于 DTS 与 SSIS 的技术文件。

l           http://www.dbworld.com.tw：笔者在此处也撰写了大量关于 SSIS 的技术文章。