没有数据就不可能进行数据挖掘，进行流程挖掘的基础就是获得流程数据。通常在利用流程挖掘时，我们需要考虑我们的目标（期望从流程挖掘中获得什么信息，主要就是提问题）、获取数据、 流程挖掘与分析、流程改进与优化等。

    目标可能与我们的流程挖掘项目息息相关。典型的流程挖掘目标可以是回答运行流程的以下的问题：
• 流程中过去真正的发生是什么？（What really happened in the past？）
• 为什么会这样发生？（Why did it happen？）
• 未来可能发生什么？（What is likely to happen in the future？）
• 何时且为何组织或人员发生偏离？（When and why do organization and people deviate？）
• 如何更好地控制流程？（How to control a Process better？）
• 如何重设计一个流程以改进其性能？（How to redesign a Process to improve its performance？）

    获取需要的数据是流程挖掘的关键。原始数据可能来自多个数据源的多种数据格式（Excel表、交易日志、数据库表等），我们需要提取（extract）可以利用的数据内容，而进行流程挖掘需要结构化的事件日志，这意味着数据还需要一个转换（transform）的步骤，最后我们将得到的结构化数据加载（load）到目标系统中（如数据仓库或关系数据库等）。下图是典型的流程挖掘工作流，可以看出获取数据的提取、转换和加载操作（Extract，Transform，Load，ETL）。

在BI和数据挖掘的语境下，ETL这个词组被用来描述这样的流程：
（1）从外部数据源提取数据；
（2）转换提取的数据以符合后面的操作需要（比如解决语法上或语义上的问题，以保证达到预定义的数据质量要求）；
（3）将转换的数据装载到目标系统（如数据仓库、关系数据库，以方面后续利用）。

    在上面工作流程图中，ETL后面还有提取（extract）和过滤（filter）操作。新的提取操作是生成事件日志格式的数据，以符合我们进行流程挖掘的目标，比如，对流程（执行）的定义，在医疗机构中，我们流程挖掘可能关注患者的治疗路径，也可能关注用药流程（比起前者我们仅关注药物），这时候我们需要从数据仓库中提取的数据可能是不一样的。在提取需要的数据之后，过滤掉一些不是我们关注点的数据，比如一家企业的内部流程，我们关注它的销售部部门的流程，于是滤掉其他部门的数据；又或者我们关注前几种最频繁出现的流程行迹，它们最能代表实际流程的执行，从而我们需要过滤掉低频率的流程行迹。
总之，流程挖掘的数据获取是一个重要而复杂的工作，需要确定要提取到什么数据（来源、转换和存储），在使用流程挖掘解决问题时，也需要考虑不同的角度，从而去更好地利用事件数据。

    一直提到事件日志，这是由于流程挖掘对数据又结构上的要求，事件日志是流程挖掘的输入。下表是我们前面用到的流程图的事件日志片段案例，从表头我们可以看出事件日志的结构。“Case id”用于区分流程的每一次执行；每一个“Event id”从属一个“Case id”，用于指明流程执行中的每一次活动的发生；“Timestamp”指明事件发生的时间，它是流程中活动顺序的依据；“Activity”指示事件执行的活动名称，“Resource”在这里表明了事件的处理人，“Cost”指明事件产生的代价。

    由这个日志案例作为引子，我们对事件日志提出几个基本假设：
        •一个流程包含很多案例（cases）（流程执行）。
        •一个案例包含很多事件（events），每个事件只能属于一个案例。
        •一个案例中的事件是有顺序的（ordered）。
        事件可以包含其他属性（时间、活动、代价和资源等）。

    事件不是必须都含有相同的属性集，并且不是必须都要有取值的，不过对于同一活动的不同事件，通常它们拥有相同的属性集合。

    为了能够定义日志的概念，明确事件日志的要求，下面形式化几个概念。

    定义1（事件Event，属性Attribute） 令ℰ是事件域，即所有可能事件标识的集合。事件可以由一些不同的属性来表示，如一个事件可能有一个时间戳，对应一个活动，被一个特定的人执行，以及包含代价等。令 AN 是一个属性名的集合。对任意一个事件e∈ℰ和属性名n∈AN，#_n(e)为事件e的属性n的取值（value）。如果一个事件e没有属性n，则#_n(e)=⊥（空值，null）。
为了方便我们假设事件拥有以下几个标准（standard）属性：
• #_activity(e)：事件e关联的活动。
• #_time(e)：事件e的时间戳。
• #_resource(e)：事件e关联的资源。
• #_trans(e)：事件e关联的事务类型，如调度（schedule）、启动（start）、完成（complete）和挂起（suspend）。

    这些属性只是对事件属性的一些例子，并非强制的。我们还会为这些标准属性做一些方便的假设，比如时间戳在事件日志中要求是非递减的。事务类型#_trans(e)可以用来表示事件e的生命周期，下图是一个标准事务生命周期模型。

    在流程中，活动结点以标签来表示，从事件的属性中获得标签，这是分类器（classifier）的作用。一个分类器就是将一个事件的属性映射到一个标签的函数，标签是用在流程模型上的。理论上分类器可以有多个，但是在一个流程模型上通常只能使用一个分类器。我们用符号e来表示事件e在流程模型中的名称（name），下面给出其定义。

    定义2（分类器，classifier） 对任意事件e∈ℰ，e是该事件的名称。
我们将e=#_activity(e)作为默认分类器，在未来的例子中都这样使用。

分类器是一个重要概念。我们知道，事件是依附流程案例的，每个事件都是独一的，但是我们从事件日志中挖掘的流程模型是体现了活动的联系，因此需要获得事件的活动信息，分类器就是将事件映射到活动名的一个函数。也可以定义分类器将事件映射为事件执行人，从而从事件日志中挖掘社会网络。通常，分类器是取事件的某个或某些属性，然后利用这个属性来映射事件，比如上面的分类器分别取的是事件的活动名和执行人（文章中例子指resource）。

    在介绍流程案例（行迹）之前，我们先介绍序列的一些概念。

序列（sequence）
•序列（sequence，或者串string）是事件日志中行迹的最自然的表示形式。
•对于一个给定集合A，A*是定义在A的所有有效序列的集合。
•一个定义在A的长度为n的有限序列是一个映射σ ∈ {1,…,n} →A。这样的序列以一个串表示，即σ=<a₁,a₂,…,a_n>，其中a_i=σ(i)，1≤i≤n。
•σ的长度以|σ|表示，即|σ|=n。
•σ⊕a’=<a₁,a₂,…,a_n,a’>，即将a’追加在σ的末尾处。类似地σ₁⊕σ₂将σ₂追加到σ₂上，其结果长度为|σ₁|+|σ₂|。
•hd^k(σ)=<a₁,a₂,…,a_min{k,n}>，表示序列σ的前k个元素的子序列（如果长度大于等于k，长度小于k结果为原序列σ）。规定hd⁰(σ)是一个空序列。pref(σ)={hd^k(σ)|0≤k≤|σ|}表示σ的前缀集合。
•类似的，tl^k(σ)=<a_{max{n−k+1,1}},a_k+2,…,a_n>，表示序列σ的后k个元素的子序列（如果长度大于等于k，长度小于k结果为原序列σ）。规定hd⁰(σ)是一个空序列。
•σ↑X表示将σ投影到A的子集X上（X ⊆ A）。如<a,b,c,d,b,d>↑{a,b}=<a,b,b>。
•∂_set(σ)={a₁,a₂,…,a_n}，和∂_multiset(σ)=[a₁,a₂,…,a_n]。∂_set将一个序列转换为一个集合（元素不重复），∂_multiset则将一个序列转换为一个多重集（元素个数保持不变，但失去顺序信息，∂_multiset(σ)也称为σ的Parkh向量）。如∂_set(<a,b,c,d,b,d>)={a,b,c,d}，∂_multiset(<a,b,c,d,b,d>)=[a1,b2,c1,d1]。

    一个事件日志包含案例（cases），而案例包含事件。一个案例的事件以一个行迹（trace）来表示，即一个不同事件的序列。和事件一样，案例也有属性。

    定义3（案例、行迹、事件日志，case、trace、eventlog） 令𝓒为案例域，即所有案例标识（case identifiers）的集合。对任意案例c∈𝓒和名称n∈AN：#_n(c) 是案例c的属性n的值（如果c没有名为n的属性，则#_n(c) = ⊥）。每个案例都有一个特殊的必要属性行迹trace，#_trace(c) ∈𝓔^*【规定#_trace(c) ≠<>，即每个案例至少包含一个事件】。记ĉ=#_trace(c) 为一个案例的行迹的速记符号。

    一个行迹（trace）是一个有限的事件序列σ∈𝓔^*，其中每个事件只能出现一次（唯一），即对1≤i,j≤|σ|，σ(i)≠σ(j)。

    一个事件日志是一个包含案例的集合L∈𝓛，其中每个事件最多只能在整个日志中出现一次（唯一），即对任意两个不同的案例c₁,c₂∈L，∂_multiset(c₁)∩∂_multiset(c₂)=∅。

    如果一个事件日志包含时间戳属性，那么对于一个行迹中的序列中的事件，它们的时间戳必须按序列顺序非递减的，即，对任意案例c∈L和任意i、j，1≤i＜j≤|ĉ|：#_time(ĉ(i))≤#_time(ĉ(j))。

    在流程挖掘语境下，为了能够发现事件日志的流程模型，我们通常要求事件需要有活动名属性，而案例需要有行迹属性。在事件日志元素中定义了属性、事件中定义了分类器，我们可以像SQL那样来查询事件日志。