Data WareHouse
Terms
1. OLTP
On-Line Transaction Processing 联机事务处理系统(OLTP)
也称为面向交易的处理系统，其基本特征是顾客的 原始数据可以立即传送到 计算中心进行处理，并在很短的时间内给出处理结果。
这样做的最大优点是可以即时地处理输入的数据，及时地回答。也称为 实时系统(Real time System)。衡量联机 事务处理系统的一个重要性能指标是系统性能，具体体现为实时响应时间(Response Time)，即用户在 终端上送入数据之后，到 计算机对这个请求给出答复所需要的时间。OLTP是由 数据库引擎负责完成的。
OLTP 数据库旨在使 事务 应用程序仅写入所需的数据，以便尽快处理单个事务。
特点：
支持大量并发用户定期添加和修改数据。
反映随时变化的单位状态，但不保存其历史记录。
包含大量数据，其中包括用于验证事务的大量数据。
具有复杂的结构。
可以进行优化以对 事务活动做出响应。
提供用于支持单位日常运营的技术基础结构。
个别 事务能够很快地完成，并且只需访问相对较少的数据。OLTP 系统旨在处理同时输入的成百上千的 事务。
实时性要求高。
数据量不是很大。
交易一般是确定的，所以OLTP是对确定性的数据进行存取。(比如存取款都有一个特定的金额)
并发性要求高并且严格的要求事务的完整、安全性。(比如这种情况：有可能你和你的家人同时在不同的银行取同一个帐号的款)
2. OLAP
联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的，他同时提出了关于OLAP的12条准则。OLAP的提出引起了很大的反响，OLAP作为一类产品同联机事务处理(OLTP) 明显区分开来。
下表列出了OLTP与OLAP之间的比较。
| OLTP | OLAP | |
| 用户 | 操作人员,低层管理人员 | 决策人员,高级管理人员 |
| 功能 | 日常操作处理 | 分析决策 |
| DB 设计 | 面向应用 | 面向主题 |
| 数据 | 当前的, 最新的细节的, 二维的分立的 | 历史的, 聚集的, 多维的集成的, 统一的 |
| 存取 | 读/写数十条记录 | 读上百万条记录 |
| 工作单位 | 简单的事务 | 复杂的查询 |
| 用户数 | 上千个 | 上百万个 |
| DB 大小 | 100MB-GB | 100GB-TB |
| 时间要求 | 具有实时性 | 对时间的要求不严格 |
| 主要应用 | 数据库 | 数据仓库 |
OLAP是使分析人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取,从而获得对数据的更深入了解的一类软件技术。OLAP的目标是满足决策支持或者满足在多维环境下特定的查询和报表需求,它的技术核心是"维"这个概念。
“维”是人们观察客观世界的角度,是一种高层次的类型划分。“维”一般包含着层次关系,这种层次关系有时会相当复杂。通过把一个实体的多项重要的属性定义为多个维(dimension)，使用户能对不同维上的数据进行比较。因此OLAP也可以说是多维数据分析工具的集合。
OLAP的基本多维分析操作有钻取（roll up和drill down）、切片（slice）和切块（dice）、以及旋转（pivot）、drill across、drill through等。
·钻取是改变维的层次，变换分析的粒度。它包括向上钻取（roll up）和向下钻取（drill down）。roll up是在某一维上将低层次的细节数据概括到高层次的汇总数据，或者减少维数；而drill down则相反，它从汇总数据深入到细节数据进行观察或增加新维。
·切片和切块是在一部分维上选定值后，关心度量数据在剩余维上的分布。如果剩余的维只有两个，则是切片；如果有三个，则是切块。
·旋转是变换维的方向，即在表格中重新安排维的放置（例如行列互换）。
OLAP有多种实现方法，根据存储数据的方式不同可以分为ROLAP、MOLAP、HOLAP。
ROLAP表示基于关系数据库的OLAP实现（Relational OLAP）。以关系数据库为核心,以关系型结构进行多维数据的表示和存储。ROLAP将多维数据库的多维结构划分为两类表:一类是事实表,用来存储数据和维关键字;另一类是维表,即对每个维至少使用一个表来存放维的层次、成员类别等维的描述信息。维表和事实表通过主关键字和外关键字联系在一起,形成了"星型模式"。对于层次复杂的维,为避免冗余数据占用过大的存储空间,可以使用多个表来描述,这种星型模式的扩展称为"雪花模式"。
MOLAP表示基于多维数据组织的OLAP实现（Multidimensional OLAP）。以多维数据组织方式为核心,也就是说,MOLAP使用多维数组存储数据。多维数据在存储中将形成"立方块（Cube）"的结构,在MOLAP中对"立方块"的"旋转"、"切块"、"切片"是产生多维数据报表的主要技术。
HOLAP表示基于混合数据组织的OLAP实现（Hybrid OLAP）。如低层是关系型的，高层是多维矩阵型的。这种方式具有更好的灵活性。
还有其他的一些实现OLAP的方法，如提供一个专用的SQL Server，对某些存储模式（如星型、雪片型）提供对SQL查询的特殊支持。
OLAP工具是针对特定问题的联机数据访问与分析。它通过多维的方式对数据进行分析、查询和报表。维是人们观察数据的特定角度。例如，一个企业在考虑产品的销售情况时，通常从时间、地区和产品的不同角度来深入观察产品的销售情况。这里的时间、地区和产品就是维。而这些维的不同组合和所考察的度量指标构成的多维数组则是OLAP分析的基础，可形式化表示为（维1，维2，……，维n，度量指标），如（地区、时间、产品、销售额）。多维分析是指对以多维形式组织起来的数据采取切片（Slice）、切块（Dice）、钻取（Drill-down和Roll-up）、旋转（Pivot）等各种分析动作，以求剖析数据，使用户能从多个角度、多侧面地观察数据库中的数据，从而深入理解包含在数据中的信息。
根据综合性数据的组织方式的不同，常见的OLAP主要有基于多维数据库的MOLAP及基于关系数据库的ROLAP两种。MOLAP是以多维的方式组织和存储数据，ROLAP则利用现有的关系数据库技术来模拟多维数据。在数据仓库应用中，OLAP应用一般是数据仓库应用的前端工具，同时OLAP工具还可以同数据挖掘工具、统计分析工具配合使用，增强决策分析功能。
3. EDM:
EDM是 Entity Data Model 实体数据模型.
实体数据模型 (EDM) 是一个规范，用于定义由在 实体 框架 基础上生成的 应用程序使用的数据。使用 EDM 的 应用程序在设计架构中定义 应用程序域中的实体和关系。设计架构用于生成由 应用程序代码使用的可编程类。在此模型中持久保留 应用程序数据的 存储结构由另一个架构（称为存储架构）表示。映射规范用于连接设计架构与存储架构。
由于可编程对象模型是从设计架构中生成的并且存储架构映射到设计架构，因此，映射规范可以有效地将可编程类连接到 存储结构。由 EDM 定义的实体可以通过数据读取器以序列化格式读取，也可以具体化为对象。具体化的对象可以在 CLR 语言中进行编程，并可以更新以及保存，而不需要嵌入式 SQL 字符串或其他数据库语法。EDM 提供在 EDM 架构和映射规范中使用的 基本实体和 关系类型。开发人员可以根据需要扩展这些类型以支持 应用程序设计。
用于管理 应用程序中的数据的多个范例全部具有重要的优势。存储模型已经过优化，可以高效地进行存储和检索。XML 支持跨平台界限进行数据交换。 面向对象的编程是用于开发 应用程序的公认标准。这些模型都有用，但要在它们之间传输数据，可能需要与 应用程序方案无关的多行代码。
数据模型可能是以 统一建模语言 (UML) 或在白板上以图表进行的分析。无论采用哪种方法，都必须在概念上对 数据类型、其属性、数据类型之间的关系、有关数据的约束等进行整理，然后才能在 应用程序代码中实现它们。EDM 扩展了 应用程序设计人员用来在开发过程中描述数据的模型，并提供了 XML 语法以便用示意图形式详细描述结果。
4. ODS
ODS（Operational Data Store）是 数据仓库
体系结构中的一个可选部分，ODS具备 数据仓库
的部分特征和OLTP系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。
作用
一般在带有ODS的 系统体系结构中，ODS都设计为如下几个作用：
1、在业务系统和数据仓库之间形成一个隔离层
一般的数据仓库应用系统都具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容易的事。因此，ODS用于存放从业务系统直接抽取出来的数据，这些数据从 数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。
2、转移一部分业务系统细节查询的功能
在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从 粒度、组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。
3、完成数据仓库中不能完成的一些功能
一般来说，带有ODS的 数据仓库体系结构中，DW层所存储的数据都是进行汇总过的数据，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的 数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。
在一个没有ODS层的 数据仓库应用系统体系结构中， 数据仓库中存储的数据粒度是根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上也就相当于ODS，但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据，而是“历史的，不再变化的”数据。
设计方法
在数据仓库设计方法和信息模型建模方法中，前人的著作对各种思路和方法都做过大量的研究和对比，重点集中在
ER模型和
维模型的比较和应用上。根据我们的实践经验，
ER模型和
维模型在数据仓库设计中并非绝对对立，尤其在ODS设计上，从 宏观的角度来看数据之间的关系，以ER模型最为清晰，但从实现出来的数据结构上看，用维模型更加符合实际的需要。因此孤立地看 ER模型或者维模型都缺乏科学客观的精神，需要从具体应用上去考虑如何应用不同的设计方法，但目标是一定的，就是要能够把企业的数据从 宏观到微观能够清晰表达，并且能够实现出来。
设计指南
在ODS的概念定义中，已经描述了ODS的功能和特点，实际上ODS设计的目标就是以这些特点作为依据的。ODS设计与DW设计在着眼点上有所不同，ODS重点考虑业务系统数据是什么样子的，关系如何，在业务流程处理的哪个环节，以及数据抽取接口等问题。
第一步：数据调研
数据调研的内容和要求，在《调研规范》文档中做了详细定义，此处不再重复。
第二步：确定数据范围
确定数据范围实际上是对ODS进行
主题划分的过程，这种划分是基于对业务系统的调研的基础上而进行的，并不十分关心整个数据仓库系统上端应用需求，但是需要把上端应用需求与ODS数据范围进行验证，以确保应用所需的数据都已经从业务系统中抽取出来，并且得到了很好的组织。一般来讲，主题的划分是以业务系统的信息模型为依据的，设计者需要综合各种业务系统的信息模型，并进行宏观的归并，得到企业范围内的高层数据视图，并加以抽象，划定几个逻辑的数据主题范围。在这个阶段，以 ER模型表示数据主题关系最为恰当。第二步：根据数据范围进行数据分析和主题定义 在第一步中定义出来了企业范围内的高层数据视图，以及所收集到的各种业务系统的资料，在这一步中，需要对大的数据主题进行分解，并进行主题定义，直到每个主题能够直接对应一个主题数据模型为止。在这个阶段，将把第一步生成的每个ER图中的实体进行分解，分解的结果仍以ER表示为佳。
第三步：定义主题元素
定义维、度量、主题、粒度、存储期限
定义维的概念特性：
维名称，名称应该能够清晰表示出这个维的业务含义。
维成员，也就是这个维所代表的具体的数据，
维层次，维成员之间的隶属与包含的层次关系，每个层次需要定义名称
定义度量的概念特性：
度量名称，名称应该能够清晰表述这个度量的业务含义
定义
主题的概念特性：
主题名称和含义，说明该主题主要包含哪些数据，用于什么分析；
主题所包含的维和度量；
主题的事实表，以及事实表的数据。
定义粒度：
主题中事实表的数据粒度说明，这种粒度可以通过对维的层次限制加以说明，也可以通过对事实表数据的业务细节程度进行说明。
定义存储期限：
主题中事实表中的数据存储周期。
第四步：迭代，归并维、度量的定义
在ODS中，因数据来自于多个系统，数据主题划分时虽然对数据概念进行了一定程度上的归并，但具体的业务代码所形成的各个维、以及维成员等还需要进一步进行归并，把概念统一的维定义成一个维，不允许同一个维存在不同的实体表示（象不同的业务系统中一样）。
第五步：物理实现
定义每个主题的数据抽取周期、抽取 时间、抽取方式、数据接口，抽取流程和规则。
物理设计不仅仅是ODS部分的数据库物理实现，设计数据库参数、 操作系统参数、数据存储设计之外，有关数据抽取接口等问题必须清晰定义。
ODS（英语：Operational Data Store)是一种数据架构或数据库设计的概念.
集成来自多个系统的数据，应先创建数据模型（data model）。由于ODS并不属于特定的系统，因此其数据模型的设计应为主题导向式（subject-oriented），实现方法与数据仓库无异。为求快速建置以及呈现来源系统数据，实务上常见许多企业采取的做法是直接将来源系统的数据以类似复制的方式至来源系统以外的数据库，将它视为来源数据的复本，而没有进行真正的数据集成。
数据给多个系统使用的方法，包括可以将其包装成SOA的'服务'、进行分析或报表、也可以再将数据通过ETL的方式发送至其他系统。
相较于数据仓库，ODS较偏向作业（operational）面的用途，通常数据有较频繁的更新以及较短的历史，但这主要是概念上的差异，实际建置时可以创建在同一平台上，由一份数据从事两种性质的服务。
目前数据仓库厂商提出了active data warehouse概念，基本上与ODS概念极为接近，亦即数据仓库厂商认为在其解决方案中除数据仓库外也包含ODS功能。
5. E-R模型
实体-联系模型（简称E-R模型）是由P.P.Chen于1976年首先提出的。它提供不受任何DBMS约束的面向用户的表达方法，在数据库设计中被广泛用作
数据建模的工具。
分类
E-R模型的构成成分是实体集、属性和联系集，其表示方法如下：
（1） 实体集用矩形框表示，矩形框内写上实体名。
（2） 实体的属性用椭圆框表示，框内写上属性名，并用无向边与其实体集相连。
（3） 实体间的联系用菱形框表示，联系以适当的含义命名，名字写在菱形框中，用无向连线将参加联系的实体矩形框分别与菱形框相连，并在连线上标明联系的类型，即1—1、1—N或M—N。
因此，E-R模型也称为E-R图。
组成
E-R图模型的组成是由实体，属性和联系。其中实体是一个数据的使用者，其代表软件系统中客观存在的生活中的实物，如人、动物，物体、列表、部门、项目等.而同一类实体就构成了一个实体集。实体的内涵用实体类型来表示。实体类型是对实体集中实体的定义。实体中的所有特性称为属性.如用户有姓名、性别、住址、电话等. "实体标识符"是在一个实体中，能够唯一表示实体的属性和属性集的标示符.但针对于一个实体只能使用一个"实体标识符"来标明。实体标识符也就是实体的主键.在ER图中，实体所对应的属性用椭圆型的符号现况表示出来，添加了下划线的名字就是我们所说的标识符。在我们生活的世界中，实体不会是单独存在的，实体和其他的实体之间是有着千丝万缕的联系的.举例某一个人在公司的某个部门工作，其中的实体有"某个人"和"公司的某个部门"，他们之间的有着很多的联系联系.
原则
从数据需求分析中分析出系统的实体属性图，需要遵循三范式原则，对实体之间的依赖关系进行了整合，得出系统E-R图。
说明：菱形表示实体之间的关系，用矩形表示实体，用无向直线把菱形与有关实体连接，在直线上标明联系的类型。用椭圆表示实体的属性，并用无向直线把实体与属性联系起来。
特点
Entities：实体
Attributes：属性
Relationships：关系
通常有许多表
通常是满足3NF的
主键/ 外键
1对多映射
建立E-R模型是数据库概念设计的重要内容，而概念设计是设计阶段的组成部分。同时建立E-R模型的工作，属于软件生命周期的设计阶段。
数据集市(Data Mart) ，也叫数据市场，是一个从操作的数据和其他的为某个特殊的专业人员团体服务的数据源中收集数据的仓库。从范围上来说，数据是从企业范围的数据库、数据仓库，或者是更加专业的数据仓库中抽取出来的。数据中心的重点就在于它迎合了专业用户群体的特殊需求，在分析、内容、表现，以及易用方面。数据中心的用户希望数据是由他们熟悉的术语表现的。
数据仓库
是一个集成的、面向主题的 数据
集合，设计的目的是支持 DSS
（ 决策支持系统
）功能。在 数据仓库
里，每个数据单元都与特定的时间相关。 数据仓库
包括原子级别的数据和轻度汇总的数据，是面向主题的、集成的、不可更新的(稳定性)、随时间不断变化（不同时间）的数据集合，用以支持 经营管理
中的决策。
那么数据集市就是企业级数据仓库的一个子集，他主要面向部门级业务，并且只面向某个特定的主题。为了解决灵活性与性能之间的矛盾，数据集市就是数据仓库体系结构中增加的一种小型的部门或工作组级别的数据仓库。数据集市存储为特定用户预先计算好的数据，从而满足用户对性能的需求。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。
特点：
1．数据集市的特征包括规模小。
2．有特定的应用。
3．面向部门。
4．由业务部门定义、设计和开发。
5．业务部门管理和维护。
6．能快速实现。
7．购买较便宜。
8． 投资快速回收。
9．工具集的紧密集成。
10．
提供更详细的、预先存在的、数据仓库的摘要子集。
11．可升级到完整的数据仓库。
数据结构
数据集市中数据的结构通常被描述为星型结构或雪花结构。一个星型结构包含两个基本部分——一个事实表和各种支持维表。
事实表
事实表描述数据集市中最密集的数据。在电话公司中，用于呼叫的数据是典型的最密集数据；在银行中，与账目核对和 自动柜员机有关的数据是典型的最密集数据。对于 零售业而言，销售和库存数据是最密集的数据等等。
事实表是预先被连接到一起的多种类型数据的组合体，它包括：一个反映事实表建立目的的实体的 主键，如一张订单、一次销售、一个电话等等，主键信息，连接事实表与维表的 外键，外键携带的非键值外部数据。如果这种非键外部数据经常用于事实表中的 数据分析，它就会被包括在事实表的范围内。事实表是高度索引化的。事实表中出现30到40条索引非常常见。有时实事表的每列都建了索引，这样作的结果是使事实表中的数据非常容易读取。但是，导入索引所需的资源数量必须为等式提供因数。通常，事实表的数据不能更改，但可以输入数据，一旦正确输入一个记录，就不能更改此记录的任何内容了。
维表
维表是围绕着事实表建立的。维表包含非密集型数据，它通过外键与事实表相连。典型的维表建立在数据集市的基础上，包括产品目录、客户名单、厂商列表等等。
数据集市中的数据来源于企业数据仓库。所有数据，除了一个例外，在导入到数据集市之前都应该经过企业数据仓库。这个例外就是用于数据集市的特定数据，它不能用于数据仓库的其他地方。外部数据通常属于这类范畴。如果情况不是这样，数据就会用于 决策支持系统的其他地方，那么这些数据就必须经过企业数据仓库。
数据集市包含两种类型的数据，通常是详细数据和汇总数据。
详细数据
就像前面描述过的一样，数据集市中的详细数据包含在星型结构中。值得一提的是，当数据通过企业数据仓库时，星型结构就会很好的汇总。在这种情况下，企业数据仓库包含必需的基本数据，而数据集市则包含更高间隔尺寸的数据。但是，在数据集市使用者的心目中，星型结构的数据和数据获取时一样详细。
汇总数据
数据集市包含的第二种类型数据是汇总数据。分析人员通常从星型结构中的数据创建各种汇总数据。典型的汇总可能是销售区域的月销售总额。因为汇总的基础不断发展变化，所以历史数据就在数据集市中。但是这些历史数据优势在于它存储的概括水平。星型结构中保存的历史数据非常少。
数据集市以企业数据仓库为基础进行更新。对于数据集市来说大约每周更新一次非常平常。但是，数据集市的更新时间可以少于一周也可以多于一周，这主要是由数据集市所属部门的 需求来决定的。
理论上讲，应该有一个总的数据仓库的概念，然后才有数据集市。实际建设数据集市的时候，国内很少这么做。国内一般会先从数据集市入手，就某一个特定的主题（比如企业的客户信息）先做数据集市，再建设数据仓库。数据仓库和数据集市建立的先后次序之分，是和设计方法紧密相关的。
数据集市可以分为两种类型——独立型数据集市和从属型数据集市。独立型数据集市直接从操作型环境获取数据，从属型数据集市从企业级数据仓库获取数据，带有从属型数据集市的体系结构。
多个独立的数据集市的累积，是不能形成一个企业级的数据仓库的，这是由数据仓库和数据集市本身的特点决定的—数据集市为各个部门或工作组所用，各个集市之间存在不一致性是难免的。因为脱离数据仓库的缘故，当多个独立型数据集市增长到一定规模之后，由于没有统一的数据仓库协调，企业只会又增加一些信息孤 岛，仍然不能以整个企业的视图分析数据。借用Inmon的比喻：人们不可能将大海里的小鱼堆在一起就构成一头大鲸鱼，这也说明了数据仓库和数据集市有本质的不同。
如果企业最终想建设一个全企业统一的数据仓库，想要以整个企业的视图分析数据，独立型数据集市恐怕不是合适的选择；也就是说“先独立地构建数据集市，当数据集市达到一定的规模再直接转换为数据仓库”是不合适的。从长远的角度看，从属型数据集市在体系结构上比独立型数据集市更稳定，可以说是数据集市未来建设的主要方向。
案例分析
通过 吉林市等城市的成功试点， 中国移动已经决定将数据集市作为2006年移动地市级公司的建设重点之一。这也同时意味着，电信行业建立在 数据仓库基础上的BI应用已经进入到更加深入挖掘的阶段，其产生的结果将直接服务于一线的生产销售……
数据集市：深化挖掘第一步
电信行业对于数据仓库并不陌生，为了实现从产品导向往客户导向的转变，电信公司纷纷建立以客户为中心的数据仓库，希望依据 客户的需要、期望及喜好来制订策略，提升企业竞争力。简单说，数据仓库就是为了保证数据查询和分析的效率，按照主题将所有的数据分门别类进行存储，需要的时候，可以按主题提取数据并做进一步的分析处理。
数据集市，可以称作"小数据仓库"，是用来分析相关专门业务问题或功能目标而做的专项的数据集合。它建立在具有统一数据存储模型的数据仓库下，各级业务人员按照各部门特定的需求把数据进行复制、处理、加工，并最终统一展现为有部门特点的数据集合，数据集市的应用是对数据仓库应用的补充。
经过近几年的努力，吉林移动通信有限责任公司已经成功在省级公司建立起了面向决策支持的经营分析系统，BI系统也逐渐完善。省级公司从业务系统中将相关业务数据进行抽取、清洗、加工、整理、加载到数据仓库中，在数据仓库中形成基础的分析数据的存储，对地市一级公司的 营销策略进行指导。
问题也随之产生，由于下属分公司在客户群体、市场容量、利润来源等地域差异明显，省级公司通过全省范围内分公司数据的汇总和分析，难以对单个地市级分公司产生个性化决策支持。另一方面，地市一级的分公司在开拓终端市场的过程中，激发了旺盛的应用需求，具体表现为对数据粒度的要求更加精细、需求更加灵活多变、要求更强的可操作性。
2005年6月，中国移动通信有限公司制定了《中国移动经营分析系统数据集市（试点）业务技术建议书》。为了使经营分析系统在地市级公司日常生产经营中发挥更大作用，吉林移动最终决定与亚信科技合作，全面进行"数据集市"的搭建。吉林省吉林市成为12个试点中第一个"吃 螃蟹"的城市。
吉林移动希望通过数据集市的建设及时准确地了解掌握地市公司的分析需求，更好地为一线地市公司的生产营销服务。吉林市分公司也希望提升自身的经营分析水平，落实集团公司的精细化营销战略。
在总体设计方面，吉林移动希望通过吉林市的试点为吉林省其它分公司建设统一的数据集市的模型，基本涵盖地市固定统计报表及分析的需求，统一建模，统一管理。在功能上，为地市分公司的 市场营销行为提供客户个体分析，提高经营分析结果的可实施能力，支持精细化营销，支持地市开发过灵活专题分析。开发标准化、开放的数据平台，满足省内不同地市分公司更多个性化的、临时性的分析需求。
总体来说，吉林移动对亚信科技提出了很实际的业务描述，就是"以提供丰富的数据为基础，以提供简要分析功能、提高日常分析能力为主要手段，以解决各类业务目标为最终目的，大力提升地市公司数据综合运用、分析能力，大力提升分公司主动服务、主动营销效能"。
数据集市项目从2005年6月开始组织需求调研，经历了5个月的建设时间，于2005年11月底上线使用，完成了中国移动集团公司试点所要求完成的所有基本集功能以及符合吉林本地特色的扩展集的内容。
作为实施方，亚信科技在吉林数据集市建设过程中遵循了"平台标准化、业务个性化"的原则。亚信一方面在数据集市基础平台采用标准的系统软件，使数据集市的逻辑数据模型统一、标准；另一方面，在地市分公司开发应用功能时，结合本地的实际情况，体现了本地的需求特色。在项目建设期间，吉林移动曾两次就该项目建设的方法与思路向中国移动集团公司领导汇报，亚信的建设思路及建设成果得到了移动总公司的高度认可。
随着吉林移动、 云南移动等公司"数据集市"项目的成功试点，中国移动31个省的上百家地市级公司将纷纷上马数据集市项目。可以预见，2006年将是移动公司进一步深入挖掘BI应用，提升BI建设水平的一年，数据集市作为专项的数据集合与分析系统，对中国移动地市级分公司的日常经营管理将产生至关重要的作用，成为中国移动落实精细化经营策略的重点工程。