基于 Cognos 的轻量级人力资源系统商业建模介绍

随着信息技术的发展，越来越多的人们开始利用商业智能的相关技术去分析处理企业的数据，为决策者提供有力的帮助。商业智能技术处理的是大量的数据，反映的是数据中的信息和知识。因此在整个商业智能项目中，对数据的建模就成为了最重要的部分。下面就通过一个人力资源领域的例子对如何建立可分析的商业模型做简要地介绍。同时介绍了如何用 Cognos 相关产品建立应用模型。

商业智能术语介绍

商业智能

商业智能（Business Intelligence: 简称 BI）是指从企业现有的数据中提取数据价值，以帮助企业做出明智的业务经营决策的相关技术，应用等。数据包括来自企业自身业务系统以及企业所处的其他外部环境中的各种数据。为了将数据转化为知识，需要利用数据仓库（Data Warehouse）、联机分析处理（OLAP）工具和数据挖掘（Data Mining）等技术。

ETL

ETL 是 Extraction-Transformation-Loading 的缩写，中文名称为数据抽取、转换和加载。 ETL 负责将分布的、异构数据源中的数据（如关系数据、平面数据文件等）抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。 ETL 是数据仓库中非常重要的一环，是承前启后的必要一步。源数据库和目标数据仓库的数据都按照一定的数据模型进行存储，ETL 完成源数据模型到目标数据模型之间的转换。关于数据模型的介绍见“数据模型”部分。

度量

测量（Measure）是分析目标的数值，是信息的某个特定切面，如某公司员工的人数，产品销售的数量等，度量存储在事实表中。

度量（Metric）是指测量的商业分布，是具备商业意义的。比如，某公司员工人数在公司部门上的一个分布情况，其数据来源于数据仓库中的星型数据模型。

事实表

每个数据仓库或数据集市都包括一个或多个事实表（Fact Table），用以捕获衡量单位业务运作的数据，如员工的历史记录，产品销售的记录等。事实表的主要特点是包含事实数据，比如说员工的记录，员工的薪资记录等。而这些数字数据可以通过汇总等聚合方式以提供可用于分析的数据。

事实表通常包含大量的行，有时当事实数据表包含大型机构一年或几年的历史数据时，可能有数亿条记录。

维度表

一般来说，一个事实表都要和一个或多个维度表 (Dimension Table) 相关联。事实表和维度表之间通过主外键相关联。维度表包含维度的详细信息，有些则指定如何汇总事实表数据，以便为分析者提供有用的信息。

如事实表包含产品销售的记录，其中只存储了被销售产品的产品代码，而产品具体的描述信息则存储在相对应的维度表中，事实表和产品维度表通过产品代码这个键进行关联

维度表包含帮助汇总数据的特性的层次结构（Level）。例如，包含地域信息的维度表通常包含国家，省，市，县等层次结构。

上面介绍了商业智能和数据仓库中数据组织的基本概念，下面就详细介绍一下数据模型的相关概念。

数据模型介绍

数据（Data）是描述事物的符号记录。模型（Model）是现实世界的抽象。数据模型（Data Model）是对现实世界特征的数字化的模拟和抽象。

数据模型分类

数据模型按不同的应用层次分成四种类型四种：分别是概念数据模型、逻辑数据模型、物理数据模型和应用型数据模型。

图 1. 各种数据模型在商业智能解决方案中的位置

概念型数据模型

概念数据模型（Conceptual Data Model）：简称概念模型，是面向数据库用户的信息模型，通常是企业决策者，商务领域知识专家和 IT 专家共同对企业业务系统分析的结果。概念模型是独立于任何计算机系统而实现的，是对商业概念的一个面向主题的抽象，不涉及信息在计算机系统中的表示，只是用来描述某个特定组织所关心的信息结构（数据以及数据之间的关系），是现实世界到信息世界的第一层抽象。

概念数据模型必须换成逻辑数据模型，才能在数据库管理系统（Database Management System，简称 DBMS）中实现。

逻辑型数据模型

逻辑数据模型（Logical Data Model）：简称逻辑模型，是面向数据库实现的模型逻辑模型是面向实现，是具体的 DBMS 所支持的数据模型，如网状数据模型 (Network Data Model)、层次数据模型 (Hierarchical Data Model) 等等。此模型既要面向用户，又要面向系统。

物理型数据模型

物理数据模型（Physical Data Model）：简称物理模型，是面向计算机物理表示的模型，描述了数据在储存介质上的组织结构，它不但与具体的 DBMS 有关，而且还与操作系统和硬件有关。每一种逻辑数据模型在实现时都有其对应的物理数据模型。 DBMS 为了保证其独立性与可移植性，大部分物理数据模型的实现工作由系统自动完成，而设计者只设计索引、聚集等特殊结构。其由

应用型数据模型

应用型数据模型（Application Data Model ）：简称应用模型，是面向最终用户和业务人员的模型，与具体的应用相关，描述了最终用户对数据的访问（内容，形式）的要求以及应用系统对数据的存取（性能，存储）的要求。在多维分析时一般根据数据仓库中的事实表和维度表的关联关系，采用星型结构或者雪花型结构去组织数据。雪花模型和星型模型的定义见“星型模型和雪花型模型”小节。

概念模型与逻辑模型的对比

概念模型的内容包括实体及实体之间的关系。在概念数据模型中不包括实体的属性，也不用定义实体的主键。这是概念数据模型和逻辑数据模型的主要区别。概念数据模型的目标是统一业务概念，作为业务人员和技术人员之间沟通的桥梁，确定不同实体之间的最高层次的关系。逻辑数据模型则是详细的模型阐述，在最高层次下的不同实体的属性和关系，逻辑数据模型也是业务人员和技术人员沟通不可缺少的工具。

逻辑模型与物理模型的对比

逻辑数据模型和物理数据模型之间的不同在于，逻辑模型更偏重与商业建模，使商业逻辑和关系清晰化，基本跟数据库系统的关联不大，着重于技术人员和业务人员之间的沟通，而物理模型需要确定数据库的具体的类型，从而实现数据库级别的具体信息，解决存储的问题，并且解决由于数据库设计带来的性能问题。

星型模型和雪花型模型

在多维分析的商业智能解决方案中，根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型。在设计逻辑型数据的模型的时候，就应考虑数据是按照星型模型还是雪花型模型进行组织。

当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型，如图 2 。

星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。

图 2. 销售数据仓库中的星型模型

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。如图 2-3，将地域维表又分解为国家，省份，城市等维表。它的优点是 : 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余

图 3. 销售数据仓库中的雪花型模型

星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。

轻量级人力资源系统的数据建模实现

数据建模的实现步骤包括：

分析源数据，确立商业需求和范围；
定义主题和关系，建立概念型数据模型；
定义实体和属性，建立逻辑型数据模型；
建立物理型数据模型建立；
确立 ETL 的细节信息；
建立应用型数据模型。

源数据

我们设计的轻量级人力资源系统存储的主要事实数据包括：员工的基本信息，招聘职位信息以及应聘者的基本信息。其中：

Employee 表：存储员工的最新信息；
EmployeeHistory 表：存储员工的历史信息，当员工信息发生更新时，原有的信息会储在 EmployeeHistory 表中，更新后的信息则存储在 Employee 表中，更新的发生可能与某一个具体的 Action 相关，如员工升职，降职等，也可能不与任何一个 Action 相关，如员工的联系信息发生改变；
Action 表：存储所有 Action 的信息；
JobCode 表：存储所有的 Job 信息；；
Location 表：存储所有地域的信息；
Department 表：存储所有部门的信息；
Positon 表：存储所有 Position 的信息，Job，Location 和 Department 共同确定一个 Position ；
OpenPosition 表：存储招聘职位的信息； OpenPostion 为 Postion 表的子集；
Candidate 表：存储所有应聘者的信息
R_Position_Candidate 表：存储招聘的信息
R_Employee_Candidate 表：存储员工和应聘者之间的关系，应聘者如果顺利通过笔试面试等一系列招聘过程，可能成为公司的员工；
ALXT：提供一种通用的结构，存储各种描述性信息，如在 Employee 表里员工的类型存储为 01，02 等代码，在 ALXT 表中则存储员工类型 01 代表 Regular，02 代表 Intern 等。

图 4. 源数据的逻辑数据模型

概念型数据模型

建立概念模型，需要依据源数据以及商业的需求和范围找出主题以及主题之间的关系。对于我们的轻量级人力资源系统，我们确定以下三个方面作为概念模型的主题，一是员工，二是职位，三是应聘者。

三个主题之间的关系为：一个职位可能与 1 至 N 个员工相对应，一个员工则只可能对应某个特定的职位（在此，不考虑一个员工对应多个职位的复杂情况），一个职位可能拥有多个应聘者，一个应聘者也可能应聘多个职位。应聘者有可能成为公司的员工，也有可能不被录用。具体的概念数据模型见图 5 。

概念数据模型只需要到此级别的设计，即找出主题并解释三个主题之间的关系，而不需要为主题添加各种属性。

图 5. 轻量级人力资源系统中的概念数据模型

逻辑型数据模型

基于上文的概念模型，技术人员和业务人员需要共同研究出逻辑模型，在人力资源的业务逻辑之上，不考虑物理数据库实现的问题，只是组织需要的任何的商业数据，从而形成了逻辑模型。在此，我们采用星型模型，共包含 3 个事实表以及 14 个维度表，如图 6 。

有些维度表的信息可以映射到源数据的某个特定表：如地域维度表 DIM_LOCATION 可以映射到源数据的的 LOCATION 表。然而，有些数据表则需要从源数据的某些表中提取信息，如表示经理级别的维度表 DIM_MANAGER_LEVEL 需要从源数据的 EMPLOYEE， EMPLOYEEHISTORY 以及 ALXT 表中进行提取。

POSITION 不作为维度表直接与 FACT_EMPLOYEE 进行关联，因为根据商业需求的分析，用户不需要基于 POSITION 进行划分产生的报表。而只需要基于 JOB，LOCATION，DPET 等划分产生的报表。

图 6. 轻量级人力资源系统中的逻辑数据模型

物理型数据模型

在建立基于逻辑模型的物理模型时，我们选择 DB2 作为存储数据库。在逻辑模型的基础上，需要考虑范式化过后的数据库的性能，是否有特别需要改进的地方，从而形成物理模型，如图 7 。

图 7. 轻量级人力资源系统中的物理数据模型

ETL

ETL 的过程的实现细节包括数据抽取、转换、装载，图 3-5 所示即一些简单的 ETL 的过程，包括，将时间格式从 082108 转化为 2008-08-21 ；将名字的格式抽取提炼出姓和名；或者将小数的小数位进行约束，只保留两位小数等等。这类的操作构成了 ETL 的核心。

图 8. 轻量级人力资源系统中简单的 ETL 过程
轻量级人力资源系统中简单的ETL过程

图 8 所示的是我们在进行 ETL 设计过程中的一部分数据转化的设计，包括从源数据的表格中提取员工的 Action type 和 Action reason，进行匹配，当符合某些规则时，则判断出该员工为自愿离职的员工，从而在目标数据库中进行标记等等。

图 9. 轻量级人力资源系统中的 ETL 设计

应用型数据模型

下面我们用 Cognos 的 Framework Manager 建立可以用于分析的数据立方体模型，也叫应用型数据模型。在使用 Framework Manager 建模之前，我们需要在 Cognos BI server 中配置与数据仓库的连接，之后，Framework Manager 才能连接数据仓库并读取数据。

首先将数据仓库中已经建立的数据模型导入到 Framework Manager 的工程里：

图 10. 将数据仓库中的数据模型导入 Framework Manager 工程

我们准备建立 3 个数据立方体 Employee Star， Candidate Star， Position Star. 分别存放在不同的名字空间（Namespace）中。下图是创建名字空间的操作示例：

图 11. 在 Framework Manager 中建立名字空间

下图所示为建立好的三个名字空间，分别代表了三个不同的立方体 .

图 12. Framework Manager 中建立的立方体

通过 Employee 立方体，我们希望能够得到员工工资，员工人数，新雇佣人数，升职人数，离职人数和职位变动人数在年龄，部门，地区，职位，经理级别，雇佣年限，工资等级，表现情况，性别，时间等方面的分布。

图 13 中的 EmployeeStar 为 Measure Dimension，是我们要衡量的指标，来自于事实表 FACT_EMPLOYEE，包括员工工资数，员工 ID，新员工标识符，离职标识符，升职标识符，工作变动标识符等。

与这个 Measure Dimension 相关联的 Age， Job 等称作 Regular Dimension，也被称作维度，用来衡量不同的指标在其上的分布情况。

有些维度是分级别的，比如说时间维度分为：全部，年，月，日四个级别。分级别的维度，为应用提供了钻取分析的依据，应用可以生成指标在各个级别维度上的分布情况，也可以从相应指标在高级别的维度上分布的情况下钻分析低级别的维度，同样也可以从低级别的维度上钻分析高级别的量度。每一个级别都必须有一个唯一 ID 来标识，也要有一个显示在应用中的标题来表示这个维度级别的内容。二者可以相同也可以不同。如下图所示：在时间维度的月这个级别上，我们用 [DIM_TIME] 表中的 [HR_MONTH] 字段作为这一维度级别的标识和标题。

如图 14，在 Framework manager 中 _businessKey 表示标识 _memberCaption 表示标题。

图 13. Framework Manager 中建立的度量和维度

图 14. Framework Manager 中维度级别的标识和标题
Framework Manager中维度级别的标识和标题