数据仓库更新的新策略--工作流

第一篇：数据仓库更新的新策略--工作流

数据仓库更新的新策略--工作流

1．概述

数据仓库作为一种新技术，主要是为决策支持系统和OLAP应用提供软件架构。它从异构和分布式数据源中收集数据，这些数据首先被聚合，然后按照OLAP所定义的组织标准进行定制。数据仓库的结构能够通过一种分层存储的方式加以定义。这种方式涉及到的存储形式包括从底层的数据源到高度的聚合数据（数据集市）。在这两种存储形式之间，按照OLAP程序的要求，还存在一些其他不同的存储形式。其中之一就是对操作型数据的存储，操作型数据是以单一和干净的方式来表征数据源中的数据。企业级数据仓库（CDW）则包含高度聚合的数据，并且被组织成多维表的形式。从每个数据源中抽取的数据可以存储在中间数据容器中。显然，这种分层存储方式只是一种逻辑上的表示方式，它体现了从数据源到数据集市的数据流动过程。所有这些存储形式都不一定要具体实现，如果确实需要的话，他们也只能形成同一数据库的不同层面而已。

图1显示了一种典型的数据仓库结构。这只是一个逻辑视图，它的具体实现，不同厂家有自己不同的数据仓库产品解决方案。数据抽取和数据清洗的实现与每个数据源有关，对于不同的数据源提供有统一的或定制的工具。同样，数据的一致性（多数据源清洗）既可以与数据集成（多数据源操作）分开也可以合并到数据集成中进行。高级别的数据聚合工作可以看成一个计算技术的集合，这个集合的范围涵盖从简单的统计函数到高级的数据挖掘算法。对于不同的数据集市来说，数据定制技术是不同的。关键在于决策者想要看到的数据的详尽程度。

数据仓库更新是一个非常重要的过程，它决定了数据采集和数据聚合的实效性。确实，向决策者提供的数据的质量与以下因素有关。首先，与数据仓库系统在合理的时间内将数据从数据源转换到数据集市的能力有关。其次，与数据仓库对数据源中信息发生变化的敏感程度有关。大部分的设计考虑主要集中在对数据结构的选取和数据的更新技术上，这里的数据更新技术指的是对数据仓库更新的优化策略。

在对数据仓库更新的理解方面在相关的文献上存在着很大的误区。确实，这个过程经常被简化为视图维护问题或与数据导入混为一谈。本文的目的之一就是指出数据

图1 数据仓库的体系结构

仓库的更新要比数据视图的维护问题要复杂的多，也不同于数据导入过程。我们把数据更新过程定义为一个工作流，组成工作流的具体活动类型取决于数据抽取和数据清洗所应用的产品。与其配套的触发事件则与应用的范围和对数据刷新频率的要求相关。

以下几节将分别描述数据更新过程的任务，并阐明在工作流中如何组织这些任务。第2节主要讨论数据更新过程与数据导入及视图维护的不同。第3节定义了工作流的标准形式并结合一个工作流的例子逻辑展现了数据仓库更新过程。第4节按照工作流的设计模式定义了数据仓库更新过程的语义。第5节归纳了本文的主要思想，并涉及到一些实现方面的观点

2．视图维护，数据导入和数据刷新

数据仓库中的数据更新过程通常容易和数据仓库初始阶段所作的数据导入或对数据仓库中具体视图的更新相混淆。这两种想法都是错误的。下面几段详细阐述数据更新和数据导入，数据更新和视图维护之间的区别和不同。

数据导入和数据更新

数据仓库的数据导入过程存在于数据仓库建立初期，是数据仓库建立的关键阶段，它主要完成对数据仓库中内容的初始计算。数据导入过程是一个全局过程，这个过程分为四个步骤（如图2所示）：1，准备；2，集成；3，高度聚合；4，定制。第一步由各个数据源完成，它主要包括数据抽取，数据清洗，可能还包括数据归档（在数据清洗前后）等阶段。对历史数据进行归档，其作用在两个方面：一，在具用不同刷新频率的数据源之间进行同步；二，用于一些特定的临时查询。第二步由数据的一致性处理和数据的集成处理组成。它包括对从异构数据源中提取的数据进行一致性处理（多数据源清洗）和对从ODS（操作型数据库）的基表（基视图）中获取的数据进行清洗等两个部分。第三步由一些对派生于基视图的聚合视的计算构成。在操作型数据库（ODS）中的数据是一些基本数据，他们具有程度很低的聚合程度，而企业级数据仓库（CDW）中存放的数据通常是用聚合函数统计过的高度聚合的数据。第四步由对用户视进行派生和定制活动组成，最后生成数据集市。数据定制指的是根据用户的需求形成不同的立方体，并向用户展示不同的侧面。

图2 数据导入过程

数据导入阶段的主要特点是它处于数据仓库设计项目的最开始阶段。在数据导入之前，对用户来说，数据仓库是不存在的。因此，在反映时间上就不存在什么限制。但是，相反，对数据源来说数据导入阶段要求数据源一直可用。

描述数据导入阶段的数据流是定义数据更新过程的基础，但是与之相对应的工作流却是不同的。数据更新的工作流是动态的，能够跟踪用户的需求和检测数据源的变化，而数据导入过程的工作流是静态的，由用户的当前要求和当前数据源的状况所定义的。

数据更新过程和数据导入过程的主要区别有以下几点：首先，对数据更新过程来说，组成其的各个活动（准备，集成，聚集和定制）之间完全是异步进行的，第二，就准备活动本身来说，其过程也可以是高度并行的，每个数据源都有自己的可用窗口和抽取策略。同步由数据集成活动来做。另外的一个不同之处在于数据源的可用性上。数据导入阶段要求数据源长期可用，而数据更新阶段对使用数据源的操作应用程序的负载要求比较轻。它要求每一个数据源具有确定的存取频率和一个严格限制的持续期。最后，对数据更新过程来说，对数据的存取有严格的反映时间限制，而对数据导入过程来说，要求就没有那么严格。确实，对用户来说，在初始数据导入前，数据仓库是不存在的。因此，其计算时间则被包含在项目的设计期间内。而在初始数据导入后，数据就变成可以看见的，应当满足用户对数据的使用，存取和刷新的要求。

视图维护和数据更新

在数据更新过程期间，对数据变化的传播是通过一系列独立的活动来完成的。这些活动包含对存储在ODS和CDW中的视图的维护。视图维护阶段是指由于给定的数据源的改变而引起存储在ODS和CDW中的一系列视图的改变，这些改变导致视图的更新。这个阶段（视图维护阶段）是一个经典的具体视图维护问题，但是，在数据仓库中，扩展到聚合视中的改变在数据源中并不一定发生，但是予处理结果是通过其他更新活动像数据清洗和多数据源数据一致性处理等来执行的。

在数据库界，对数据视图维护的问题已经进行了大量的研究。这个领域所做的主要工作被收集在[2]和[6]中。大部分的工作都集中到对一套具体的视图的维护工作上，这套视图派生于一套基本的关系表，当基本关系被修改时便引起视图的改变。视图维护所涉及到的工作主要有：

● 自我维护性：自我维护性是针对这样一套视图集的：视图集V对于基本关系的改变是自我维护的，指的是不需要查询基本关系就可完成V中视图的改变。（也就是说通过存储在具体视中的信息和变化的实例就足以完成视图的维护）

● 一致性和有效性更新转换：对于每个单独的视图都有相应的算法来调度更新转换过程，但是，考虑到视图间的相互依赖关系，及视图间会导致可能的矛盾。出于这个目的，导入一些辅助视图来促进更新转换和加强自我维护性。

数据仓库主要关注的是视图集的自我维护性。存储在数据仓库中的视图集必须是全局可自我维护的，这一点是大家都认同的。这样做的原因是避免对操作型数据源中的常规活动负载过重。

像上节描述的一样，对数据仓库更新的研究主要集中在对具体视图的更新转换上。关于这个题目，已经发表了很多文章。但是，很少有人致力于将数据更新过程作为一个整体（像前面定义的）来研究。我们认为视图维护问题只是整个数据更新过程的一步，其它几步包括数据清洗，数据一致，数据定制，如果需要的话还有数据归档。另一方面，抽取和清洗策略对不同数据源来说是不一样的，就像数据更新转换过程对不同的用户视是不同的一样。所以，数据仓库更新过程不能仅限于视图维护过程。

综上所述。我们认为数据更新过程是一个复杂的系统，它由一系列异步和并发活动构成，当然，这些活动必须是可监控的。另外，数据更新过程也是一个基于事件驱动的系统，是不断跟踪变化，动态反映数据源和用户要求演变的系统。用户，数据仓库管理员和数据源管理员可以施加一些限制，例如，数据的刷新率，ODS和CDW的空间限制，对数据源的存取频率等。对所有数据仓库应用，所有的数据仓库用户或整个数据仓库生命周期来说，不存在简单和同一的数据更新策略。

3．数据更新过程是一个工作流

工作流是一套相关活动的集合，这些活动既可是手动的，也可以是自动的。工作流的概念已经在不同的领域得到应用，像商业过程模型，企业操作模型和数据库事物模型等。根据应用的领域，活动和活动间的联系可以使用相应的说明语言来描述，像状态图，Petri nets或活动规则等。尽管对工作流的应用和表示方式多种多样，但是，大部分工作流用户却或多或少地倾向于接受Workflow Coalition对工作流所做的概念和说明。工作流系统一般具有高度的灵活性，有可递归分解和合成的活动，和对工作流过程进行动态重组等特性。对数据仓库来说，这些特点是非常有用的。因为，不同的数据仓库厂商所提供的产品是不同的，也就是说，组成数据仓库的活动的功能和范围由于产品的不同其差别是很大的，而这正是工作流所擅长的。

在下面几小节，我们将展示数据仓库是如何被定义为工作流的。根据用户的需求，数据源和数据仓库的限制等要求，我们将提出不同的方案，并以此来说明将工作流引入数据仓库的优点。同时，我们将说明这些方案能够全程跟踪和监控用户需求和限制的任何变化，并完成相应的更新操作。

3.1 数据更新过程的工作流

数据更新的目标是反映数据源的变化，并将这些变化导入到数据仓库中。这个导入和转换行为可以通过一系列独立的活动来完成（抽取，清洗，集成等）。按照用户对数据更新过程的语义以及他对所获取的数据的要求，这些活动可以以不同的方式进行组织。同时，这些活动的顺序和它们执行的上下文环境也定义了语义并影响质量。顺序和上下文环境来源于对视图的分析，数据源的限制和用户在质量方面的要求三个方面。在下面几节中，我们将阐述数据更新活动和他们是如何被组织成工作流的。然后，我们给出不同的工作流方案，并进一步说明数据更新是一个动态和演变的过程。最后，我们将概括不同的想法，并提出一个合理的数据更新方案。

数据更新活动

就数据流来说，数据更新过程类似数据导入过程。但是，数据导入过程是数据仓库的大规模的数据导入，而数据更新只是捕获数据源所发生的改变并将这些改变转换到数据仓库的各个存储层次中。在准备阶段，从每个数据源中抽取数据，这些数据是自上次抽取以来，数据源所发生变化的数据。至于导入，数据应在集成前被清洗和归档（可能的话）。数据集成阶段主要是完成对来自多数据源的改变数据进行一致性处理，并将其导入到ODS中。聚合阶段主要是利用这些数据变化重新对各层次聚合视进行增量计算。定制阶段主要是将这些经过概括的数据装载到数据集市中。和数据导入阶段一样，这是一个逻辑的分解过程，其具体实现对不同的数据仓库产品来说是不同的。这种逻辑视图具有对数据更新过程的跟踪能力。图3显示了数据更新过程的活动和相应事件的一个样例。

图3 数据更新过程的一般工作流

活动协调

在工作流系统中，活动是由控制流调配的，这些控制流可能是过程提交提示，代理发布的电子邮件，临时事件或其它触发事件等。在数据更新过程中，活动的协调工作是通过一个范围广泛的事件类型来做的。

我们能够定义几种不同的事件类型，这些事件类型可以触发和同步数据更新活动。它们可以是临时事件，末端事件或其它用户定义的事件。根据不同的更新策略，可以选取合适的事件类型集以取得正确的同步级别。

数据更新工作流的活动只有在它们被触发时才可以执行，触发的条件依据输入数据源的当前状况。例如，如果数据抽取是周期性触发的，那么它实际上只有在数据源日志发生有效变化的时候才执行。如果清洗过程是在数据抽取后立即触发的，那么它实际上只在抽取过程已经收集了数据源的变化数据后才执行。因此，我们认为每个活动的输入数据源的状态是有效执行这个活动的必须要考虑的条件之一。

在数据更新过程的工作流中，不同活动可能具有不同的起源和不同的语义，因此，数据更新策略和活动的实际行为是相互独立的。然而，在操作级别，一些活动是可以合并的（例如，数据抽取和数据清洗）另外一些是可以分解的（如集成）。工作流系统的灵活性允许动态地裁剪数据更新活动和相关的协调事件。

另外，还有一种方式描述工作流和其触发策略。确实，如果不考虑外部事件像临时事件或不同活动的末端事件的话，我们可以把数据改变作为事件。因此，数据更新工作流的每一个输入存储源都可以考虑成一个事件队列，由它来触发相应的活动。然而，为了能够描述不同的更新策略，这种方法需要一种参数化的同步机制，以便在正确的时机触发相应的活动。有两种方法可以作这个工作。一种是引入复合事件，例如可以将数据改变事件和临时事件进行组合。另外一种是给数据存储单元加锁，并在一个活动或活动集决定提交后去锁。但是，对某些需要长期同步机制的数据仓库来说，后一种方式显然是无效的。

工作流的角色

在数据更新工作流中主要涉及两个角色：人为角色，主要定义要求，限制和策略；另外一种是计算机，主要处理活动。我们把人为角色分为用户，数据仓库管理员，和数据源管理员。把计算机分为数据源管理系统，用于数据仓库和数据集市的数据库管理系统，封装和媒介等。对于只关注活动及其相关联系的数据更新工作流来说，是不必需要角色的。3.2 定义数据更新策略

为了阐明不同的工作流策略，我们考虑使用下面这个例子。这个例子涉及三个国家的电信单据分别用S1，S2，S3三个关系表示。每个关系都有相同的模式定义：（#PC,date,duration,cost）。聚合视V的模式为（avg-duration,avg-cost,country）。V在数据仓库中定义。视图V提取最近6个月和上述三个关系相关的三个国家中每一个电话的平均通话时间和花费。我们假定视图V的构造遵循以前的解释。在数据准备期间，包含在每个数据源中的最近6个月的数据被清洗（例如，所有的收费单元被转换为欧元）。

然后，在数据集成阶段，通过联合每个数据源的数据和产生附加的属性（country）来建造基本关系R，R的模式为（date,duration,cost,country）。最后，通过聚合计算产生视图（图4）。

图4：更新策略的第一个案例

我们也能够用同样的数据源和类似的视图定义另一个更新策略。这个策略镜像的是每天的平均通话时间和花费而不是6个月的。这导致数据抽取，数据清洗，集成和转换的频率的改变。图5给出了这样一个可能的策略。数据源抽取的频率是由数据源管理员指定的。数据源3是长期可用的。

图5：更新策略的第二个案例

当更新活动是一个长期活动或DWA想要在活动间加入校验过程时，临时事件或活动终止可以被用来对整个更新过程进行同步控制。通常，质量要求也可施加一定的同步策略。例如，如果用户想要最新的数据，这意味着数据源的每一次更新都应当尽可能的反映到视图中。因此，这就决定了同步的策略：数据源的每一次改变都触发抽取，当语义相关时触发集成，在每个数据源提交后，转换活动立即在集成活动后将相应变化导入到视图中，并且在数据集市中定制用户视图。

更新模式

数据更新过程存在不同的处理模式，主要模式类型有：

● 客户驱动的数据更新

客户驱动的数据更新模式指的是以用户需求为条件所触发的数据更新过程。它主要关注的是如何将数据从ODS转换到数据仓库中的聚合视图中去。这种基于需求的策略既可以适用于所有的聚合视，也可以仅用于和日期查询相关的数据刷新中。

● 数据源驱动的数据更新

数据源驱动的数据更新描述的是由于数据源发生变化而触发的数据更新。这种更新主要涉及到数据准备阶段。就数据源来说，我们可以利用数据源之间的独立性来制定不同的准备策略。例如，一些数据源和清洗过程相关，而另外一些却不是这样。一些数据源需要抽取数据的历史记录，而其它的没有这个要求。对某些数据源来说，清洗过程可以在抽取期间的空闲时间做，对另外一些则可能在抽取后或基于这些变化的历史来做。对不同的数据源来说，触发抽取的事件也是不同的。可以定义不同的事件，像临时事件（定期或固定时间），在检测数据源发生改变后或基于集成过程的要求等。

● ODS驱动的数据更新

ODS驱动的数据更新指的是由数据仓库系统自动监控的数据更新过程。这部分主要涉及数据集成阶段。它在一个同步点被触发，这个同步点定义在准备阶段结束后。数据集成通常被考虑成一个整体，涉及到同一时刻所有的数据源改变。在这种情况下，它只能被一个外部事件触发，这个事件可以是临时事件或最后一个数据源的准备阶段结束事件。和每个数据源的准备阶段的结束一起考虑的话，那么数据集成也可以被序列化，也就是说，一个数据源的清洗完成后就对其抽取进行集成。ODS也能监控准备阶段和聚合阶段，主要是通过产生相关的事件，由这些事件触发这些阶段的活动。

在很简单的情况下，前两个方式中的任一个均可作为一种单独的策略。在复杂的情况下，就需要有和数据源的数量或高级聚合视图数量同样多的策略。介于两者之间，对于前面所说的四个阶段，可能有与之相对应的四个不同的策略。对于某些给定的用户视图，可能使用客户驱动的策略（拉策略），而对于其它视图则可能使用ODS驱动策略（推策略）。类似，一些数据源要求用拉策略，而其它的用推测略。

策略的选取既和语义参数有关，也决定于执行数据更新活动（抽取，清洗，集成）所能使用的工具。一些抽取工具也能在空闲时做清洗工作，而一些集成器也能立即将变化一直转换到高级视图中。在图3所示的是数据更新的一个逻辑视图，它显示了主要的活动和触发它们的潜在的事件类型。

4、数据更新过程的语义

正像我们在以前说明的方案中所展示的那样，视图的定义并不能有效地解决数据更新的语义问题。确实，用来定义视图的查询不能够说明这个视图是否建立在历史数据上，这个历史数据是如何采样的，对于给定的数据源的变化是每小时还是每周进行集成。以及当集成不同数据源的变化时，应当采用什么样的数据时间戳。另外，视图定义不包括定义在清洗过程中的具体的过滤条件，例如为特定属性选取同样的措施，对一些属性值四舍五入，或删除一些隐秘数据等。因此，即使基于相同的视图定义，数据更新过程也会产生不同的结果，而这和外部参数有关，这些参数必须独立确定，和定义视图的查询无关。

视图V在t时刻的查询结果取决于两个主要的参数，这两个参数和数据仓库的数据更新策略有关。第一个参数是每个数据源的抽取性能。例如，数据源s1在发生改变时可以立即进行抽取，而s2的改变只在每个月的最后一个晚上被捕获。这就决定了数据源变化的实效性,因此影响到数据的刷新率。另外，它也影响了数据的一致性，因为在视图中可能产生时间差：计算的平均数可能将s1的最新刷新数据和s2的旧数据进行集成。第二个参数是计算视图变化所需要的时间。

实际上，这两个参数可以被重复多次，就像在数据源和数据视图之间存在许多中间存储器一样。例如，考虑存储准备阶段结果的情况，则第一个参数刻画了数据集成过程存取数据准备阶段结果的时刻。因此，如果数据准备阶段的每个结果只能在月末才可用的话，那么数据集成过程也只能在月末执行，结果视图将只在每个月末作出对数据源变化的反映。

另外一个参数则影响了视图V的查询结果。定义了包容在每个数据源中的数据的实现。例如，数据源s1可以在每个周末更新，而数据郓s2在每个月末的前两天更新。如果视图V的一个查询在一个月的第二个周末触发的话，从这个月开始到现在与数据源s2有关的国家的电话的情况将不可能在视图V中得到反映。所以，第二个参数的值决定了数据仓库所反映的视图状态和现实世界中视图状态存在不同之处。因为这个参数是固定的，处于数据仓库应用程序的控制之外（它实际上是数据源操作应用程序的一部分），我们将不会对它加以考虑。

上述讨论已经揭示了数据更新过程是如何依靠某些参数，具体视图选取的独立性和这些参数是怎样影响数据更新过程的语义的。它也揭示了建立一个与应用要求（例如，数据刷新，查询和视图的计算时间，数据精度）相关的有效的更新策略所倚赖的不同参数，这些参数和下列因数有关：

● 数据源的限制（例如，可用的窗口数，变化频率）

● 数据仓库系统的限制（例如，存储空间限制，功能限制）

综上所述，基于以上的样例和讨论，我门可以得出如下结论：

数据更新过程的操作语义可以被定义成为一个全部设计考虑的集合，这些考虑用来向用户提供相关联的数据，并履行质量控制的要求。

其中，这些考虑中一些来源于数据导入，其它则和数据更新本身相关。来源于数据导入的第一个设计考虑集中在视图的定义和数据源和数据集市之间的数据流的构成。第二个考虑是导入活动的语义即清洗规则，集成规则等。

和数据更新语义相关的的设计考虑是这样一些因素，它们决定以下信息：

● 整个过程中每一个更新任务发生的时刻

● 不同更新任务的同步方式

● 与相应任务相关的共享数据的可视化方式

这些考虑是通过以下定义来说明的：

● 按元任务进行的数据更新过程的分解（例如，某些确定数据源的清洗，来源于两个不同数据源的两个给定变化的局部集成和在一个统一任务中对另外一个数据源的检测和清洗）

● 任务排序

● 触发任务的事件，这些事件用来调整更新过程的频率，不同的频率，数据的刷新和精度的差别是相当大的。

5、关于实现的几点想法

就实现的问题来说，可以考虑不同的解决方案。数据更新过程依据工作流的概念性定义，自然导致采用在市面上通用的工作流系统的控制下的实现方式，如果这些系统提供各种事件类型和更新方案所需的所有的特点的话。另一个解决方案，我们在描述组成在一定操作语义下执行的活动规则时已经提到。我们选择的基本原则是灵活性和活动规则的动态演化性。确实，更新策略不可能一下定义所有的东西，它需要不断跟踪用户需求，这些需求可以导致具体视图定义的改变或具体的品质方面的改变。当品质方面的实际价值为了适应数据仓库反馈信息的变化或实现这种变化的技术而有所减慢时，这种活动规则也必须能够对此进行演化。因此为了掌握数据仓库的复杂性和演化性，提供一种灵活的技术，它能够满足复杂性和演化性的要求，是非常重要的。而这正是活动规则所要提供的。在欧洲数据仓库研究项目的DWG[5]的相关研究中已经开发并发布了一个协议。但是，活动规则并不能用来替代工作流。工作流是更新过程的基本逻辑结构，而活动规则是工作流思想的具体操作实现。

6、结论

本文分析了数据仓库应用中的更新过程。阐明了数据更新过程不只局限于视图维护过程，也不是数据导入古成。通过一个简单的。例子，我们已经说明数据更新过程能够基本上被看作是一个工作流。我们定义了工作流的不同任务阶段，展现了它们在不同更新方案中的组织方式，这些不同的更新方案导致不同的更新语义。我们也着重强调了不同的设计考虑对更新语义的影响。我们也说明了这些考虑是怎样和一些品质因素像数据刷新率和一些限制像数据源的可用性和可存取性相关的。

第二篇：数据仓库总结

数据仓库系统与传统数据库系统的区别

数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。

数据挖掘与传统分析工具不同的是数据挖掘使用的是基于发现的方法，运用模式匹配和其它算法决定数据之间的重要联系。

数据挖掘的步骤

1.描述数据---计算统计变量（比如平均值、均方差等），再用图表或图片直观的表示出来，进而可以看出一些变量之间的相关性。

2.历史数据建立一个预言模型，然后再用另外一些数据对这个模型进行测试。

3.验证你的模型

数据挖掘与传统数据分析方法区别

（1）数据挖掘的数据源与以前相比有了显著的改变；数据是海量的;数据有噪声；数据可能是非结构化的；（2）传统的数据分析方法一般都是先给出一个假设然后通过数据验证，在一定意义上是假设驱动的；与之相反，数据挖掘在一定意义上是发现驱动的，模式都是通过大量的搜索工作从数据中自动提取出来。即数据挖掘是要发现那些不能靠直觉发现的信息或知识，甚至是违背直觉的信息或知识，挖掘出的信息越是出乎意料，就可能越有价值。

在缺乏强有力的数据分析工具而不能分析这些资源的情况下，历史数据库也就变成了“数据坟墓”－里面的数据几乎不再被访问。也就是说，极有价值的信息被“淹没”在海量数据堆中，领导者决策时还只能凭自己的经验和直觉。因此改进原有的数据分析方法，使之能够智能地处理海量数据，即演化为数据挖掘。

数据挖掘方法与过程

   方法：决策树 关联规则 人工神经网络

粗糙集理论

遗传算法

过程：1.对数据库数据整理，抽取出用来完成特定挖掘目标的数据集。2.选择合适的挖掘方法和工具，在领域专家指导下进行知识获取研究3.对事物的发展进行预测

数据采集与处理：从数据仓库中选取相关的数据集合。知识库：指导数据挖掘和评价挖掘结果。

数据挖掘：对数据仓库中提取的数据进行分析处理。

知识评价：是以兴趣度作为衡量标准来查找和选择对最终决策活动友有益的的知识。

OLAP与数据挖掘（DM）的比较 相同之处：OLAP与DM都是数据库(数据仓库)上的分析工具；不同之处：（1）前者是验证型的,后者是挖掘型的；（2）前者建立在多维视图的基础之上，强调执行效率和对用户请求命令的及时响应，而且其直接数据源一般是数据仓库；后者建立在各种数据源的基础上,重在发现隐藏在数据深层次的对人们有用的模式,一般并不过多考虑执行效率和响应速度。

（3）数据挖掘与OLAP不同，主要体现在它分析数据的深入和分析过程的自动化，自动化的含义是其分析过程不需要客户的参与，这是它的优点，也正是其不足。因为在实际中，客户也希望参与到挖掘中来，例如只想对数据的某一子集进行挖掘，对不同抽取、集成水平的数据进行挖掘，或是根据自己的需要动态选择挖掘算法等等。因此，OLAP与数据挖掘各有所长。

OLAP与OLTP的区别（1）OLTP主要面向公司职员;OLAP则主要面向公司领导者。（2）OLTP应用主要是用来完成客户的事务处理，其数据基础是操作型数据库，如民航订票系统、银行储蓄系统等等，通常需要进行大量的更新操作，同时对响应时间要求较高;而OLAP是以数据仓库或数据多维视图为基础的数据分析处理，是针对特定问题的联机数据访问和分析，它一般不对仓库数据作修改处理，而只是查询，其应用主要是对客户当前及历史数据进行分析，辅助领导决策，其典型的应用有对银行信用卡风险的分析与预测、公司市场营销策略的制定等，主要是进行大量的查询操作，对时间的要求不太严格。

OLTP

OLAP 面向人群

业务系统的操作、维护人员

管理、决策者 功能

日常操作处理

分析、决策辅助 实现方式

基于交易的处理系统

基于查询的分析系统 应用场合 面向生产应用

面向特定主题 数据库设计

实体-联系模型

星形或雪花模型 数据

当前的、最新的细节数据

历史的、聚合的数据 响应时间

对响应时间要求非常高

查询时间长

数据仓库与数据集市的差别

（1）范围不同：数据仓库面向的是整个企业，为整个企业提供所需的数据；数据集市则面向各个部门。

（2）粒度不同：数据仓库中的数据粒度非常小；数据集市中的数据主要是概括级的数据。

（3）数据组织方式不同

数据集市中数据的结构通常被描述为星型结构或雪花结构。一个星型结构包含两个基本部分—一个事实表和各种支持维表。事实表描述数据集市中最密集的数据。在电话公司中，用于呼叫的数据是典型的最密集数据；在银行中，与账目核对和自动柜员机有关的数据是典型的最密集数据。对于零售业而言，销售和库存数据是最密集的数据等等。

数据仓库:是一个面向主题的、集成的、不可更新的且随时间不断变化的数据集合，用来支持管理人员的决策。数据仓库的根本任务：把信息加以整理归纳并及时提供给管理决策人员。主要作用：提供报表和图表、支持多维分析、数据挖掘的基础。

数据挖掘:（Data Mining)是从大量的、不完全的、有噪声的、模糊的、随机的实际应用数据中，提取隐含在其中的、人们事先不知道的、但又是潜在有用的信息和知识的过程。

聚类分析:聚类（clustering）就是将数据对象集合进行分析，将数据集划分为多个类或簇，使得同一类中的数据对象之间具有较高的相似度，而不同类之间的数据对象具有较大的差异度。将上述分析过程称为„„

粒度是指数据仓库中记录数据或对数据进行综合时所使用的时间参数，它决定了数据仓库中所存储的数据单元在时间上的详细程度和级别。分割是指将数据分散到各自的物理单元中去以便能分别独立处理，以提高数据处理效率。

数据分割后的数据单元称为分片。

元数据：元数据是数据仓库数据本身信息的数据。不仅包括在数据仓库建设过程中所产生的有关数据源定义、目标定义、转换规则等相关的关键数据，而且还包括关于数据含义的商业信息。

OLTP：是传统的关系型数据库的主要应用，主要面对基本的、日常的事务处理。

OLAP：是数据仓库上的分析展示工具，它建立在数据多维视图的基础上。联机分析处理。OLAM：OLAP与数据挖掘结合起来，发展出一种为数据挖掘服务的具有新型OLAP的数据仓库，将更能适应实际的需要。数据仓库系统的四个层次体系结构：数据源 数据的存储与管理 联机分析处理

前端工具 数据仓库设计需考虑的四种视图：自顶向下视图 数据源视图 数据仓库视图 商务查询视图 数据仓库设计

自上而下 自底而上

混合的方法

数据仓库建模

数据仓库通常采三层结构：底层：数据仓库服务器 中间层：OLAP服务器 顶层：前端工具 ETL：是数据抽取（Extract）、转换（Transform）、清洗（Cleansing）、装载（Load）的过程。是构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗,最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。

神经网络：神经网络是由许许多多的被称为神经元或网络节点的基本单元构成，而这些基本单元则模仿了人脑中的神经元。将多个基本单元以某种适当的方式连接起来，就构成了神经网络。

决策树：又称为判定树，是一个类似于流程图的树型结构。决策树是一种简单的知识表示方法，它将事例逐步分类成代表不同的类别。在决策树的图形表示中，矩形表示内部结点，椭圆表示叶子结点，短线表示分枝，分枝上的标注表示一次测试的输出结果。

关联规则：是数据挖掘的一个重要内容，它反映了一个变量与其他变量之间的相互依存性和关联性；其中，关联是指在两个或两个以上变量取值之间所存在的某种规律性。关联规则挖掘：是为了发现变量之间的这种依存性和关联性的规则，并利用令人感兴趣的规则来预测多个变量之间潜在的关联或是通过其他变量来预测一个变量的存在。

文本数据挖掘：也称文本挖掘，它是将文本信息源作为分析对象，利用智能算法，并结合文字处理技术，分析大量非结构化文本源，从中寻找信息的结构、模型、模式等各种隐含的知识。

遗传算法：是一种基于生物进化过程中自然选择与遗传机制的模拟算法，该算法是模拟达尔文主义“适者生存”思想的一种全局优化方法，实质是一种繁衍、检测和评价的迭代算法。

 数据分类的基本技术有：判定树归纳、贝叶斯分类、贝叶斯网络、神经网络等；  预测的方法主要有：线性的、非线性的、广义线性回归。

数据仓库中的不同综合级别，称为“粒度”。粒度越大，表示细节程度越低，综合程度越高。元数据（metadata）：关于数据的数据。粗糙集:能够在缺少关于数据先验知识的情况下，只以考察数据的分类能力为基础，解决模糊或不确定数据的分析和处理问题。

用于从数据库中发现分类规则的基本思想是将数据库中的属性分为条件属性和结论属性，对数据库中的元组根据各个属性不同的属性值分成相应的子集，然后对条件属性划分的子集与结论属性划分的子集之间上下近似关系生成判定规则。

对数据立方体的典型操作包括：切片、切块以及旋转等。多维数据模型：是为了满足用户从多角度多层次进行数据查询和分析的需要而建立起来的基于事实和维的数据库模型，其基本的应用是为了实现OLAP（Online Analytical Processing）维（Dimension）：是人们观察数据的特定角度，是考虑问题时的一类属性，属性集合构成一个维（时间维、地理维等）。

维的层次（Level）：人们观察数据的某个特定角度（即某个维）还可以存在细节程度不同的各个描述方面（时间维：日期、月份、季度、年）。维的成员（Member）：维的一个取值，是数据项在某维中位置的描述。度量（Measure）：多维数组的取值。

星型模式：是最常见的模型范式。这种模式的数据仓库包含：一个大的事实表和一组小的维表。事实表：包含大批数据和不含冗余的中心表

维表：附属表，每维一个表

雪花模式：是星型模式的变种，其中某些维表是规范化的，因而数据被进一步分解到附加的表中。

多维数据模型上的OLAP操作：有钻取、切片和切块、以及旋转等。

钻取：是改变维的层次，变换分析的粒度。它包括向下钻取（Drill-down）和向上钻取（Drill-up）/上卷(Roll-up)。Drill-up是在某一维上将低层次的细节数据概括到高层次的汇总数据，或者减少维数；而Drill-down则相反，它从汇总数据深入到细节数据进行观察或增加新维。

切片和切块：是在一部分维上选定值后，关心度量数据在剩余维上的分布。如果剩余的维只有两个，则是切片；如果有三个或以上，则是切块。

旋转：是变换维的方向，即在表格中重新安排维的放置。

OLAM产生的原因

一方面，分析工具OLAP功能虽强大，能为客户端应用程序提供完善的查询和分析，但它也存在以下不足:

1)OLAP是一种验证型分析工具，是由用户驱动的。即在某个假设的前提下通过数据查询和分析来验证或否定这个假设，这很大程度上受到用户假设能力的限制。

2)OLAP分析事先需要对用户的需求有全面而深入的了解，然而用户的需求并不是确定的，难以把握。所以OLAP分析常常采用试凑法在大型数据库或仓库中搜索，不仅花时间，而且可能产生一些无用的结果。

3)即使搜索到了有用的信息，由于缺乏应有的维度，从不同的视图得到的结果可能并不相同，容易产生误导。

另一方面，数据挖掘虽然可以使用复杂算法来分析数据和创建模型表示有关数据的信息，用户也不必提出确切的要求，系统就能够根据数据本身的规律性，自动地挖掘数据潜在的模式，或通过联想，建立新的业务模型以辅助决策。但它也存在一些缺点:

1)DM是挖掘型分析工具，是由数据驱动的。用户需要事先提出挖掘任务。但对于用户来讲，很多时候预先是不知道想挖掘什么样的知识的。

2)由于数据库或数据仓库中存有大量数据和信息，用户仅仅指出挖掘任务，而不提供其他搜索线索，这样DM工具就会遍历整个数据库，导致搜索空间太大。计算机将处于长时间的工作，而且结果中可能会生成很多无用信息。

3)即使挖掘出了潜在有价值的信息，但它究竟用来做什么分析用，用户也可能不清楚。

两种技术各存在不足，但同时也可以相辅相成。如果将OLAP同DM配合集成，一方面OLAP的分析结果给DM提供挖掘的依据，引导DM的进行;另一方面，在数据挖掘的结果中进行OLAP分析，则OLAP分析的深度就可拓展。这样用户就可以灵活选择所需的数据挖掘功能，并动态交换挖掘任务，在数据仓库的基础上提供更有效的决策支持。鉴于OLAP与DM技术在决策分析中的这种互补性，促成了OLAM技术的形成。

数据仓库、数据挖掘在电子商务中的应用

1.控制商品库存

对于零售业，库存销量比是一个重要的效率指标。通过使用数据仓库，企业可以随时跟踪库存，及时通过网上供货商补充，实现了库存商品的有效控制。比如美国沃玛特连锁店，数据仓库规模从最初的6 万亿字节增加到现在的100 万亿字节，实现了存货少效益高的良性循环，始终保持着行业领先。2.减少跳线率

对于航空、银行等服务性行业，由于行业竞争激烈，存在“跳线”的现象，即客户从A 公司跳到B 公司，几个月后又重新回到A 公司，导致企业资金浪费。采用数据仓库后，进行数据挖掘，预测客户跳线机率，在客户跳线之前尽可能挽留，减少跳线率。3.客户跟踪

目前在电子商务网站中，84%的在线交易没有跟踪客户；96%的在线交易不能提供符合客户的个性化服务；75%的在线交易无法辨别重复客户；导致电子商务企业不能抓住已有的客户，更不用谈潜在客户的发展，丧失了该部分重要的资源。随着客户个性化需求的逐步增加，电子商务企业更是无从招架。当启用数据仓库后，网站能够对客户的信息以及浏览页面进行整理并存储，当客户再次访问后，数据仓库就会为客户提出相应的扩展服务，使顾客能够更加信任该网站，进而提升了该企业的效益。4.聚类客户

在电子商务中，通过客户相似浏览行为和客户的共同特征进行分析，深层次挖掘和分析企业的客户、市场、销售、服务与支信息，可以帮助电子商务的组织者及时了解客户，尽可能满足客户需求，向客户提供更适合的服务。

5.提供优质个性化服务，提高客户忠诚度在电子商务活动中，网站的内容、标题、奖励方案、服务等方面都可能吸引客户。由于电子商务网站的众多，客户可以很方便的在网站间切换，因此电子商务网站应该能够对客户访问信息进行挖掘，通过客户的浏览行为，从而了解客户的忠诚度、喜好及需求，快速调整WEB 页面满足客户的需求。比如京东网，通过分析客户浏览的页面，运用数据挖掘中的序列模式发现技术进行挖掘，可以把客户需求的相关物品呈现出来，方便客户挑选，6.提高点击率，完善电子商务网站设计通过数据挖掘技术，分析客户的行为记录和反馈行为，电子商务企业可以更加有效地优化网站结构，提高网站的点击率。例如通过关联规则，针对客户需求，调整站点结构，把客户访问过的有关联的文件进行直接链接，从而使客户很容易访问想要的页面，增加客户再次访问的概率。

7.决策信息服务

数据仓库用于实现对决策主体数据的存储和综合，通过从源数据库中抽取、清理、集成和转换，提供标准的报表和图表；通过从多种角度构建多维数据模型，采用联机分析处理实现多维数据分析；进而挖掘出隐藏在数据背后的模式和信息，可以针对整个企业的状况和未来发展做出比较完整、合理、准确的分析和预测，从而为企业提供了多方位的决策支持。

结论：由于电子商务领域拥有丰富的信息资源，为企业实施数据仓库和数据挖掘技术提供了良好的基础；同时，数据仓库和数据挖掘技术又为电子商务提供了有力的技术支持，加快了电子商务的发展和普及。在电子商务活动中，数据仓库、数据挖掘技术已成为数据管理、信息处理领域最热门的技术之一。通过对源数据的整理、归纳，它可以帮助决策者查找数据间的潜在关联，发现隐藏在数据背后的信息，不仅可以预测客户的消费趋势以及进一步的市场走向，而且可以指导电子商务企业提高网站运行效率，进一步改善企业客户关系，提高销售额，具有良好的发展和应用前景。

第三篇：IBM数据仓库解决方案

IBM数据仓库解决方案

IBM 2000-09-23

数据仓库是汇总商用信息后，进而支持数据挖掘、多维数据分析等当今尖端技术和传统的查询及报表功能，这些对于企业在当今激烈的商业竞争中保持领先是至关重要的。那么怎样把这样大量的数据转换成可靠的、商用信息以便于决策支持呢？建立数据仓库正被广泛地公认为最好的转换手段。

根据IDC的调查，使用数据仓库的投资回报率平均超过400%，尤其是从小型数据仓库开始实施的平均超过500%。

IBM早在90年代初期，就投入大量优秀技术人员和资金开始了数据仓库的研究，并启动了Star－Brust大型科研项目。该项目主要就是为了攻克数据仓库领域的一些技术难题，例如优化星型连接（Star－join），实现多维分析。因此，IBM现在发布的数据仓库产品都是经过反复推敲和久经考验的，真正做到让用户买起来放心，用起来舒心。基于对数据仓库结构的深刻理解和多年积累的经验，IBM设计了自己的数据仓库结构。它作为一种开发式结构，方便了用户的产品选择、实施和今后的扩展。

在数据抽取阶段完成对各种数据源的访问，数据转换阶段完成对数据的清洗、汇总和整合等，数据分布阶段完成对结果数据存储的分配。这三个阶段通常紧密结合在一起，集成在一个产品中实现。例如，VisualWarehouse、DataJoiner、DataPropagator都跨越了这三个阶段。其中，DataJoiner和VisualWarehouse可以访问各种关系型和非关系型的数据，关系型数据库主要包括DB2数据库家族、Oracle、Sybase和Informix，非关系型数据有VSAM。VisualWarehouse还可以进行数据映射的定义，以定期地抽取、转换分布数据。DataPropagator采用数据复制的方式可避免对日常业务系统事物处理性能的影响。当用户有特殊需求时，可以通过编程接口编程实现或选择第三方厂商（如ETI和ValityTechnology）的产品。

数据仓库的存储由DB2家族产品来完成，以保证数据仓库始终高性能地运转，提供完整、准确的数据，以便于将来的升级和扩展。若希望使用多维数据库，则可选用第三方的产品，例如：Arbor软件公司、Pilot软件公司、PlanningSciences软件公司。如果既想拥有多维数据库的独特功能，又要把数据存放在关系型数据库中以便管理，则DB2OLAPServer是用户的最佳选择。

DataGuide通过描述性数据帮助用户查找和理解数据仓库中的数据。

其中数据的呈现由不同产品完成不同层次的分析要求。其中，Approach可进行查询和统计分析，IntelligentDecisionServ С侄辔治觯琁ntelligentMiner用于数据挖掘。用户也可选择自己喜爱的第三方产品，这些第三方厂商包括：Andyne、Brio、BusinessObjects、Cognus、InformationAdvantage。

整个数据仓库的管理工作可交给VisualWarehouse,ADSM是大型磁盘阵列管理的得力助手，DB2ECCforTME10可从一点集中管理各种关系型数据（DB2、Oracle、Sybase、Informix）。

以上各个阶段的结构都是按照IBMInformationWarehouse和IBMOpen－Blueprint的架构统一设计的，因此相互之间结合得既紧密又非常开放，只要符合标准的软件就可结合在一起。

最后，为了帮助用户快速实施，IBM可由IBMGlobalServices或IBMGlobal－Solution提供可靠的咨询服务。这些服务也可从广泛的第三方获得。因此，在此架构下，IBM提供给用户的是一个完整的、灵活的、开放的解决方案。

IBMVisualWarehouse是IBM数据仓库解决方案的重要组成部分，它主要由以下几部分功能组成：数据访问;数据转换;数据分布;数据存储;靠元数据查找和理解数据;显示、分析和发掘数据;数据转换过程的自动化及其管理。它缩短了复杂的海量数据与有洞察力的商务决策之间的差距，有助于公司更进一步了解其业务、市场、竞争对手和客户。

IBM的VisualWarehouse的数据源可以是DB2家庭中的任一数据库，也可以是Oracle、Sybase、Informix、SQLServer数据库和IMS、VSAM文件系统；存放数据仓库的数据库可以是DB2UDBforWindowsNT,OS/2,AIX/600,HP？UX,SunSolaris,SCO,SINIX和DB2/400,DB2forOS/390;VisualWarehouse的管理平台为WindowsNT和OS/2；而且以上适用的平台仍在不断地扩展。下面，我们将从几个用户关心的方面来分析一下VisualWarehouse。

(1)元数据的存储（MetaData）

VisualWarehouse建立在集成的元数据的仓库之上，该元数据的仓库提供了一个所有管理和操作功能的中心。数据仓库的模型以元数据的形式存储于该仓库中，它定义了数据仓库的结构和内容，用于对数据源进行抽取、过滤、转换、映射后放入数据仓库。这种元数据是以商业视图被定义的，而且商业视图可以在多个数据仓库间输入和输出，大大方便了具有相同结构数据仓库的建造。

(2)数据仓库的规模化扩展

VisualWarehouse很易于扩展，单个数据仓库可支持非常大量的数据，也可靠简单地增加内存、处理器升级和存储设备扩容来支持更多的升级和用户，访问更多数据源。另外，我们还可以不同的主题同时实施多个部门级数据仓库，最后再把它们整合到一起形成企业级的数据仓库。

(3)开放的系统环境

VisualWarehouse提供了一个真正开往的系统环境，它不仅提供了数据仓库的所有功能和组件，而且可以“即插即用”的方式与用户喜欢的第三方软件组合，以最少的费用快速开发出用户所需的数据仓库。

(4)规模化的体系结构

VisualWarehouse提供了完整的分布式客户机/服务器环境，它使得用户可充分享受到“网络计算”带来的便利，而且适用于多种平台。它包括四个组件：管理员、控制数据库、客户端管理员、代理。这些组件既可分布于几个不同的服务器，也可都安装在同一服务器上。

(5)VisualWarehouse的管理

VisualWarehouse的管理是由其客户端管理员实现的，它的管理得以集中于 isualWarehouse中的触发器、用户自定义程序，元数据等。

(6)高效装入

除了WindowsNT，VisualWarehouse的代理(Agent)现在可以运行于AIX和OS/2，这就带来了针对位于这些平台上数据中心的装入性能的改善，因为数据无需再通过WindowsNT上的代理。另外，除了现有的基于SQL的目标装载，VisualWarehouse现在还提供用于文件传输和装载过程管理的程序。

(7)处理OLAP

VisualWarehouse支持DB2OLAPServer上一种或多种星型图表的全部映射或装载。另外VisualWarehouse现在也支持指定和创建DB2OLAPServer以外生成的星型图表初始化或引入关键码。

(8)高端可升级性选项

现在，VisualWarehouse对抽取和转变程序具有更完善的支持。VisualWarehouse利用这种支持给IBM的战略基础伙伴提供数据加工后的管理：ARBOR软件公司和ETI。

(9)商务视图建模改善

VisualWarehouse图形查询编制器得以扩展，目前除了支持常用的SQL语句还支持JOIN和GROUPBY语句，简化了复杂的SQL声明。

VisualWarehouse基于久经考验的独创技术，可以支持复杂业务分析过程的每一步骤,同现有应用程序环境集成，转换数据，自动执行数据仓库处理，分析数据，并为决策人员提供信息。VisualWarehouse是一种简单易用、经济有效的数据中心和数据仓库产品，可以处理部门中设计、实现和应用方案时的相应任务。其较低的维护成本和迅速的实现过程将使工作组迅速提高工作效率。

VisualWarehouse提供了完整的Web支持功能，允许从任何Web浏览器访问任何数据。因为VisualWarehouse的信息目录完全支持Web,用户可以访问可用数据的详细信息，包括格式、通用性、拥有者和位置。

IBM的VisualWarehouse提供了强有力的工具以定义、建立、管理、监控和维护一个商用信息系统环境„„数据仓库。但是，IBM并不满足于此。为了更好地满足用户的需求，IBM设计了一个完整的解决方案。IBM将Dataguide和VisualWarehouse集成在一起并与Lotus、Approach和相应平台上的DB2UDB打包在一起，作为一个完整的解决方案提供给用户。其中，Dataguide靠商用信息分类表支持商业需求，帮助用户查找和理解数据仓库中的商用信息。Lotus、Approach可帮助用户分析信息并把它以图表的方式表示出来。

IBM的VisualWarehouse系列软件包用于帮助企业迅速建立、管理和分析数据仓库和数据中心。VisualWarehouse系列包括VisualWarehouse、VisualWarehouseOLAP（联机分析处理）、IBM及其贸易伙伴提供的补充产品。VisualWarehouse系列已得到扩展，通过与EvolutionaryTechnologiesInternational(ETI)和ValityTechnology的产品相结合，可以满足复杂的数据提炼、纯化和转换需求。VisualWarehouse的Cognos和BusinessObjects版本也已经分别集成于相应公司的前端工具之中。这些版本提供了完整的业务智能解决方案，包括从数据访问、分析到应用。

VisualWarehouse产品系列集成了数据仓库功能，单一软件包中的集成化工具可以简化数据仓库和决策支持的整个过程。它提供了迅速建立小型企业或工作组数据仓库并投入运行所需的一切。

现在，越来越多的用户受益于VisualWarehouse，例如：INGRAM公司依靠IBM可视数据仓库将原始数据转变为有价值的商用信息；RYDERSYSTEM、VOLTINFORMATIONSCIENCES和INTENTIA这三个可代表数据仓库客户群的系统集成商得出了一致结论：IBM的可视数据仓库是一个强有力的、经济的、易于安装和实施的数据仓库。它提供支持商业决策的、一致的和固有的数据。另外，国内用户也在不断增长，例如：上海庄臣有限公司等。

OLAP在IBM的商务智能中扮演着重要角色，IBM为此提供一个分析工具——DB2OLAPServer，深入最终用户的业务，对桌面上的数据进行实时操作。DB2OLAPServer是一套独特的商务工具，能够快速地分布传统监视和报告范围之外的应用程序数据。

IBMDB2OLAPServer是一种功能强大的工具，结合了业界领先的ARBORESSBASEOLAP功能以及DB2的可靠性、可管理性和访问能力。ARBORESSBASE是OLAP市场领先的厂商。同其它OLAPAPI相比，有更多的前端工具和应用程序利用了ESSBASEAPI，使其? 事实上的业界标准。由于DB2OLAPServer包含了完整的ARBORESSBASEOLAP引擎，所有支持ESSBASE的应用程序都可以同DB2OLAPServer协作，而不必加以修改。同大多数基于SQL的应用程序结合时，DB2OLAPServer和VisualWarehouse将为前端用户提供更多的前端工具和业务智能应用程序选择余地的优势，如今用户可以享受更多种OLAP应用程序的优势，如通过ARBOR的OLAP引擎集成预算功能，充分利用在相关技术上的投资，管理基本设施和DB2的数据。

通过集成IBM的VisualWarehouse和DB2OLAPServer(称之为VisualWarehouseOLAP版本)，这套解决方案将具有三方面的重要价值：

（1）完全、自动地把OLAP集成到数据仓库，数据抽取和生成自动地由规则和数据源支持，直接进入DB2OLAPServer的立方体

（2）OLAP描述数据外部化

（3）一个中间数据存储库

DB2OLAPServer和ESSBASE产品最突出的方面在于它特别的分析能力和简便的分布。OLAP系统更倾向于把劳动集中于获得和清除数据，使用VisualWarehouseOLAP版本能够自动地创建和维护多维数据库，大量减少手工维护并确保数据稳定。

利用VisualWarehouseOLAP版本还有一项附加收益，就是在可视化数据仓库上创建了一个中间信息仓库。这个中间数据仓库包含干净、抽取的数据。用来在OLAP系统上装载多维数据。一旦OLAP系统装载并上线，或者作为干净数据源来进行OLAP以外的分析比如查询客房地址等，这些中间数据就可以废弃。

VisualWarehouseOLAP版对于分析业务需求来说是一套很好的商务智能解决方案，它利用自动维护仓库工具提供了强大的分析型数据的分析能力。

当用户的数据积累到一定数量时，这些数据的某些潜在联系、分类、推导结果和待发现价值隐藏在其中，我们可以使用数据发掘工具帮助发现这些有价值的数据，IBM在这方面的工具就是IntelligentMiner。IBMIntelligentMiner被选为业界最佳数据采集工具，赢得了DM读者奖。除了数据仓库和数据挖掘解决方案，IBM还在此基础上开发了一系列行业解决方案及应用程序。

1．IBM数据挖掘工具

IntelligentMiner通过其世界领先的独有技术，例如典型数据集自动生成、关联发现、序列规律发现、概念性分类和可视化呈现，它可以自动实现数据选择、数据转换、数据发掘和结果呈现这一整套数据挖掘操作。若有必要，对结果数据集还可以重复这一过程，直至得到满意结果为止。

现在，IBM的IntelligentMiner已形成系列，它帮助用户从企业数据资产中识别和提炼有价值的信息。它包括分析软件工具IntelligentMinerforData和IBMIntelligentMinerForText，帮助企业选取以前未知的、有效的、可行的业务知识，如客户购买行为，隐藏的关系和新的趋势，数据来源可以是大型数据库和企业内部或Internet上的文本数据源。然后公司可以应用这些信息进行更好、更准确的决策，获得竞争优势。

(1)IntelligentMinerforData

IntelligentMinerforData可以包含传统文件、数据库、数据仓库和数据中心中的隐含信息。这一产品的最新版本拥有改进的用户界面，增强了并行性，提供新的平台支持、统计功能、一种新的中枢净价值预测技术以及优化的算法。

IntelligentMinerforData帮助用户充分利用传统数据库或普通文件中的结构化数据。其采集算法已成功应用于客户及贸易伙伴之中，满足市场分析、诈骗行为监测、客户联系管理等业务领域的需求。系统支持的服务器平台包括AIX和AIX/SP、OS/390、SUNSolaris、OS/400和WindowsNT，此外还将全面推出OS/2客户机版本。

(2)InteligentMinerforText

IBM还扩展了采集解决方案的范围，包含了文本数据源。IntelligentMinerforText允许企业从文本信息中获取有价值的客户信息。文本数据源可以是Web页面、在线服务、传真、电子邮件、LotusNotes数据库、协定和专利库。

IntelligentMinerforText扩展了IBM的数据采集功能，可以从文本文档和数据源获取信息。数据源可以包括客户反馈、在线新闻服务、电子邮件和Web页面。其功能包括识别文档语言，建立?、用语或其它词汇的词典，提取文本的涵义，将类似的文档分组，并根据内容将文档归类。新版本中还包括一个全功能的先进文本搜索功能。系统支持的服务器平台包括AIX和WindowsNT、OS/390和SUNSolaris。

IBMIntelligentMiner系列可以充分发挥您寻找相关信息的潜力，并帮助您花费最少的时间来搜索和浏览结果信息。此外,文本采集技术还可以适用于多种需要查看或研究文档的用户,如专利代理人、企业图书管理员、公共关系人员、研究人员和学生。

2．行业解决方案

通过利用以上介绍的IBM数据仓库和数据挖掘技术，IBM为客户开发了一系列行业解决方案及应用程序，主要有以下几种：

（1）DecisionEdgeforFinance——专门为金融行业设计的综合解决方案。DecisionEdgeforFinance不仅仅是简单的报告工具，它提供了行销经理所需的全部技术，以制定战略业务决策并开展行销活动。

（2）DecisionEdgeforInsurance——端到端的解决方案，包括硬件、软件、顾问和服务，其设计目的是帮助保险业行销经理制定战略业务决策并开展行销活动。

（3）IBMDiscoverySeriesforBanking——为满足“客户至上”的银行业需求而设计的应用程序套件。

（4）IBMDiscoveryfortelecommunications——为电信行业提供完美的客户服务的应用程序套件。

（5）BusinessAnalysisSuiteforSAP——适用于下列公司：已经安装SAP事务处理系统，并需要建立数据仓库，以充分利用日常运作中收集的所有事务数据。

（6）Surf－Aid——数据采集应用程序，用于分析Web站点利用率。

（7）InfoPrintBusinessIntelligenceSolution——允许企业将自定义消息、姓名及地址同图形和条形码相结合，向客户提供有独特个性的行销资料。

（8）GlobalServicesBIOffering——包含不同角度（行业、业务功能、技术）的战略和规划功能，以及帮助客户理解和解决业务困难、管理数据仓库项目、开发和实现先进分析功能的方法。

（9）InsuranceUnderwritingProfitabilityAnalysis－将数据仓库和数据采集技术相结合，帮助保险业执行人员处理保险业过程。

第四篇：java 工作流

Willow 由Huihoo Power开发详细可到其中文主页查看。

更多Willow信息

OpenWFE OpenWFE是一个开放源码的Java工作流引擎。它是一个完整的业务处理管理套件：一个引擎，一个工作列表，一个Web界面和一个反应器（存放自动代理）。它可以可以跟你的程序很好的给合。

更多OpenWFE信息

jBpm jBpm是一个灵活可扩展的工作流管理系统。作为 jBpm运行时server输入的业务流程使用简单强大的语言表达并打包在流程档案中。jBmp将工作流应用开发的便利性和杰出的企业应用集成（EAI）能力结合了起来。jBmp包括一个Web应用程序和一个日程安排程序。jBmp是一组J2SE组件，可以作为J2EE应用集群部署。

更多jBpm信息

OpenEbXML OpenebXML项目致力于提供一个ebXML框架，主要支持不久将由 UN/CEFACT和OASIS发布的ebXML规范2.0版。

更多OpenEbXML信息

Werkflow Werkflow是一个灵活可扩展的基于流程和状态的工作流引擎。它的目标是满足可以想象的所有工作流程，从企业级的业务流程到小范围的用户交互流程。通过使用可插拔和分层结构，可以方便地容纳各种工作流语义。

更多Werkflow信息

OSWorkflow OSWorkflow是一个灵活的工作流引擎，设计成可嵌入到企业应用程序中。它提供了许多的持久化API支持包括：EJB,Hibernate,JDBC和其它。OSWorkflow还可以与Spring集成。

更多OSWorkflow信息

wfmOpen WfMOpen是WfMC和OMG中所谓工作流设施（workflow facility）(工作流引擎)的J2EE实现。工作流通过扩展的XPDL描述。

更多wfmOpen信息

OFBiz OFBiz是一个非常著名的开源项目，提供了创建基于最新J2EE/XML规范和技术标准，构建大中型企业级、跨平台、跨数据库、跨应用服务器的多层、分布式电子商务类WEB应用系统的框架。OFBiz最主要的特点是OFBiz提供了一整套的开发基于Java的web应用程序的组件和工具。包括实体引擎, 服务引擎, 消息引擎, 工作流引擎, 规则引擎等。更多OFBiz信息

ObjectWeb Bonita Bonita 是一个符合WfMC规范、灵活的协同工作流系统。对于各种动作如流程概念建模、定义、实例化、流程控制和用户交互等提供了全面的集成图形工具。100% 基于浏览器、使用SOAP和XML数据绑定技术的Web Services封装了已有的工作流业务方法并将它们以基于J2EE的Web Service形式发布。基于活动预测模型的第三代工作流引擎。更多ObjectWeb Bonita信息

Bigbross Bossa 速度非常快、轻量级的引擎，使用富有表达能力的Petri网定义工作流，不要求关系数据库，使用简单，能和Java应用集成。事实上，它是按嵌入式设计的。更多Bigbross Bossa信息

XFlow XFlow运行于EJB和servlet容器中。

更多XFlow信息

Taverna Taverna项目的目标是提供一种语言和软件工具，方便在eScience中使用工作流和分布计算技术。

更多Taverna信息

Enhydra Shark Shark完全基于WfMC和OMG标准，使用 XPDL作为工作流定义语言。流程和活动的存储使用Enhydra DODS(一个开源OR映射工具)。

更多Enhydra Shark信息

PowerFolder PowerFolder是一个容易使用，容易安装基于J2EE的工作流服务器，包括开发人员使用的基于web的studio。

更多PowerFolder信息

Open Business Engine Open Business Engine是一个开放源码的Java工作流引擎，支持WfMC规范，包括接口1（XPDL）、接口2/3（WAPI）和接口5。OBE为活动的运行提供了一个可控的集中环境。OBE主要基于J2EE实现。

更多Open Business Engine信息

OpenWFE OpenWFE是一个开放源码的Java工作流引擎。它包括可升级的三个组件：引擎、工作列表和Web界面。它的流程定义语言虽然使用XML格式，其灵感来源于 Scheme，一种Lisp方言。

更多OpenWFE信息

Freefluo Freefluo 是一个使用Web Service的工作流协同工具，可以处理WSDL的Web Service调用。支持两种XML格式的工作流语言：IBM的WSFL和XScufl。Freefluo非常灵活，它的核心是不与任何工作流语言或执行架构关联的可重用协同框架。Freefluo包括可执行使用WSFL一个子集描述的工作流的运行库。

更多Freefluo信息

Twiste Twister的目标是提供新一代、易集成、应用Java领域中最新成果、面向B2B的工作流解决方案。流程引擎基于BPEL业务流程规范和Web Service标准。

更多Twiste信息

Con:cern con:cern工作流引擎基于扩展的案例（case）处理方法，流程由一组具有前后条件的活动组成。

更多Con:cern信息

JFlower JFlower是一个用Java开发的工作流引擎，可以通过Java插件来扩展。服务器可以

解析XML文档来执行任务，检查条件。会话数据保存在一个数据库中，所以服务器是完全可伸缩的。

更多JFlower信息

JFolder JFolder(formerly PowerFolder)是一个工作流服务器和开发环境,它可以配置在任何J2EE服务器与数据库。

更多JFolder信息

JAWE 基于Java的图形化工作流编辑器。图形化工作流编辑器。使用JAVA语言开发，开放源码。严格遵循WFMC规范。XPDL（XML Process Definition Language）WFMC的 XML 过程描述语言。工作流定义文件保存在本地的XML文件中

更多JAWE信息

Zebra Zebra是一个工作流引擎。原先的设计是为了填补商业开源工作流引擎的空白。它有一些不同于其它工作流系统的特点：

*所有工作流模型都可以在workflow patterns中描述

*一个易于使用的GUI designer

*一个持久层中间件

*OO设计

*一个基于Turbine的Web应用程序

更多Zebra信息

ActiveBPEL ActiveBPEL引擎是一个健壮的运行时环境,它能执行依据BPEL4WS或just BPEL1.1与WS-BPEL2.0规范编写的业务流程。

更多ActiveBPEL信息

YAWL YAWL(Yet Another Workflow Language)一个开源工作流语言/处理系统.它基于现有的工作流处理系统与工作流语言的一个精确分析.不像传统的系统,它提供对大部分工作流模式的直接支持.YAWL支持控制流透视图,数据透视图并且能与WSDL标准的web服务相结合.更多YAWL信息

MOBE MidOffice BPEL Editor(MOBE)是一个开源平台能够让执行,监控,调整,结束每个定义的过程和谐地结合起来.这个平台的实现使用到J2EE技术与公共的标准如:BPEL,XML与SOAP.更多MOBE信息

RUNA WFE RUNA WFE是一个基于JBOSS-JBPM引擎的开源工作流工作平台它是一个跨平台适用于商业流程处理的最终用户解决方案,很容易与所有SQL数据库管理系统相结合.更多RUNA WFE信息

micro-workflow micro-workflow框架适用于那些要在他们程序中分离控制与逻辑方面的开发者,所以这个框架可以使他们的流程相互独立。这样有利于代码重复使用与代码的完整性。更多micro-workflow信息

bexee bexee是一个BPEL执行引擎并且是BPEL标准的一个开源实现.更多bexee信息

PXE PXE-Process eXecution Engine是一个模块化的商业流程执行引擎.支持用WS-BPEL2.0或用BPEL4WS1.1规范描述的商业流程.

第五篇：工作流技术研究

工作流技术研究（1）(2008-09-10 19:29:14)

标签：工作流管理系统 工作流参考模型 杂谈 分类：工作流

工作流技术从起源到现在已有三十年的发展历史,为了规范工作流技术的管理,1993年成立了工作流管理联盟(WfMC)。WfMC统一了工作流的定义,制定了工作流产品结构和工作流参考模型等一系列的标准。本文针对工作流及其参考模型作简单的介绍。

首先，先了解一下工作流的相关定义。

一、工作流相关定义

定义1 工作流（Workflow）：工作流的概念定义很多，其中被广泛引用的是工作流管理联盟关于工作流的定义，该组织为工作流管理系统的相关术语、体系结构及应用编程接口等方而制定了一系列的业界标准。工作流管理联盟给出的工作流定义是：全部或者部分，由计算机支持或自动处理的业务过程，它已根据一系列过程规则、文档、信息或任务能够在不同的执行者之间进行传递与执行。工作流是指整个或部分经营过程在计算机支持下的全自动化或半自动化。工作流是企业中各种流的载体，它带动了信息流、物料流、资金流的流动，并决定了它们的流速和流量。通过工作流，考察信息、物料、资金等随过程的变化情况，从而可以方便地对一些关键指标进行跟踪和计算。其文

档、信息或任务可以遵循一组程序上的规则从一个参与者传送到另一个参与者。

定义2 工作流管理：工作流管理（Workflow Management, WFM）是人与计算机共同工作的自动化协调、控制和通讯，在计算机化的业务过程上，通过在网络上运行软件，使所有命令的执行都处于受控状态。在工作流管理下，工作量可以被监督，分派工作到不同的用户达成平衡。

定义3 工作流管理系统（WFMS—Workflow Management System）：工作流管理系统是这样的一个系统，详细定义、管理并执行工作流，系统通过运行一些软件来执行工作流，它运行在一个或多个工作流引擎上，这些引擎解释对过程的定义，与工作流的参与者（包括人或软件）相互作用，并根据需要调用其他的软件工具或应用。这些软件的执行顺序由工作流逻辑的计算机表示形式（计算机化的业务规则——过程定义）驱动。总体来说，实际企业中运作的工作流管理系统，是一个人与计算机结合的系统。

它的基本功能体现在几个方面：

? 定义工作流，包括具体的活动、规则等。

? 遵循定义创建和运行实际的工作流。

? 监察、控制、管理运行中的业务，例如任务、工作量与进度的检察等。

定义4工作流机：为工作流实例提供运行时期的执行环境的软件服务器或引擎。工作流机能处理：

? 解释过程定义

? 控制过程实例—创建、激活、挂起、终止等

? 为过程的活动导航，可能要包含顺序或者平行的操作、最后时间期限、对工作流相关数据进行解释

? 参与者签名和退出

? 确定任务项目，实现用户意图；提供接口，支持用户交互

? 维护工作流控制数据和工作流相关数据，在应用程序间或者用户间传递工作流相关数据

? 提供调用外部程序的接口，连接所有工作流相关数据

? 提供控制、管理和审查功能

工作流机可以控制过程集、子过程、或通过对象类型的范围、及其属性定义好运行范围的实例。在一个由多个工作流机构成的工作流执行服务器中，要把过程进行划分，分配给工作流机。可以按照过程类型来划分，某个工作流机负责控制相应类型过程；按照功能进行划分，某个工作流机负责控制过程的一些部分，这些部分所需要的用户或者资源，都在此工作流机的控制范围内。也可以按照其他的一些机制来划分。

定义5 业务过程（business process）：就是活动的集合，这些活动均关联于特定的托付事项（commitment），为过程的产出增值。相对于“工作流”，业务过程是一个更一般化的统称，而工作流这个词，则已经不能仅从字面含义或原理上去理解，它已经被赋予了更深一层的特定含义——专指基于信息技术规划、运作、管理的业务过程。

定义6 自动与协调：“自动”（automate）是工作流的一个特征，但这主要是指它自动进行的特征，而不是说没有人的参与。工作流实际上是一个人与计算机协调的混合过程，在一个实际的工作流中，通常总有些步骤是人完成的。协调是工作流管理的一个目标或者特征，这包括了人与人、人与计算机，计算机软件之间等多种层面的含义。

定义7 监察与控制：监察（Monitoring）与控制（Contorl）是工作流系统的重要功能与特征。这不仅包括对正在发生的业务过程（工作流），还包括它的定义或改

变（比如BPR的过程）。这是工作流系统带给我们的明显好处之一。定义8 标准化：工作流的概念被明确提出并得到重视的同时，人们就认识到了“标准化”在其中的重要性，有关工作流的标准开发和推广，基本是与“工作流”的开发和推广同步进行的。在这方面目前的权威性机构，是“工作流管理联盟”（Workflow Management Coalition, WfMC）。它成立于1993年8月，目前已拥有 130 余个成员，成员包括工作流产品的供应者、应用者，有关大学和研究机构和个人，是一个国际性的非赢利组织。定义9 工作流与重规划：从逻辑上，对工作流的关注和研究可以看作是对业务过程重规划（BPR）的一种深化。BPR的观点，要求我们将眼光投向实际业务进行的过程，但这个过程应当是什么样的，怎样分析、构造？工作流就是一个具体的、操作性的答案，它可以令我们从神秘的、难以预测和控制的“头脑风暴式”的“艺术的”业务过程创造，变成解析的、技术的、可控制和预测的工程化过程，如此，才真正体现出

re-engineering 中 engineering 的意义。

工作流与 BPR 的概念，已经被几乎所有的研究者联系在一起研究和应用。在这个领域有一个非常活跃的组织，即国际工作流与重规划协会（Workflow And

Reengineering International Association, WARIA）。

工作流管理系统是一个真正的“人—机”系统，用户是系统中的基本角色，是直接的任务分派对象，他或她可以直接看到计算机针对自己列出的“任务清单”，跟踪每一项任务的状态，或继续一项任务，而不必从一个模块退出，进入另一个模块，搜索相应任务的线索。前者是面向功能或对象的，而后者是直接面向用户的。这样，用户的任务

分派和任务的完成状态，可以被最大程度地计算机化和受到控制。

现在的典型工作流产品是客户—服务软件。而日益增长的重要途径是通过万维网界面，它可以令客户或远程的职员更好地参与。工作流的定义经常是借助于图形化

工具，依照业务过程实例的情况定义相应工作的安排。

二、目标领域

使用工作流管理系统的目的之一是作为企业应用系统集成（EAI）的平台。在当前大部分企业级IT架构中，各种各样的异构（heterogeneous）应用和数据库运行在企业内网中。在这些系统被应用到组织时，都有一个清晰的目标。例如，客户管理、文档管理、供应链、订单、支付、资源计划等等。让我们称这些系统为专门应用（dedicated applications）。每一个专门应用都包含它们所支持业务流程的领域知识。这些专门应用中的自动化流程，被拼装到企业中更大的非自动化流程中。每当一个这样的专门应用安装并投入使用，都会带来涉及其他多个应用的新功能需求。企业应用系统集成（EAI）就是通过使用多个专门应用满足软件新需求的方法。有时，这只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务流程硬编码在软件中。可以这么说，在你购买专门应用时，你是购买了一组固定的自动化业务流程。而工作流管理系统是不必事先知道问题域的相关信息的。工作流系统将业务流程描述作为输入并管理流程实例的执行，这使得它比专门应用更灵活（当然你也要花精力编写业务流程的规格化描述）。这就是为什么说工作流系统和专门系统是相互补充的。工作流系统可以用来管理全局的业务流程。如果专门应用支持你所需要的业务流程，那么使用专门应用。在此讨论的工作流系统的第一种使用方式就是：结合所有的专门应用，使用工作流系统构建一个EAI平台。

工作流系统能够发挥很大价值的第二个使用方式是：协助涉及多人相关任务工作流软件的开发。为了达到这个目的，大部分工作流系统都有一个方便的机制，来生成执行任务的表单。对于专注于ISO 或者CMM认证的组织，采用这种方式使用工作流系统能够显著提高生产率。不用将过程用文字的形式写在纸上，工作流系统使你通过

流程定义建模实现过程的自动化（如使用基于Web的应用）。

工作流系统的第三种使用方式是：将工作流引擎嵌入到其他应用中。在前面我们谈到，专门应用将指定问题域相关的业务流程固化在软件中。开发专门应用的公司也可以将工作流引擎嵌入到他们的软件中。在这里，工作流引擎只是作为一个软件组件，对于应用的最终用户是不可见的。将工作流引擎嵌入到应用中的主要原因是为了重用

（不重复发明轮子）和应用软件的可维护性。

三、工作流参考模型

WfMC定义的工作流参考模型包括若干基本部件和5个基本接口（部件之间的箭头表示部件之间的接口），如图1所示。工作流执行服务器周围的接口是 WAPI（Workflow APIs），通过这些接口可以访问工作流系统的服务，这些接口还控制工作流控制软件与其他系统组件间的交互。在5个接口中的许多功能，都是被2个或更多个接口同时拥有的，因此WAPI可以看作是统一的服务接口，可以交叉使用这5个接口来支持工作流管理功能，而不是单独的使用其中某个接口。

首先，我们粗况的了解一下参考模型中的基本部件，然后再对这些基本部件进行简单分析。

（1）过程定义：负责给出工作流程的定义，并以一定的数据格式提供给工作流引擎解释。

（2）工作流执行服务：工作流管理系统的核心，提供了过程实例执行的运行环境。工作流执行服务借助于一个或多个工作流引擎，激活并解释工作流流程定义，用来创建、管理、执行工作流实例。并同外部的应用程序进行交互，完成工作流过程实例的创建执行与管理职能。

（3）管理和监视工具：负责监控工作流的执行，对工作流管理系统中过程实例的状态进行监控与管理，如用户管理、角色管理、审计管理、资源控制等。

（4）工作流客户应用：执行者访问工作流的界面，活动参与者通过这样的应用程序参加工作流活动，获取自己的任务。

（5）工作流引擎：过程定义的解释器，它是工作流执行服务的核心。

（6）被调应用程序：工作流执行服务在过程实例的运行过程中，调用的、用以对应用数据进行处理的程序。在过程定义中包含这种应用程序的详细信息如类型、地

址信息等。

（7）其他工作流执行服务：在大型的工作流管理系统中，工作流可能需要多个工作流引擎共同完成，甚至需要其他异质的工作流执行服务来辅助完成，这涉及到工

作流管理系统之间的互联。

其中过程定义通常包括一些独立的活动步骤，相关的计算机和用户通过一系列的活动步骤操作或制定规则以管理流程的步骤。

参考模型中定义的五类工作流接口。

（1）接口1（工作流定义转换）：工作流服务和工作流建模工具间的接口，包括工作流模型的解释和读写操作。

（2）接口2（客户端应用程序接口）：工作流服务和客户应用之间的接口，这是最主要的接口规范，它约定所有客户方应用与工作流服务之间的功能操作方法。

（3）接口3（应用程序调用接口）：工作流引擎和直接调用的应用程序之间的直接接口。

（4）接口4（工作流机协作接口）：工作流管理系统之间的互操作接口。

（5）接口5（管理和监视接口）：工作流服务和工作流管理工具之间的接口。

在实际的应用中，很多商用和开源的工作流系统都没有严格遵照这个标准，或者说没有统一。一个原因是WfMC的标准对于很多细节没有明确说明，在实现时各个系统出现了各自的实现。另一个原因是，工作流系统与业务系统关系密切，受业务系统的限制或约束太大，因此支持不同业务的工作流在细节上差异很大，标准不易统一，做

一个通用的工作流系统难度比较大。

3.1过程定义

1过程定义工具（Process Definition Tools）

过程定义是用来创建一个计算机可以处理的形式的过程描述。可能要以形式过程定义语言、对象关系模型、简单的系统、脚本、或者在参与者间进行信息传递的路径集为基础。工作流定义工具，可能作为工作流产品的一部分、也可能作为业务过程分析产品的一部分来提供给用户，作为业务过程分析产品一部分，会有其他的组件来负责处理业务过程的分析或者模型，这时，必须要有兼容的转换格式，与运行时期的工作流软件进行过程定义的相互转换。有许多不同的工具可以用来分析、建模、描述业务过程；这样的工具有很大的不同从非正式的（铅笔和纸）到成熟的、十分专业。工作流模型不关心这些工具的特性，也不关心在过程建立时期他们是如何交互的。在以前指出过，这些工具可以作为工作流产品的一部分来提供，或者一个单独的产品，例如BPR工具集。

有的工作流产品提供了其自己的过程定义工具，从而过程定义一般是保留在工作流产品范围内的，并且可能或者不能被读/写信息的编程接口所访问。而使用单独的过程定义和执行服务器产品，过程定义能够在不同的产品间进行转换，并可以被其他产品访问。

设计活动和最后的过程模型输出，称为过程定义。在运行时期过程定义可以被工作流机解释。

过程分析工具、建模工具和定义工具，都要有在一个组织结构中模拟过程的能力（尽管这不是工作流参考模型规定必须有的）。如果组织模型集成到了这些工具中，那么过程定义将包含组织相关对象。这些都是与系统相关的控制数据，例如角色：活动者间的关系，可能会在过程执行期间被引用。工作流定义转换（接口 1）

在建模或定义工具与运行时期工作流管理软件间的接口，被称为过程定义导入/导出接口。这个接口的特点是：转换格式和API调用，从而支持过程定义信息间的互相转换。这个接口也支持已完成的过程定义间的互相转换，或过程定义的一部分。例如，过程定义的改变或者活动中属性的改变。

使用标准的过程定义格式有很多好处：

首先，把建立阶段与运行时期环境进行了分离，可以使用一个建模工具来产生过程定义，这个过程定义可以作为很多个不同工作流运行时期产品的输入。从而用户

可以单独地选择建模工具和工作流运行时期产品。

其次，可以为几个工作流机输出过程定义，这几个工作流机合作来构成分布式的工作流执行服务器。

WFMC在此部分作了以下两个方面的工作：

（1）提出了一个元模型，可以用来表示过程定义中的对象、对象间的关系和属性。这个元模型为不同的产品间的过程定义相互转换奠定了基础，并形成了一套转换

格式。

（2）工作流系统间或工作流系统与过程定义产品间的API调用，提供了公共的方法来访问工作流过程定义。访问可能是读、读/写或者只写操作，并且操作标准对

象集合（在元模型中定义的对象集合），或者产品自己的对象集合。

3基本元模型（A Basic Meta-Model）

WFMC开发了一个过程定义的元模型。元模型中定义了基本的对象类型集，来满足简单的过程定义相互转换。或者有开发者具体扩展，或者在增加的功能中定义另

外的一致性级别来增加更多的对象类型。

需要为下边的类型定义特殊的属

性：

工作流类型定义（Workflow Type Definition）

? 工作流过程名

? 版本号

? 过程开始/结束条件

? 安全、审查、控制数据

活动（Activity）

? 活动名

? 活动类型

? 进入动作和离开动作

? 其他约束

转移条件（Transition Conditions）

? 执行条件

工作流相关数据（Workflow relevant data）

? 数据名与路径

? 数据类型

角色（Role）

? 名称与组织实体

? 应用程序调用（Invoked Application）

? 类型和名称

? 执行参数

? 本地或者访问路径

在分布式工作流服务器中，可能要在过程定义时，为每个工作流机分配活动，可以作为活动的一个附加属性。过程定义能影响安全性与管理。定义的交换格式，要支持符号命名方案，这些符号可以映射到工作流执行服务器中的实际名称与地址。这种映射可以使用动态地址定位机制来实现（例如，目录服务器），也可以使用其他的外部过程定义机制实现。也有其他的一些行业在相关的方面作研究，例如过程建模和CASE转换工具；WFMC提出的方法也适用与其他行业，预

先定义适当的转换格式。

4访问过程定义的 API（APIs to access Process Definitions）

用来支持访问过程定义数据的API命令集。希望规范中包含下边列出的通用类型功能。命令集应该提供命令操作表，和操作的对象、属性，包括：

建立会话（Session Establishment）

? 连接/断开参与系统间的会话

工作流定义操作（Workflow Definition Operationis）

? 从过程定义库或者其他资源中，获得工作流过程的名称列表

? 选择工作流过程定义，为更多的对象级操作提供会话句柄

? 读/写上层工作流过程定义对象

工作流定义对象操作（Workflow Definition Object Operations）

? 创建、恢复、删除工作流定义中的对象

? 恢复、设置、删除对象的属性

3.2工作流执行服务

1什么是工作流执行服务器

由一个或多个工作流机构成的软件服务器，用来创建、管理、执行工作流实例。应用程序可能会通过WAPI来与这个服务交互。

在模型中，过程与活动控制逻辑间有一个逻辑上的分离，活动控制逻辑构成工作流执行服务器；过程与应用工具间、与终端用户任务间也有一个逻辑上的分离，应用工具和任务建立起对每个相关活动的处理。这种逻辑上的分离，为制定更多的行业标准提供了机会，也为在工作流程序中集成用户具体的应用工具提供了机会。

使用下边两个接口中的一个，就可以使工作流机访问外部资源：

客户端应用程序接口（The client application interface），通过这个接口工作流机可以与任务表处理器交互，代表用户资源来组织任务。然后由任务表处理器负责，从任务表中选择、推进任务项。由任务表处理器或者终端用户来控制应用工具的活动。

应用程序调用接口（The invoked application interface），允许工作流机直接激活一个应用工具，来执行一个活动。典型的是调用以后台服务为主的应用程序，没有用户接口；当执行活动要用到的工具，需要与终端用户交互，通常是使用客户端应用程序接口来调用那个工具，这样可以为用户安排任务时间表提供更多的灵活性。

在分布式的工作流执行服务器中，每个工作流机控制过程执行的一部分，并与这部分过程中的活动所要用到的用户、应用工具进行交互。在分布式的执行服务器中有公共的名称空间与管理范围的，从而过程定义、用户/应用程序的名称在一致的标准下被处理。分布式工作流系统，在工作流机间采用特殊的协议和信息转换格式，来同步工作流机的操作、过程交换和活动控制信息。也许工作流相关数据也要在工作流机间进行传递。在单一的工作流执行服务器中，这些操作都是由开发商自己定义的。

在工作流机间需要一个标准的交换格式，来实现异种产品间的调用。使用接口4，执行服务器可以把活动或者子过程转移到另外一个（异种）执行服务器中执行。在工作流参考模型中，这被称作“工作流机交互（Workflow Engine Interchange）”。

2过程和活动状态变迁（Process and Activity Transitions）

工作流执行服务可以看作是一个状态变迁机器，过程或者活动的实例在响应外部事件、工作流机负责的控制判断后，其状态发生改变。

下图描述了过程实例的基本状态变迁方案：

在上图中，发生状态转移（用箭头表示）来响应WAPI的命令；过程定义中的转移条件满足，也可能发生状态转移。

初始化（Initiated）—过程实例被创建，包括与过程状态相关的日期、工作流相关数据，但是过程还没有满足条件，不能执行。

运行（Running）—过程实例已经执行，过程中的活动如果条件满足就可以执行。

激活（Active）—过程中的一个或者多个活动已经被执行。

挂起（Suspended）—过程实例被静止，并且过程中的活动不能执行，直到过程返回到运行状态。

结束（Completed）— 过程实例满足结束条件；所有的完成后操作都将被执行（例如记录日志、或者统计信息），并且销毁过程实例。

终止（Terminated）— 过程实例在正常结束前被停止；所有的完成后操作都将被执行（例如记录错误信息、或者恢复数据），并且销毁过程实例。

活动是不能被中断的，例如工作流执行服务器一旦开始了一个活动，就不能挂起或者终止这个活动。这就意味着，只有在所有运行中的活动结束后，并且过程返回到运行状态，才能对过程执行挂起、重启、终止等命令。另外，可能需要把几个活动放在一起作为“原子单元”，这些原子单元要执行就全部被执行完，如果中途出现异常则返回到开始点，重新执行。可中断活动的处理办法和原子活动单元的重新启动能力，需要进一步的考虑，这超出了WFMC的初期工作范围。

忽略那些额外的复杂事物，活动实例的基本状态和转移如下图：

一个活动的基本状态有：

初始化—过程实例中的活动已经被创建，但是还没有激活（例如，活动的进入条件没有满足），并且没有任务需要处理。

激活 —创建好的任务，分配这个活动来处理。

挂起—活动实例被静止，并直到活动返回到初始化状态，才能为其分配任务。

结束 —活动实例执行完成。

当然，一个产品也可以实现一些其他的状态类型，或者使用不同基本状态和转移来代表上图中的状态和转移。参考模型没有指定工作流系统的内部行为，但是状态

转移阐明了，API命令集的影响范围的基本观点。工作流应用编程接口与数据交换（Workflow Application programming Interface & Interchange）

WAPI可以被看作是一套由工作流执行服务器支持的API调用和数据交换集合，这个集合在在工作流执行服务器的边界处，负责与其他资源交互。尽管结构中涉及到了WAPI中的5个接口，但是每一个接口中的许多功能都是公共的（即，同时被2个或者多个接口共同拥有）。

WAPI的主要功能由API调用组成。同时在WFMC也定义了接口间的，数据转换格式，例如过程定义。工作流控制，工作流相关数据和工作流应用数据

工作流执行服务器维护内部控制数据，来确定过程实例或活动实例的状态，并支持其他内部状态信息。这种内部控制数据不能被访问，也不能进行转换。但是有些信息内容是要对外提供的，来响应某些特殊操作（例如，查询过程状态等）。同种工作流执行服务器可能在工作流机间交换这些信息，通过使用具体的内部对话。

工作流控制数据—由工作流管理系统和（或）工作流机管理的内部数据。

工作流管理系统使用工作流相关数据来判断转移条件是否满足，并选择下一个要执行的活动。这些数据能被工作流应用程序访问，这些数据也需要通过工作流执行软件在活动间传递。当在同种环境下进行操作时，如果过程的执行要在2个或者多个工作流中进行，那么这些数据就要在工作流机间进行传递；这个过程可能需要名称映射

或者数据转化。

工作流相关数据—工作流管理系统用来判断过程中状态转移是否可以执行的数据。过程实例中的每个活动中可能都需要进行数据操作。因此，工作流模型必须能够在所有的处理活动间的“情形数据”交换。在一些环境中，可能需要情形数据在不同的工具数据格式间进行转换，例如，把文档从一种格式转成另外一种格式。（有的系统中，数据转换是工作流执行服务器来完成的；有的系统中直接把数据转换定义成过程中的一个活动来执行）

工作流应用程序数据—应用程序的具体数据，并且不能被工作流管理系统访问。

工作流应用程序数据不能被工作流执行软件所使用，只与应用程序或者用户任务的执行相关。就像工作流相关数据一样，在同种执行服务器中应用程序数据会在工

作流机间进行传递，来保证活动的正常执行。

应用程序与其需要用到的工作流相关或应用程序数据间的关系，会在工作流定义中说明。在一些情况下，可能是隐含关系（例如，在一些系统中情形数据会作为活动导航的一部分，传递到下一个活动中），然而在其他情况下（例如访问共享对象存储），就需要明确定义对象的名字和应用程序的访问路径。在参考模型中，把前一种情况

称为“直接数据交换”，后一种称为“间接数据交换”。数据交换（Data Interchange）

工作流相关数据和应用程序数据的交换，都需要访问WAPI，来支持在3个运行时期功能中的协同工作：

? 任务表处理器（Interface 2）

? 应用程序调用（Interface 3）

? 工作流机交换（Interface 4）

本节讲述数据交换的基本原理；提出了API命令集，包括从工作流机中接收/返回工作流相关数据的具体调用；并为直接数据交换和间接数据交换定义了，与上述

API命令集不同的命令集。

由Email驱动的工作流系统是一种典型的应用程序数据的直接交换，这样的系统中，应用程序数据物理地在活动间进行传递。这种情况下，不需要明确定义活动与应用程序数据间的关系；应用程序数据作为标准工作流活动导航的一部分进行传递，并且在应用程序调用时在本地直接与程序相关。需要在活动间提供数据格式转换时，应用程序需要定义与之相关的数据类型，可以作为一个属性来定义（这个属性信息可能存放在软件执行环境中，或者能被整个工作流执行服务器访问，例如地址目录）。这样，使用同种工作流应用程序构造的系统，就能够根据每个应用程序所定义的数据类型进行数据转换。需要采用一些协议来传递和保存数据类型信息，例如使用 X.400 对象标识符，或者Internet mail MIME机制。

一些类型的工作流系统（例如，使用共享文档存储实现的），在活动间不能从物理上传递应用程序数据。在这些系统中，应用程序要使用适当的访问路径才能进行数据访问。这样，必须要有统一的访问路径命名方案，必须是有效的访问权限，并且由激活的过程实例来控制访问权限。在这种情况下，如果需要，在建模时，数据格式转换

也可以作为一个活动。

同种系统中可能使用私有的对象命名协定和访问权限，但是异种系统需要一个公共的方案。在异种系统中，在过程定义时必须包含对应用程序数据对象存储的访问

路径，或者在活动间的导航必须包含访问路径的传递。

同种工作流产品进行协调工作，其必须采用相同的应用程序数据交换方法，或者通过一个网关机制进行协作，网关机制通过适当的协议，可以在两种不同的数据交换方法间进行映射，也可以处理对象命名与数据类型转换的不同。以后还需要对这部分进行细化，但有可能制定一个交换标准，来包含上述的两种情况。

工作流应用程序或相关数据交换的方法，都是通过3个接口来处理的；下边列出了这3个接口：

客户端应用程序接口—工作流相关数据可以包含在任务中。工作流相关数据也可以通过共享的对象存储形式来间接传递。

应用程序调用接口—依靠应用程序调用接口进行数据转换，可能需要在调用服务中把数据包含在具体应用程序协议中。激活的工作流应用程序可以使用，读/写工作

流相关数据的API，或者用这些API来构造通用应用程序代理。

工作流机协作接口—与客户端应用程序接口相似，尽管在不同的系统中支持不同的应用程序数据交换方法，但是网关功能的使用，需要在两种方法间进行映射，也

要处理名称问题。

3.3工作流客户应用：

1工作流客户端应用程序（Workflow Client Applications）

任务表处理器是在需要调用人类资源的活动时用来与终端用户进行交互的软件。任务表处理器可以作为工作流产品的一部分提供给用户，也可以由用户自己开发。在其他情况中，工作流可能要与普通的办公系统进行集成，例如Email，来为终端用户提供一个统一的任务管理系统。这就要求在工作流执行服务器与工作流客户端应用程序

间有一个非常灵活的通信机制，来构建各种可能遇到的运行系统。在工作流模型中，通过客户端应用程序与工作流机间的定义良好的接口进行交互。在这个接口中包含任务表—由工作流机分配给用户的任务序列。最简单的情况是，工作流机访问任务表，来把任务分配给用户；任务表处理器访问任务表，向任务表中添加任务项。有许多不同的产品来实现任务表的交互。

任务表中任务项的激活（例如，启动应用程序，连接工作流相关数据），可能是由工作流客户端应用程序或者终端用户控制的。在工作流客户端应用程序与工作流执行服务器间定义了一系列的方法，用来向任务表中添加任务项、从任务表中删除完成的活动、激活临时挂起的活动，等。

任务表处理器也可以调用应用程序，或者直接调用，或者由终端用户调用。通常希望，任务表处理器的应用程序调用范围能够受到运行环境的限制，尽管这样会给

模型带来通用性的限制，但这种情况是一直存在的。

与任务表相关的部分活动的数据，是任务表处理器用来调用应用程序所必须的信息。当应用程序数据是强类型时，在任务表处理器中要存放一个联接，用来实现程序的调用。在其他情况中，在任务表处理器与工作流机间要进行完全的应用程序名称和地址信息的交换；这时，工作流客户端应用程序也可能实现一些应用程序调用接口（接

口3）中的功能，来获得必要的信息。

任务表中可能要包含一个过程中的几个不同实例的相关任务，或者包含几个不同过程中的一个共同活动项。一个任务表处理器可能要与几个不同的工作流机、几个不同的工作流执行服务器进行交互。（按照每个产品的实现，为每个过程单独维护一个物理上分开的任务表，或者任务表处理器把几个不同的任务表联合到一起，呈现给终端

用户）

因此，客户端工作流应用程序与工作流机间的接口必须十分灵活，来满足下边的几方面功能的实现多样性：

? 过程和活动表示符

? 资源名和地址

? 数据引用和数据结构

? 可选择的通讯机制 工作流客户端应用程序接口（接口 2）

满足上述需求的方法，在标准API集后，可以为从工作流应用程序到工作流机和任务表的访问提供一致的形式，而不管产品的实现特性。

API与其参数可以映射到几个不同的通信机制上，来适应各种不同的工作流实现模型。

WFMC在其文档中，分开发布API规范；下边是对客户端应用程序API使用的一个概述，分成几个不同的功能。提供了对单独或者多个过程活动实例的操作命令，就像任务表一样。

建立会话（Session Establishment）

? 连接/断开参与系统间的会话

工作流定义操作（Workflow Definition Operations）

? 对工作流过程定义名称或者属性的恢复/查询功能

过程控制功能（Process Control Functions）

? 创建/开始/结束一个过程实例

? 挂起/唤醒一个过程实例

? 在过程实例或活动实例中强制一个状态发生改变

? 查询过程实例或活动实例的属性

过程状态功能（Process Status Functions）

? 打开/关闭过程实例或活动实例的查询，设置过滤标准

? 获取过程实例或活动实例的详细信息

? 获取具体过程或活动的详细信息

任务表/任务项处理功能（Worklist/Workitem Handling Functions）

? 打开/关闭任务表查询，设置过滤标准

? 获取任务表中的项目

? 通知选择/重分配/结束一个任务项

? 查询任务项属性

过程管理功能（Process Supervisory Functions）

? 改变过程定义或者它的实例的运行状态

? 改变某种类型的所有过程实例或活动实例的状态

? 为某种类型的所有过程实例或活动实例的属性赋值

? 终止所有过程实例

数据处理功能（Data Handling Functions）

? 恢复/返回工作流相关或应用程序数据

应用程序调用（Application Invocation）

? 上边对功能的概括，为支持任务表处理器对应用程序调用提供了基础。应用程序调用功能的一些命令是与客户端应用程序环境相关的。

? 有些产品可以只实现全部WAPI的一部分；以后会给出进一步的考虑，定义一致性级别，来满足市场中不同的产品间的，不同的协作需要。

3.4被调应用程序：

1应用程序调用（Invoked Applications）

所有的WFM产品都没有足够的逻辑单元，知道如何调用所有的应用程序，这些应用程序存在异种的产品环境中。这就需要，能够处理在所有平台下和网络环境中进行调用的逻辑，并需要能使用公共格式和编码进行应用数据或相关数据传递的方法。

然而，许多工作流系统能够使用了更多受限制的应用程序，特别是那些采用强制数据类型和直接与应用程序相连的系统。在其他情况中，应用程序对操作的调用，可能是通过标准的交换机制来实现的，例如OSI TP协议或者X.400。一些实现使用了“应用程序代理（Application Agent）”，把这些在在标准接口之后的各种方法包含在工作流执行服务器中。也有可能开发“Workflow enabled”应用工具，这种工具使用标准的API集来与工作流执行服务器进行通信，来接收应用程序数据、信号和响应活动事件等。这些API可以被应用工具直接调用；也可以被应用程序代理过过程调用，作为与其他应用程序（不包含任何工作流技术的程序）交互的前端。应用程序调用接口（接口 3）

下边是接口3的结构，“工作流”类型的应用程序或应用程序代理，可以直接使用这个结构。

在简单的情况中，工作流机在本地处理应用程序调用，使用过程定义中的信息来确定，活动的性质、将要调用的应用程序的类型和所需的数据。被调用的应用程序可能存储在工作流机中，或者与工作流机一同存储在相同的平台下，或者存放在一个独立的网络访问的平台中；过程定义中有足够的应用程序类型和寻址信息（工作流机的特殊需求），来实现应用程序调用。在这种情况下，应用程序命名与寻址的协定是处于工作流机与过程定义之间的。

应用程序调用API的详细语法、语义作为WFMC规范的一部分给出。操作覆盖了一些不同的基本接口，包括上表中的一部分，其中一些操作是同步的，一些是异步的。API的操作可以是单线程的，也可以是多线程的，后者使用活动ID来区分线程。下边是应用程序调用可以使用的一些命令概括：

创建会话（Session Establishment）

? 连接/断开应用程序会话

活动管理功能（Activity Management Functions）

? 开始活动

? 挂起/恢复/放弃活动

? 活动完成通知

? 信号事件

? 查询活动属性

数据处理功能（Data Handling Functions）

? 提供工作流相关数据

? 提供应用程序数据或数据地址

更复杂的情况，异种工作流机间的协同工作，可能需要在工作流机间传递应用程序调用信息，或者作为运行时期数据交换的一部分，或者通过在过程定义阶段后导

入过程定义来实现。

3.5其他工作流执行服务：

WFMC的一个主要目标是，为不同开发商的工作流系统产品，相互间能够进行无逢传递任务项，定义标准。

工作流产品的特性变化多样。在WFMC的协同工作标准中，没有强迫开发商必须提供一个只面向用户需求的产品或者只考虑协同工作。

WFMC把焦点聚集到，开发多种不同的协同工作框架，这些框架可以操作一系列标准的协调工作，从简单的任务传递到整个工作流系统的协同工作（包括过程定义转换、工作流相关数据交换、通用的界面等）。简单的协同工作，WFMC的协同工作定义将在最初就能支持；而复杂的协同工作，还需要进一步的研究。

尽管可以开发一个非常复杂的协同工作框架，由许多个工作流机构成个执行服务器，但是这种框架不会在近期实现，因为这需要所有的工作流机都可以解释一个公共的过程定义和共享公共的工作流控制数据集，事实上是维护异种工作流机间的一个共享过程视图。现阶段更现实的目标是，能够在运行时期传递过程的某些部分，来支持不

同的执行服务器运行。

WFMC定义了4个协同工作模型：链锁式，子过程嵌套，P2P（Peer-to-Peer），相似同步，包含多种协同工作能力级别

3.6管理和监视工具：

WFMC规范的最后关注的是为管理和监视功能开发公共的接口标准，这样一个开发商的产品就可以用来管理其他工作流机的运行。通过公共的接口，几个不同的工

作流执行服务器可以共享，管理和监视功能。

尽管，过程状态命令在接口定义中已经描述了，但一致认为，在某些行业中需要，进行全部状态监视和提取信息的功能。WFMC提出的接口，是要让用户能够得到工作流运行状态的完整视图，无论是什么样的工作流系统；同时，也希望能提供一套全面的功能集，进行系统管理，包括安全性、控制和权限。

接口中包含WAPI集中的一些具体命令，来操作管理和监视功能。另外，进一步的讨论，期望能够确定在什么范围内，这个接口可以使用现有的协议（如CMIP、SNMP），来设置、恢复管理状态和统计信息（定义在开放MIB中——Management Information Base）

“工作流” 已经成为了一个事实存在的概念和名词，可是到了2007年依然找不到没有能够明确的定义,在互连网上，我们随便在GOOGLE或百度上搜索，找到关于工作流的内容及定义可以说是百家争鸣，是标准、是引擎、是技术、解决方案、是思想、是架构。。到底是什么？

工作流到底是什么呢，对于从事做计算机软件设计的人而言，它是一项技术、是我们为我们的客户提供解决方案框架的一部分；对于从事企业信息化管理的人而言，它是一种思想，是我们降低用户的IT运维成本的一种方法；对于从事软件开发的人而言，它是一个架构，是我们如何利用成熟稳定的接口和组件低成本的开发出适应用户流程变化的应用程序。总而言之，工作流通过技术的手段，融入管理思想、为管理提供“人、事、物、流程、时间、条件”等多维管理能力，帮助用户实现管理目标。

既然今天谈的是“工作流”技术，那文章的重点就是占在技术的角度来讨论工作流，我们可以从以下几个方面来探讨工作流。

1、为什么要使用工作流技术

对于这个问题我们可以从软件企业的解决方案策略、用户运维的成本上及企业信息化规划等几个角度来考虑这个问题。

首先从解决方案提供者的角度来说，我们的CIO/CTO面临的一个很大的压力是在于我们为用户提供的解决方案滞后于我们的用户的商业策略，我们用户总是在变化中发展，商业策略面临着市场、竞争对手的压力而改变，而我们提供的解决方案却不能够快速适应这样的变化。工作流技术使这样的一种解决方案成为可能，同时工作流技术也为用户企业实现企业战略执行提供了实现的平台。

从IT运维的角度来说，目前很多IT公司面临了一种CTO（总体拥有成本）成本比例的变化趋势。因为大部分IT企业或IT部门的IT基础架构的现状，使我们用户运行维护的成本在逐步的升高，研发新能力的成本在逐步压缩，但我们的IT投资始终会变缓，特别是IT运行维护的成本在总体拥有成本中的比例。意味着IT企业和IT部门利益的空间将越来越小，其实我们身边的很多案例里就有很多IT企业被某些项目拖累致倒闭的现象。工作流技术可以脱离开发环境而设计业务流程的特性让企业IT运行维护成本大大的降低，从而提高了IT企业和IT部门的利益空间。

从企业信息规划的角度来说，可以回顾前些年的ERP、进销存、CRM等系统，大部分是管事的，系统主要是记录数据及其关联关系等，是静态为主的，但随着社会的发展与竞争格局的变化，企业的策略越来越需要能随需而动，生产管理活动也始终是“人”参与的活动，很多时候人需要激励、参与、满足、约束、被管理等等才能很好达到管理目标。因此新一代管理系统中协同性、灵活性、扩展性需求相当重要，工作流是提供协同性、灵活性、扩展性的最佳工具。

2、工作流用在哪里

毫五疑问，工作流技术是软件技术，用在软件设计领域，工作流分为业务型工作流和状态型工作流，业务型工作流大部分是要用在管理软件设计领域，为管理软件提供灵活性、扩展性、协同性等特质。帮助企业实现战略管理目标。

常用的工作流应用场景：

企业办公自动化系统

IT服务管理系统

客户服务管理系统

物流揽收调度系统

设备运维管理系统

质量考核监督系统

采购系统。。

3、如何使用工作流及哪些人使用

很多时候工作流是一个看不见摸不着的东西，存在于我们的业务管理系统软件中，至于如何使用、哪些人使用可以从几个方面说明。

工作流引擎是系统功能，是软件本身去使用的，工作流架构是包含工作流引擎使用、接口调用、业务系统应用框架的，是开发人员使用的，开发人员在工作流架构上设计开发包含工作流技术的不同业务领域的软件系统。

工作流平台一般是包含流程设计工具的，由企业流程管理用户去使用，通过工作流平台提供的流程管理工具将企业的战略和制度转化为执行语言。

软件系统普通用户使用的则仅仅是包含企业战略执行语言的业务管理系统。

4、工作流技术的选型

关于工作流技术的选型，对于从事IT工作的人员来说是一个需要非常慎重选择，在这里做些简单的阐述，工作流技术分为两种。一种是业务流程型的，比如我们的一些事件处理、服务流程、物流揽收调度、合同审批、设计审核等，需要工作流引擎根据各种表单的内容来人机交互来自动管理这个过程；另一种是状态机型的，根据一件事情的状态变化而自动进行处理，如工业控制，电路控制管理等。常用于一些工业自动化控制系统等。

我们经常听到有人说工作流引擎可以很快的就配置出一个业务系统出来，自定义表单，自定义流程，自定义报表等等，很快就给用户提供一个完整的业务系统，其实这样的想法是非常理想的，我们在开发我们的业务系统的时候我们会发现我们的业务系统不仅仅是功能的实现，它将面临着各个方面的需求，包括性能，并发处理能力、易用性、一致性及个性化等等，当工作流引擎只能满足60%的需求时，我们的团队将为另外的40%需求付出多少成本。因此在工作流的选型上很重要的一点就是它对于二次开发的支持，及接口的友好特性，同时它能支持我们在工作流基础上设计思路上的延续性。

因此工作流技术的选型不但要考虑工作流引擎本身功能的完整性和稳定性，工作流架构的扩展性、易用性及适应能力，还需要考虑工作流涉及开发人员、企业管理实施人员、企业用户的习惯和易用性等。纯粹的工作流的产品意义并不大，关键是否能很好的帮助企业实现管理目标。

5、工作流技术的应用

E8.Net工作流平台融入了新一代管理软件关注的重点思想，所有功能模块应用将权限体系、工作流引擎体系、表示逻辑体系、管理控制逻辑体系、扩展及个性化接口体系充分结合，从架构的设计上优化企业个性化业务系统实施成本，并通过流程管理工具，为企业实施个性化的企业流程，通过记录、监督、跟踪、回访、分析企业日常事务，持续改善企业管理流程，E8.Net工作流平台开源的开发架构设计过程中充分分析了管理行为中人的特性，基于E8开发的企业流程应用系统提供了事中监督、事后回访、全程跟踪的体系架构，E8工作流引擎功能设计中也充分考虑了流程和环节模型特性、环节行为人群体特性和中国特色，流转过程中基于权限体系提供了人为因素中“主动/被动”异常的解决思路，解决快速实施企业业务流程需求的同时，又提供了人性“非理想”状态下的异常解决方案和防范控制解决方案。

工作流技术在协同办公中的实现

http://www.xiexiebang.com 2008年10月28日 17:04 比特网ChinaByte

一、协同办公(OA)系统简介

协同办公(OA)系统是一套兼具企业信息门户、知识管理、工作流管理、人力资源管理、客户与合作伙伴管理、项目管理、财务管理、资产管理功能的协同商务平台，协同办公(OA)系统是一个数字化的企业应用环境，真正让公司所有的信息都在一个平台上管理，解决信息孤岛问题。协同办公系统本身具有的网状结构，为企业打通所有的信息节点，让企业管理者轻松穿梭在客户、员工、文档等所有的信息节点上，因为协同办公系统为您提供了一张信息网，只要您找到这张信息网中的某个节点，您就可以轻松的以这个节点为中心把企业的整个信息网都提取出来。

同时，协同办公(OA)系统可以与后台的ERP软件集成在一起，将所有利益相关者、企业部门、不同应用系统的信息整合到统一的渠道，并提供统一的界面给用户操作和提取信息，从而实现业务处理和信息获取与共享的一体化，达到内部协同和外部协同，为每一个用户提供一个完全的个性化门户，用户在这个个性化的门户中管理日常的所有事务。

二、工作流管理简介

由于工作流预先定义的特性，已设定的请求可以很容易的遵守相应的规则和实际操作情况。企业可以确信所有的请求都是根据规则和手续来输入和批准的，从而保证企业运作的规范化和透明化。上海泛微软件公司的协同办公(OA)系统中实现的工作流e-Workflow管理可以对内部以及外部业务处理采取电子化管理方式管理，工作流管理是提高组织效率的有效工具。

e-Workflow提供强大的自定义功能，支持企业复杂的工作流设置。企业可对工作流的组成因素包括流程完成需要的阶段、每个阶段的负责人、流转条件，直至相对底层的表单和字段进行自定义，使得工作流的定义完全与企业的政策和实际运营相符合，而不必进行复杂的二次开发。

e-Workflow同时也提供了可定制的浏览和报告的功能，用户可以对工作流的关键信息进行任意的定义以获得特定的报表。e-Workflow的特性可以使用户获得非常灵活和丰富的统计报告以对相关的决策作出支持。

三、工作流管理实现基本功能

1定义任意形式的工作流程

e-Workflow强大的自定义功能可以满足企业对复杂工作流程的定义，包括文档流程和表单流程e-Workflow 与 e-HRM结合对于人员在组织结构中的地位和角色将是工作流设计的基础。

2工作流执行

可设定的对工作流的执行包括提交、批准、退回、拒绝、代理、重新打开、归档等，e-Workflow会根据路由的判定条件和当前节点的执行操作设置工作流的下一目标节点。

固定流程和自由流程的结合

原则上是固定流程，应该一步步走下去，但是在某个节点，加入一个自由流程审批人可以选定下一步的审批人，然后再按照预定的流程走下去。

如：申请者-部门经理-出纳-财务经理，对于大一点的公司，有多个出纳，哪个出纳在岗，就让哪个出纳审，那么就可以把出纳那步设成自由流程，当部门经理审批完后，会自动列出所有的出纳，部门经理选择其中的一个出纳然后提交。

4表单数据自动生成

表单的有些数据，不希望由人工输入获得，e-Workflow可以根据被计算字段、原始数据和计算方法自动得出目标字段数据，并可以此作为下一路由选择的判断条件。

5跟踪和回溯

e-Workflow保留工作流流转过程中的所有信息以供查询。对于文档型的审批，可以保持痕迹。这样审批人能够一目了然知道原稿和审批稿的区别。监控和管理

对于某个模板产生的单据，可以设定监督人和管理人，这样既使他没有审批权，也可以看到该单据，同时发送催办信息。当某个单据因为某种原因需要临时更改流程时，监督和管理人可以修改流程，以避免单据的积压提高工作效率

7自动提醒

对于请求的不同状况，例如新的请求到达、待处理请求、超时未处理请求、客户联系计划、请求递交被处理状况等，系统都设定了多种提醒功能以确保请求的处理不致延误。

8流程自动激活

e-Workflow的一个强大之处就是在于它可以让系统在运作的过程中自动触发请求，并且还可以根据前一个请求的实际状况对下一个触发的请求进行智能选择。

9自动更新数据库

e-Workflow在信息流转的过程中，会自动更新系统原有的相关数据库，这是 e-Workflow 另一个重要的特性体现，通过数据自动更新，避免了二次手工录入带来的工作效率低下和失误的情况，真正实现企业管理和运营的电子化。

10分支选择流

根据上一步的选择，选择不同的分支进行流程执行。如：如果上一步是总经理审批的，会选择一个分支进行流转。如上一步是副总审批的选择另外一个分支进行流转。

11条件流转

以请款单为例：金额小于3000元，审批流程是：普通员工-部门经理。如果金额大于3000元的审批流程是：普通员工-部门经理-总经理，那么在流程定义的时候，需要根据单据的填写值进行判断，系统自动选择流程。

12传阅、归档等的并发流

如有一个流程：申请者-副总经理的一张单子，申请者需要提交副总审批的一张单子，不需要部门经理审批，但是需要让部门经理知晓，称为传阅的并发流。同理有归档或者其它的并发流。这种并发流的特点是一个流程的执行过程中，会产生另外的的流程，互不影响。

13流程门户定义

通过与企业信息门户的结合，e-Workflow实现流程定义的门户化，根据不同的信息门户设定不同的流程。

四、小结

工作流技术的出现和迅速发展为企业先进制造战略的实施提供了重要的技术支持。本文提出了分布式工作流建模工具的设计框架，以 SOA设计模式，通过三层结构的方式很好的实现了工作流建模工具、逻辑、数据、视图的分离，使得系统在可扩展性、可靠性与实用性方面都大大提高。以此为原型开发的泛微e-Workflow工作流管理系统很好的配合了工作流引擎的设计。在实际中的初步应用表明该系统通过分析企业不同类的经营过程，采用有向图的方法对现实的企业活动进行形式化描述，并严格定义组成有向图的各类元素的行为特征，从而明确建立企业经营过程到工作流模型的映射机制.使其与企业现有应用结合形成一个完整的过程体系。责任编辑：胡艳丽 工作流管理技术介绍

2009-11-25 作者：葛志春 来源：希赛网

摘 要：本文主要对工作流技术的起源，工作流的概念，研究的技术的内容及工作流管理系统作了深入的介绍；并对工作流技术在国内外的应用现状及不足作了深入的分析。

关键词：工作流、表单

1、工作流技术应用背景

传统的计算机管理信息系统的主要功能有三个：即信息处理、事务处理与决策支持。信息传递和信息处理构成了企业和行政管理部门的业务工作内容之一，也是计算机信息系统的主要功能之一，它是企业和行政管理部门进行事务处理和决策支持的基础。

当PC机没有作为信息处理工具而出现的时候，纸张是进行日常业务活动不可取代的载体。这种传统的纸张为载体的信息传递与处理方式的效率很低，需要花费相当的人力、物力来完成信息的处理、组织、存储以及查询检索，同时这种方式降低了对客户需求的响应速度，给企业和行政管理部门的生产经营都带来了及不利的影响。在计算机得到了广泛普及、计算机应用水平日益提高的情况下，企业与行政管理单位的工作人员希望能够以一种无纸化的、计算机使能的工作环境来开展日常业务工作。一些企业和行政管理部门因此建立了相应的文件、表单传递系统（Forms-routing applications）用来实现日常表单处理的电子化与自动化。这种简单的文件、电子表单系统可以看作是工作流应用的雏形。

企业的经营过程是由一系列相关的任务组成的；这些任务按照企业的管理规章与业务流程串行或并行的执行，最终完成企业的经营目标。自从进入工业化时代以来，有关过程的组织管理与流程的优化工作就一直在进行，它是企业管理的主要研究内容之一。只不过在没有引入计算机信息系统的支持以前，这些工作是由人工来完成的。随着市场经济的发展，市场竞争的日益激烈，企业要求其业务过程能够进行快速重组；业务过程的不断变化也相应要求信息系统能够快速重组。这样，单靠人工对企业过程进行重组和传统的面向功能的信息化计算机系统已经不能适应现代企业的发展。因此，企业希望有一种能够实现企业快速业务流程重组和业务过程自动化的软件系统。在计算机网络技术和分布式数据库技术迅速发展、多机协同工作技术日臻成熟的基础上于20世纪80年代中期开始提出了工作流的概念。工作流技术的提出与发展为企业更好的实现这些经营目标提供了先进的手段。

随着经营业务的展开企业的物理位置逐渐分散、部门间的协作日益频繁；决策过程的分散性也日益明显，对日常业务活动详细信息的需求也日益提高。因此，企业又要求信息系统必须具有分布性、异构性、自治性。在这种大规模的分布式应用环境下高效地运转相关的任务，并且对执行的任务进行密切监控已成为一种发展趋势。在这种技术背景下，工作流管理系统也有最初的创建无纸化办公环境，转而成为同化企业复杂信息环境、实现业务流程自动化的必要工具。这样的一个转变，把工作流技术带入了一个崭新的发展阶段，使得人们从更深的层次、更广的领域上对工作流展开了研究。

1993年工作流技术的标准化组织工作流管理联盟（Workflow Manangement Coalition 简称：WfMC）.的成立标志着工作流技术在计算机应用领域之中被明确的划分出了自己的一席之地，相应的概念与术语也得到了人们的承认。在全球范围内，对工作流的技术研究以及相关的产品开发了进入了更为繁荣的阶段。

2、工作流定义

工作流是从英文单词Workflow翻译而来的。Work表示工作或任务；Flow则表示流动、流程或者流量。Flow反映了一种变化及变化的过程，本身意义比较抽象，但是当它与某一个具体过程相联系时就有了具体的含义，如电流、水流、气流。在经营管理与生产组织中Flow也有重要的意义，如表示物料传输过程的物料流、表示资金流动的资金流、反映信息处理和传递过程的信息流，同样还有价值流、决策流、控制流等概念。依此，用活动及活动之间变化的过程表示的业务流程就是工作流。

十几年来，不同的研究者和产品供应商从不同的角度给出了工作流的定义，但到目前为止，对于工作流仍没有统一的定义。下面列举了一些有代表性的定义，可以使我们对工作流的一些基本特征有一定的理解。

WfMC的定义：工作流是一类能够完全或者部分自动执行的经营过程，根据一系列过程规则，文档、信息或任务能够在不同的执行者之间传递、执行。

Forrester Report的定义：日常的业务处理或协同工作能按预先定义好的规则和过程进行流动，并且这一流动过程能被跟踪和监控。

Giga Group的定义：工作流是经营过程中可运转的部分，包括任务的顺序以及由谁来执行它，支持任务的信息流、评价与控制任务的跟踪、报告机制。

IBM Almaden Research Center的定义：工作流是经营过程中的一种计算机化的表示模型，定义了完成整个过程所需用的各种参数。这些参数包括对过程中每一个单独步骤的定义、步骤间的执行顺序、条件以及数据流的建立、每一步骤由谁负责以及每个活动所需要的应用程序。

Amit Sheth 的定义：工作流是涉及到多任务协调执行的活动，这些任务分别由不同的处理实体完成。一项任务定义了需要做的某些工作，它可以以各种形式来进行定义，包括在文件或电子邮件中的文本描述、一张表格、一条信息以及一个计算机程序。用来执行任务的处理实体可以是人，也可以是计算机系统（如：邮递员、一个应用程序、一个数据库管理系统）。

以上这些定义，虽然表述方式略有不同，但是基本上都说明了这样一个问题，即工作流是业务过程的一个计算机实现，而工作流管理系统则是这一实现的软件环境。使用工作流作为业务过程的实现技术首先要求工作流系统能够反映业务过程的如下几个问题：即业务过程是什么（有哪些活动、任务组成，也就是结构上的定义）、怎么做（活动间的执行条件、规则以及所交互的信息，也就是控制流与信息流的定义）、有谁来做（人或计算机程序，也就是组织角色的定义）、做的怎样（通过工作流管理系统对执行过程进行监控）。因此，可以说工作流是一种反映业务流程的计算机化的模型，它是为了在先进计算机环境支持下实现经营过程集成与经营过程自动化而建立的可由工作流管理系统执行的业务系统。

3、工作流技术研究的主要内容

工作流技术，在初期主要由工作流产品供应商推动其发展。随着工作流产品在实际应用中不断取得良好的效果而得到了人们日益的重视，并且到了迅速发展。相对于工作流产品的繁荣，工作流相关理论研究则显得滞后。在过去很长一段时间里，有关工作流技术方面的研究主要有商品化的工作流产品供应商所领导。本着把工作流产品推向市场的目的，这些供应商大多把研究的注意力放在工作流管理产品的开发实施方面。目前在工作流设计方法学，工作流概念模型等方面还没有形成一套比较成熟的理论和方法。在工作流理论与实施技术方面，研究的主要内容包括：

工作流管理系统体系结构；

工作流模型与工作流定义语言；

工作流的事务特性；

研究如何实现高级事务处理技术与工作流管理技术的结合，用定义良好的模型语义与恢复机制来提高工作流系统的正确性与可靠性，从而能够更好的支持复杂的业务过程；

工作流实现技术：包括面向对象技术、异构分布式计算技术、图形化用户界面、消息通信、数据库、WEB等在内的与工作流系统的设计实现有关的各项技术及方法；

工作流的仿真与分析方法；

基于工作流的应用集成与互操作技术；

研究异构应用系统的集成以及不同工作流系统之间的互操作问题；

工作流与经营过程的重组：研究如何通过工作流系统的实施支持快速的实现经营过程重组；

工作流技术的其他应用：研究如何将工作流技术在不同的领域进行运用，包括在CIMS中的应用。

上述主要研究课题可以归纳为三个方面（如图1）：第一方面是工作流的理论基础，包括工作流管理系统的体系、模型与定义语言（工作流的建模方法、工作流模型的形式化表示、工作流定义语言）等的研究。这一部分是工作目前相对来说比较薄弱，还有许多问题需要进一步研究。第二方面是工作流的实现技术，包括工作流的事务特性、各种先进软件技术的应用、工作流仿真。这方面研究工作的目标是提高工作流管理系统的性能，尤其是提高工作流管理系统可靠性及其在处理大规模复杂的且具有并行业务的流程方面的能力。第三方面是工作流技术的应用，包括工作流实施技术在不同应用领域的应用（如在企业经营过程重组、并行过程、敏捷制造）方法、应用软件集成等。这几方面研究的目标是发挥工作流管理系统的优势，为解决具体应用领域内的问题提供有向实现手段。

图1：工作流技术研究内容

4、研究工作流的意义

工作流技术的应用将给组织单位带来巨大的效益。首先，采用工作流管理将使组织单位改变传统的按照功能来配置人员的组织结构，变成按照要实现的主要业务流程来配置组织结构，这样可以大大缩短主要业务过程的处理时间，提高对市场的响应能力。其次，组织结构的改变将大大减少在组织内部不必要的的物料、信息的传递时间。当然，整个组织结构的调整首先需要调整传统的以部门为单位的做法，变成以项目来组织生产和人员的工作方法，如：一个人可能同时从属于多个项目。应用工作流管理系统主要可以取得如下好处：

1）提高管理的规范化程度；

2）更好地与上下游单位形成快速响应市场的供应链网络；

3）降低业务过程的整个处理时间，如在办公自动化环境中，通过更好的规划工作流程，并行执行相互独立的活动，减少文档的传递时间；

4）降低管理成本，如避免不必要的重复的工作，提高工作人员的工作效率；

5）改进工作质量，如自动完成某个任务所需要的相关信息。在客户服务中，能够快速方便的访问所有相关数据和工作流程，从而大大提高客户服务质量；

6）在工作人员之间更好的均衡负荷，如在工作人员缺勤的情况下，自动柔性分配替代人员；

7）通过在工作流模型中加入可预计的故障的处理策略来提高系统的柔性；

8）通过对已经完成的工作流实例的分析，找出存在的不足，进而不断改进工作流程；

9）使工作内容更加丰富，并且提高工作人员的业务能力，减少工作人员进行单调乏味并且十分耗时的文档查找工作。

采用工作流管理系统可以在最大程度上集成组织的现有信息资源，实现资源的充分利用。由于工作流管理系统具有较好的柔性和开发性，因此，可以保证信息系统能够顺利的扩展以满足不断变化的市场环境。另外，工作流管理系统在工作流模型的基础上进行业务过程进行，这就意味着信息系统已经从过去没有一个具体的可量化指标的管理信息系统，发展到了一个建立在工作流模型上（并且是可以利用BPR或者其他仿真工具进行优化后的模型），按照预先定义好的规则进行执行，并且对于执行的结果随时进行监控和评价的规范化阶段。这种由过程建模—〉模型分析—〉过程优化—〉执行结果—〉统计分析—〉改进业务过程—〉优化运作的实施方法为成功地实施信息系统奠定了坚实的基础。

5、工作流管理系统

工作流技术是当今一项飞速发展的技术，它最基本的特性就是它能够结合人工和机器的行为，特别是能够与应用程序和工具进行交互，从而完成业务过程的自动化处理。

工作流是业务的自动化处理过程，在这个过程中，根据预定义的规则将文档、信息在过程参与者中传递，最终完成业务的处理。工作流管理系统（WFMS）是通过管理一序列工作行为以及与活动步骤、相关人员、资源设备来提供业务处理程序上的自动控制，它是通过计算机软件来定义、管理和执行工作流，计算机的执行顺序是由工作流逻辑的计算机描述来驱动的。

工作流管理系统主要具备以下三个功能特征，如图2：

工作流定义功能，主要是对业务处理过程的计算机定义，提供了一种或多种分析、建模、系统定义技术，将一个现实世界的业务处理过程转换成计算机可处理的定义；最终的定义叫作过程模型、过程模版或过程定义，可以表现为文本、图形或自然语言符号。

运行控制功能，对过程的定义进行解释，创建并控制过程的运行实例，调度过程的各种行为步骤，调用适当的人工和IT应用程序资源；工作流管理系统的核心部件就是工作流管理控制软件（工作流引擎）。

运行交互接口，提供与人员或IT应用程序工具进行交互接口来处理各种活动步骤，交互接口对于活动间的控制传递是必须的，如确定过程的状态，调用应用程序工具，传递应用程序数据等。

图2WFMS的三个特征

6、工作流管理系统的分类

根据所实现的业务过程，工作流管理系统可分为四类：

1)管理型工作流（administrative workflow）：在这类工作流中活动可以预定义并且有一套简单的任务协调规则，例如，大学里的课程选修，完成论文后的学位申请等。

2)设定型工作流（ad hoc workflow）：与管理型工作流相似，但一般用来处理异常或发生机会比较小的情况，有时甚至是只出现一次的情况，这与参与的用户有关。

3)协作型工作流（collaborative workflow）：参与者和协作的次数较多。在一个步骤上可能反复发生几次直到得到某种结果，甚至可能返回到前一阶段。

4)生产型工作流（production workflow）：实现重要的业务过程的工作流，特别是与业务组织的功能直接相关的工作流。与管理型工作流相比，生产型工作流一般应用在大规模、复杂的和异构的环境下，整个过程会涉及许多人员和不同的组织。

根据底层实现技术，可将工作流产品分为三类：

1）以通讯为中心：以电子邮件为底层的通讯机制。这种类型的工作流管理系统适合于协作型工作流和不确定型工作流，而不适于生产型工作流。

2）以文档为中心：基于文档路由，它同外界应用的交互能力有限。许多基于表的管理型工作流可以用以文档为中心的工作流实现。

3）以过程为中心：这种工作流系统对应生产型工作流。它们一般建立在数据库之上，有自己专用的通信机制并且提供了同外部进行交互的接口。

根据不同工作流系统所采用的任务项传递机制的不同，市场上的工作流产品又可以划分为四类：

1）基于文件的工作流系统：以共享文件的方式来完成任务项传递。这种类型产品开发得最早、发展最成熟、其产品品种较多。代表产品有FileNet的Visual WorkFlo、IBM的FlowMark、InConcert的InConcert。

2）基于消息的工作流系统：通过用户的电子邮件系统来传递文档信息。这种类型的产品一般都提供与一种或多种电子邮件系统的集成接口。代表产品有Novell与FileNet合作开发的Ensemble、JetForm公司的InTempo、Keyfile公司的Keyflow。

3）基于Web的工作流系统：通过WWW来实现任务的协作。这一类产品起步较晚（在95年以后），但是发展迅速，其市场前景十分看好。许多供应商纷纷改进原有产品或开发新产品以增加对Web的支持。代表产品有Action Technologies公司的ActionWorks Metro、Ultimus公司的Ultimus。

4）群件与套件系统：虽然这一类产品与上面介绍的三种产品在任务传递方式上有很大程度的重叠，但是在这里却有必要把它们单独划分成一类，因为这一类产品都需要依赖于自己系统的应用基础结构，包括消息传递、目录服务、安全管理、数据库与文档管理服务等，它们本身就构成了一个完整的应用开发环境。代表产品有IBM/Lotus公司的Lotus Notes、Microsoft公司的Office与Exchange、Novell公司的GroupWise。

7、工作流管理系统的实施

工作流管理系统不同于ERP和普通的企业管理信息系统，ERP与普通的企业管理信息系统是事务处理系统，其主要目的是满足企业业务操作功能，提高企业事务处理的效率和水平。从企业整体的业务流程和企业经营目标上看，事务处理系统一般局限于解决某个或者某些领域的问题；事务处理系统的另外一个局限性是它一般局限于解决组织内部的具体操作问题，面向组织内部功能，而不是面向市场和面向客户的系统。工作流管理系统的着眼点是面向市场、面向客户，其目标是在整个企业的业务层提高企业的业务处理水平、强化企业的市场意识、提高对市场的应变能力。

由于工作流管理系统与普通事务处理系统存在显著的差别，工作流管理系统在实施方法上也不同于普通的事务处理系统。要实施工作流管理系统首先要在战略层次上对经营目标进行分析，确定战略目标和组织要求。工作流管理系统实施的层次结构，如图3。

图3 WFMS实施的层次结构

在完成了战略目标分析和工作流实施战略后，工作流管理系统才能够进入真正的实施阶段。工作流管理系统在实际系统中的应用一般分为3个阶段，如图4，即模型建立阶段、模型实例化阶段和模型行阶段。模型建立阶段通过利用工作流建模工具完成经营过程模型的建立，将实际经营过程转化为计算机可处理的工作流模型。模型的实例化阶段完成为每个过程设定运行所需的参数，并分配每个活动执行所需要的资源（包括资源、人员、应用）。模型执行阶段完成经营过程的执行，在这个过程中重要的任务是完成人机交互和应用的执行，并对过程与活动的执行情况进行监控与跟踪。

图4 WFMS 实施的三个步骤

8、国内外应用现状与不足

8.1 应用现状

目前工作流技术的研究正日益受到人们的重视，许多大学和研究机构都开展了很多研究项目，取得了重多的研究成果，对工作流技术的发展做出了贡献。

由于工作流应用环境大多是在复杂的分布异构环境中，如企业内部网或因特网，因此应用最新的分布对象处理技术和Web技术，实现工作流管理成为当前研究的重点。有影响的工作流原型系统有：

1）美国佐治亚大学研制的Meteor系统：该系统是一个支持多范型的工作流管理系统，主要用于处理医疗保健应用。多范型是指该系统能够支持分布异构环境下的企业内和企业间的各种工作流。这些工作流可以是数据库管理系统和分布式事务处理系统中的事务，也可以是EDI等特殊应用。Meteor系统可以在Web或CORBA环境下运行。

2)美国普度大学开发的CORBAflow系统：该系统提出了基于CORBA的体系结构，支持跨平台的异构分布系统集成，支持弹性ACID性质；扩展了IDL语言以定义事务性工作流中的补偿事务。

3)土耳其中东大学开发的METUFlow系统：该系统提出了一种基于CORBA环境的工作流服务，包括基于ACTA扩展事务模型的工作流模型、块结构化定义语言、工作流调度管理和并发控制机制等。

工作流的许多概念来自于办公自动化、文档管理、计算机支持协同工作(CSCW)等领域。至今约有300个称为工作流工具的商品化软件，但只有数十个是真正的WFMS软件。一些著名的WFMS产品有：

1）IBM公司的FlowMark系统［9］该系统由对象数据库管理系统ObjectStore支持。主要组件包括服务器、建立客户器、运行客户器和程序执行客户器。服务器负责与数据库交互及协调工作流执行；建立客户器提供用于设计工作流的图形接口；运行客户器提供工作表方式的用户接口；程序执行客户器提供API调用方式的应用接口。

2）Action公司的ActionWorkflow系统该系统由微软的SQL服务器或Lotus Notes支持，包含三个基本组件：①管理系统内核用于集成和管理工作流事务；②分析器提供设计工作流的专门工具；③应用建立器用于将工作流定义转化成可执行的过程。此外，还提供辅助工具，如报表器用于查询工作流的进展状态。

3）Sigma图象系统公司的OmniDesk系统它使用提供ODBC接口的数据库。其中，路径管理器用于工作流管理和负载平衡；路径建立器用于定义路径逻辑；表格建立器用于创建工作流接口。虽然OmniDesk系统主要是为图象文档管理设计的，但是也可以管理其他类型的工作流。

4）Wang公司的OPEN/workflow系统该系统建立在自含的数据库引擎之上。系统分为数据库服务、图形过程建立器、集成工具箱、报表工具。数据库服务提供基本的完整性、安全性、并发控制、恢复和管理功能；图形过程建立器用于定义过程；集成工具箱提供应用之间交互需要的API调用和通信服务；报表工具如查询建立器和报表建立器用于访问有关过程执行的信息。

8.2 工作流应用技术的不足

实际上，大多数产品的开发由于没有清楚地理解用户的需求，而不能满足用户的迫切需要。许多工作流系统主要是解决共享和协作(某些问题仍未很好解决，如异构平台环境、多媒体数据)，而像性能、可伸缩性、可靠性对于复杂应用系统来说至关重要的问题，现有工作流软件并没有考虑。主要原因是，这些系统的建立不是基于在线事务处理(OLTP)技术和数据库技术，只是使用数据库做底层存储，因而在这些领域缺乏技术成熟性和系统健壮性。

另外，由于已有的绝大多数WFMS产品和原型系统的设计是面向普通的办公室应用，因此存在以下不足：

1）工作流模型只能描述如办公自动化中电子邮件或文档等简单的工作流，而不能描述工程设计等复杂过程处理。

2）经营业务流程往往是复杂的异构环境，现有产品不能提供很好的互操作性。例如，在异构环境中，IBM的FlowMark不提供API接口以支持一个工作流的输出，作为下一个工作流的输入。

3）一个工作流可能涉及到多个单位和车间，或多个工厂和企业，例如，在虚拟制造应用中，可能包含成百上千个用户，覆盖广域网络中的数十个场地，上百台计算机系统。大多数现有工作流软件只是设计为一种协作工具，适用于小群体之间业务的工作流，在体系结构上存在缺陷，缺乏可伸缩性。

4）现代组织应用要求系统具备非常高的可用性和健壮性。现有工作流软件只适合于小团体和轻负载，缺乏有效的后备机制，不具备强的故障恢复能力。

为了进一步研究开发支持应用集成的CIMS工作流管理技术，我们认为，需要解决以下关键技术：

1）面向CIMS的工作流建模技术包括工作流模型和定义语言。如何采用弹性事务模型、分层事务模型和工程数据模型相结合的方法，设计出一种适合于CIMS工程应用的工作流模型。

2）基于CIMS信息集成平台的工作流管理系统体系结构CORBA软件总线提供了良好的平台透明性和分布透明性，以及分布对象操作能力，如何充分利用CORBA软件总线和信息集成平台，实现一个高效的工作流管理系统。 3）面向分布对象的工作流管理和执行技术CORBA软件总线系统提供了对象引用、启动和联编机制。工作流管理与执行机制需在此基础上完成作为对象任务的创建、调度、执行、提交或取消，保证工作流的正确性和可靠性。还需要考虑在CORBA软件总线上增加新的公共服务，如持久性对象仓储服务、故障恢复服务等。

4）面向CIMS目标产品的集成技术工作流管理系统是一种中间件技术，适合于任何计算机分布处理系统，在CIMS应用集成涉及的有关系统中，如PDM、MRPII等，都需要这方面的集成技术。

参考文献

[1] 林惠萍、范玉顺、吴澄，“支持企业经营过程重组的工作流仿真技术研究”，http://www.simflow.net

[2] 范玉顺，《工作流管理技术基础》，清华大学出版社，2001.4

[3] 陶冶、范玉顺、罗海滨，“分布式工作流系统的可靠性研究”，http://www.simflow.net

[4] 罗海滨、范玉顺、吴澄，“工作流技术综述”，http://www.simflow.net

[5] 范玉顺、吴澄，“基于工作流的CIMS应用集成支持系统研究”，http://www.simflow.net

[6] 刘佚名、范玉顺，“基于工作流的企业过程的建模和仿真技术研究”，http://www.simflow.net

[7] 范玉顺、吴澄，“基于协调理论的工作流建模方法”，http://www.simflow.net

[8] 陶冶、范玉顺、罗海滨，“提高分布式工作流管理系统的可扩展性”，http://www.simflow.net

[9] 鲍震宁、范玉顺，“企业组织模型结构和建模方法研究”，http://www.simflow.net

[10] 罗海滨、范玉顺、吴澄，“一种面向企业用户的工作流模型”，http://www.simflow.net