关于商业智能 BI 的介绍面对不同的企业客户可以从很多不同的角度展开，比如从业务角度、管理角度、数据架构角度、IT 信息化建设角度、BI 实施方法论角度等，不同的视角可以帮助企业更加全面的了解商业智能 BI，对企业在规划和建设商业智能 BI 项目会有很大的帮助。

笔者同时从事过多年的传统软件技术开发和商业智能 BI 开发工作，深感两个专业领域有所同，也有所不同。这篇文章站在传统软件开发流程的角度，对比商业智能 BI 的开发流程，谈一谈两者之间的差异。结合这种对比，再来解答一下在企业级商业智能 BI 的建设上，大家可能会存在的一些困扰，以及如何解决。

01

传统软件开发流程与商业智能 BI 开发的异同

传统软件开发从流程上来看，基本上可以分为以下几个阶段：

1. 需求分析 —— 用户需求调研、业务流程梳理、核心业务痛点分析、业务边界确认与划分等。
2. 概要设计 —— 系统基本处理流程、组织结构、功能模块划分、运行设计、异常处理设计等。
3. 详细设计 —— 数据结构、类与接口设计、技术框架设计等。
4. 编码开发 —— 根据详细设计进行程序开发与实现。
5. 测试阶段 —— 单元测试、模块测试、整体测试、日志优化调整等。
6. 交付验收 —— 软件开发项目验收、用户培训等。

视项目规划大小、企业资源投入程度决定以上各个阶段的实现的复杂程度，以及进行适当的调整。小投入、短周期的项目要求立竿见影，这种条件下就不可能做到面面俱到，但整体上基本会按照这个大流程进行。

商业智能 BI 的开发从流程上基本上和软件开发流程类似，从需求开始到设计、开发、测试与验收上线。

本质上两者都是解决企业 IT 信息化的问题，区别在于业务软件重点解决业务流程和管理信息化的问题，商业智能 BI 重点解决数据信息化和决策化的问题。

对比软件开发流程中的概要设计、详细设计与开发阶段，其中有几个环节值得注意：

第一，商业智能 BI 在可视化原型建模大多数情况下是缺失的。

第二，传统软件底层数据库设计采用 3NF 建模，而商业智能 BI 在不同的项目规划中底层数据库设计可以采用 3NF 建模，也可以采用维度建模以及两者结合的混合架构。商业智能 BI 不同的建模方式也决定了完全不同的设计理念以及开发与实现过程，例如商业智能 BI 的 3NF 建模与传统软件开发的生命周期完全不同，对 BI 开发人员的要求也有很大的差异。

第三，商业智能 BI 的开发人员大多数情况下集数据库设计、前后端一体，软件开发在人员分工上会更加细化，前后端分离。

以下从上门这几个重点环节来谈谈其中的差异。

02

原型设计与用户需求分析

在早期的软件开发领域，用户需求调研基本上都是以与业务部门访谈梳理业务流程为主，结合静态的 HTML 或 EXCEL 模拟( 以 B/S 项目为例 )向用户展示一些基本的表单样式与表单跳转( 处理流程 )来理解和确认业务，以及确认相关核心的业务字段。如今，在特别突出产品经理角色的时代，可以通过 Axure、蓝湖、墨刀、Sketch 等很多种强大的工具完整的模拟用户需求原型，效率得到了极大的提升。

但是在商业智能 BI 领域，到目前为止我们在绝大多数企业我们看到的还是十来年前的老样子，用户需求访谈调研，用 EXCEL 结合一些测试数据来模拟一些基本的可视化报表来与客户确认。实际上还是很难真正表达客户真实的分析诉求的，因为 EXCEL 图表太零散、单一，也无法表达完整的分析意图。同时，在很多实际的项目上，因为项目周期的原因，也不允许出现这种长周期的需求调研。在这一点上，派可数据在 BI 产品上做了很多努力，基本上已经很好的解决了这个问题，可以在很短的时间( 2-3 天 )给出不同的行业化可视化分析原型。

BI 原型设计的核心是什么 ？是可视化建模，而建模的核心在于数据仓库中数据分析模型的设计。

数据分析模型的搭建在商业智能 BI 领域重点其实就解决两个问题：用户要看什么数据( 指标、度量 )，从什么角度看 ( 维度 )。至于怎么进行可视化展现实际上在底层数据模型设计阶段并不重要，因为现在的 BI 工具已经完全实现了拖拉拽的操作，可以非常轻松的进行可视化报表的设计了。

在这里，有一个核心概念是派可数据在市场上反复强调的：商业智能 BI 的本质不是面向报表开发，而是面向模型开发。这里的模型重点指的就是如何组织数据( 指标 )和角度( 维度 )，形成一个具备完整分析链路( 维度中的属性层次结构 )的分析模型，可以支撑到各种灵活多变的可视化图表展现效果。

所谓面向报表开发，指的就是用户提出什么报表需求，就写 SQL 取数通过大宽表以数据集的方式支撑一个或者一张报表的呈现。这样做实际上牺牲了很多的业务可扩展性和灵活性，在面对日益累计的业务分析需求的时候，对 BI 的开发和扩展会形成非常沉重的负担。

上面讲到的建模在商业智能 BI 建模方法论中实际上体现的是 Kimball 的维度建模方法论，另外一个建模方法论则是 Inmon 的 3NF ( The Third Normal Form ) 建模方法论。两者建模方式上有很大的差异，并且 Inmon 的 3NF 建模方法论在针对 BI 的可视化原型建模过程中是无法很好的实现的。因为 Inmon 的 3NF 建模更多表达的是源自业务系统的业务过程模型，而 Kimball 的维度建模在表达分析思维模型的时候更加直观。

为什么在商业智能 BI 领域会存在两种不同的建模方式，3NF 建模和维度建模的主要差异到底在哪里 ？我们需要从根上即商业智能 BI 的底层基础 —— 业务软件系统的建模方式上来一探究竟。

03

软件系统中的3NF 建模

软件系统的开发在经历了用户需求调研、原型设计阶段之后，基本上用户的业务流程、业务需求都确认的差不多了，这时就可以进入到概要设计阶段。在这个阶段一是要进行 ER 模型的设计，同时也要进行底层数据库表的结构设计。

ER 模型 - 实体关系图 ( Entity Relationship ) 表达的是：

1. 在整个实际的业务流程中谁 ( Entity 实体 ) 与谁 ( Entity ) 发生了什么 ？例如一个客户( 实体 )下了一笔或者多笔订单( 实体 )，这个订单包含了一个或者多个商品( 实体 )。

2. 如何描述这个实体 —— 属性( Attribute ) ？比如，要记录客户的姓名、年龄、性别、联系电话、住址等，这些就都是属性。

3. 它们( Entity )之间什么关系( Relationship )？下订单就是客户与订单的关系，订单包含商品就是订单与商品的关系。同时，也描述了一个客户可以下多笔订单，一笔订单包含多个商品，这就是 ER 模型中一对一、一对多或者多对多的关系。

基于 ER 模型，在数据库设计层面，就可以进行数据库表设计建模，对应到 ER 模型：

1. 数据库表，对应到实体。通常会增加非业务性的一些额外的数据库表来支撑程序开发。

2. 数据表字段，对应到实体的属性。通常会增加主键来唯一标识一个实体、一张表。

3. 数据表关系，对应到实体与实体的关系。通常通过数据表的主外键关系来表达，形成一对一、一对多或者多对多的关系，复杂一点的还有自引用的表设计关系，比如企业的组织架构、上下级关系。

同时，基于 ER 模型和数据库表设计，也可以进行程序开发中的类 Class 和接口 Interface 的设计与定义。

在软件系统的详细设计和开发阶段，数据库表就已 3NF 的形式来进行设计开发了，3NF ( The Third Normal Form ) 三范式开发的相应要求：

1. 1NF，第一范式，最小字段、原子性不可再分。
2. 2NF，第二范式，唯一标识，可以通过主键唯一标识一条数据。
3. 3NF，第三范式，消除传递依赖，非主键列不依赖除主键列的其它字段。

关于三范式的数据库表设计规范不在这里重点阐述( 除了三范式外还有其它四范式、五范式等，读者可以搜索了解 )。

为什么软件业务系统采用 3NF 的数据库建模方式，主要有以下几个重点原因：

第一，业务系统本身描述的就是业务过程的，而业务过程在 ER 图上的表现就是实体与实体的关系。这种关系对应到数据库表的设计上就通过 3NF 来体现。

第二，消灭数据冗余。3NF 的设计规范在最大程度上消灭了数据冗余，能够更加清晰的定义业务发生的实体，实体与实体的关系。

第三，面向对象、面向接口的编程思维。对于对象 OBJECT 的定义以及 CLASS 类的实现本身也就描述了 ER 模型的实体和数据库基础表的结构和定义。

第四，业务系统重在数据的录入、修改和删除等基本操作。虽然在业务系统中也有大量的查询，但大多数都是围绕原子表进行增删改基础上的查询工作，并不是真正为分析为目的的查询 SELECT 操作。而3NF 的设计更加适合程序对数据的增删改 INSERT、UPDATE 和 DELETE 操作。

以上，从业务过程的表达与描述、ER 模型的还原、数据的操作场景以及程序设计角度定义了 3NF 在软件业务系统开发过程中的必要性。

04

BI 系统中的3NF 建模与维度建模

商业智能 BI 系统与业务软件系统的开发过程一样，都需要进行底层数据库表的设计。不同的是，在商业智能 BI 系统中，我们把这种数据库叫做数据仓库。数据仓库本质上就是一个数据库，核心区别主要在于他们解决的问题的不同，建模方式的不同( 例如使用 Kimball 维度建模方法论时 ), 数据仓库存在多层表设计分类的不同等等。

关于数据库和数据仓库的差异，读者可以通过这篇文章了解：每日小视频：数据库和数据仓库有什么区别和联系？

在商业智能 BI 领域中有很多种不同的数据仓库建模方式，例如:

• Independent Data Marts Achitechture 独立集市架构
• Centralized Data Warehouse Architecture 集中式架构
• Data Vault 架构
• Data Mart Bus Architecture 数据集市、数据仓库总线架构 ( Kimball )
• Hub and Spoke / CIF – Corporate Information Factory 集线器架构 / 企业信息工厂架构 ( Inmon )

其中最常见就是 Inmon 的 3NF 三范式建模与 Kimball 的维度建模 ( 星型和雪花型建模 )这两类。

其中最常见就是 Inmon 的 3NF 三范式建模与 Kimball 的维度建模 ( 星型和雪花型建模 )这两类。

关于两种建模的详细差别与孰优孰劣暂时不在这篇文章中展开，可以放到后续的公众号文章来阐述，我们只来谈谈它们做了什么。

Inmon 的 3NF 三范式建模如同在本文开头的第一节【传统软件开发流程与商业智能 BI 开发的异同】中提到的：商业智能 BI 的 3NF 建模与传统软件开发的生命周期完全不同。

Inmon 的 3NF 建模在商业智能 BI 的开发过程中不是以分析需求为导向的，Inmon 的做法是先集成各个业务系统的数据，再来设计 DSS ( Dicision Support System 决策支持系统 )，到最后分主题实现 Data Mart 数据集市来支撑到 Reporting 报表系统。

所以 Inmon 的建模方法论复杂就复杂在这个地方，对比业务系统的软件开发过程，就相当基于各个业务软件系统的独立的、按照 3NF 建模的数据库之上在封装、设计出一套跨业务、跨主题的大而全的 3NF 数据库。

也可以理解为：在不同特定行业和领域，Inmon 的 3NF 数据库事实上梳理了这个行业和领域的一套完整的数据库设计架构，如果基于这种基础的表架构来进行软件系统的开发，这套数据库底层表设计基本上就是其对接的全部软件系统数据库表设计之和。

可以想象它对 BI 开发人员的要求在数据仓库的设计层面几乎与软件开发人员对业务系统的数据库设计完全对等，其挑战就是：

第一，要完全理解所服务企业的全部业务，熟悉所对接的全部业务系统数据库表设计的含义。

第二，几乎是一种程序开发思维来重新按照 3NF 的设计对数据库表进行建模。

第三，长周期的调研、长周期的沟通，同时还需要把以往各个业务系统中设计不合理的因素重新规避掉。

第四，巨大的人力、时间投入成本，项目启动动辄千万级别的规模，一般的企业无力承担。

事实上，我们在很多企业看到的一些按照 Inmon 3NF 设计思想设计的数据仓库是经不起推敲的，基本上都是通过简单分层、临时表来写 SQL 拼数据集拼报表做展现，这就是一种典型的面向报表开发思维。

哪些企业做的比较好，例如传统的金融( 银行、保险)等民生领域，有几个方面的原因：

第一，这些领域是最早实现基础软件信息化的，早在 2000 年前后就已经有了非常成熟的业务系统。没有业务信息化的支撑，用户连基本银行交易都无法实现。

第二，基础业务信息化实现的早，就构成了对数据分析决策、报表统计的大量需求，因此这些领域商业智能 BI 的建设也比传统企业领先了至少十年时间。

第三，不同于传统企业 BI 的分析需求可以从某一个业务领域切入，这些行业需要一个整体的、大而全的数据标准，达到一个完整的一致性的数据仓库平台，这种就很符合 Inmon 的 3NF 建模方法论。

业务需要、有钱能投入、数据需求这几个方面的主要因素就决定了他们选择 Inmon 建模方法论的合理性。

在过去的两年我们一直在大批量的面试 BI 开发人员，可以发现大部分新进入这个行业的 BI 开发人员早期的项目经验或培训实习经验都提到了金融、银行、保险等项目经验。通过面试反馈，大部分的 BI 开发人员对于数据仓库建模了解很有限，日常的主要工作就是从已经建好的数据仓库中取数做报表开发。这也从侧面说明了这些行业的数据仓库成熟度很高，所以他们很少能碰到完整的从零到一开发数据仓库的机会。

我们再来谈谈 Kimball 建模方法论，Kimball 建模的开发过程实际上就与传统软件开发的过程和生命周期相对一致。

第一，从需求出发，通过需求分析来确认分析的数据( 指标 、度量 )、确认分析的角度或者叫看数据的角度 ( 维度 )。

第二，通过星型和雪花型建模方式来组织分析模型，进行维度建模的设计开发过程。

第三，通过 ETL 过程 ( Extract 抽取、Transformation 转换、Loading 加载 )完成从各个业务系统数据源取数、清洗、格式转换到最终适配模型层数据库表来实现数据的填充。

第四，根据项目实际的需要进行 Data Mart 数据集市的组织。

第五，分析报表可以直接从底层 FACT 事实表，也可以从 Data Mart 数据集市完成反向的 SQL 自动查询来呈现数据可视化报表。

Kimball 的数据仓库从数据表的建模角度来讲，与 Inmon 有几个重要不同：

第一，Kimball 的维度建模是反规范化的，反三范式的，因此会有大量的数据冗余，适合大批量查询，而非增删改。

第二，Kimball 从需求端往下推进，从小业务范围切入逐步扩大，在一开始不需要建立大而全的数据仓库，只解决特定业务领域的分析，取数范围从小到大。

第三，Kimball 维度建模的数据表架构( 星型和雪花型模型 )更容易表达业务分析思维，而不是像 Inmon 主要描述业务过程。

我们在外面经常听到大家提 Inmon 和 Kimball 的差别就是自上往下、自下往上，实际上就是两端，一端是需求，一端是数据。我们的习惯认为需求在上、数据在下，所以我们通常会反过来介绍：Inmon 是自下往上的，而 Kimball 是自上往下的。实际上什么方向并不重要，这都是一种表达形势。重要的是要真正理解 Inmon 和 Kimball 在商业智能 BI 项目建设过程中到底扮演了什么角色，对 BI 实施方法论有什么影响，对于企业和 BI 开发人员有提出了什么挑战和要求。

看到这里，大家可能会有以下几个疑问：

第一，Inmon 的建模方法论基本上讲明白了，Kimball 建模方法论中的星型和雪花型模型到底是什么 ？

第二，Inmon 在一开始的时候就集成了大而全的业务系统数据，所以 BI 需要什么数据就取什么样的数据，这种方式应该会更好一些。但 Kimball 并没有这样做，如何在架构上保证不断增进的业务需求不会破坏已经建好的数据仓库架构 ？

第三，维度建模的核心到底是什么，维度、事实在 ETL 中处理流程是什么，如何对他们组织并进行合理的分层 ？

第四，在文章开头提到的原型设计和维度建模有什么样的关联和联系，在实际业务分析需求过程中两者如何结合和关联 ？

第五，在维度建模过程中，Data Mart 数据集市到底应该如何定位，在实际的场景中应该如何应用 ？

对于这些疑问，我们不在这里展开，我们会陆续通过后续的文章展开分享，答疑解惑。

最后，我们仍然将数据仓库架构的设计置于整个软件开发流程和商业智能 BI 开发的流程来看，Kimball 的建模方法论是符合软件开发流程和生命周期的。

05

再看软件开发与商业智能 BI 开发

从大的开发过程上来看，软件开发解决的是业务流程的开发，商业智能 BI 解决的是数据分析的开发，本质上都是服务于 IT 信息化，我们可以通过下面的对比找到很多的对应关系，这样对商业智能 BI 的理解会更加容易一些。

可以从开发环境、开发角色、实现语言、实现效果等多个角度来对比理解：

第一，软件开发需要依赖 IDE 工具进行开发，商业智能 BI 开发同样需要。比如现在的IDEA，还有笔者早年经历过 Visual Studio、JCreator、JBuilder、NetBeans、Eclipse 等。商业智能 BI 开发环境例如派可数据 BI 可视化分析平台，以及国内外其它优秀的 BI 产品工具，都是 BI 开发的 IDE。

所以，很多企业不能简单的认为只要买了一个 BI 工具就可以解决所有的问题，它只是一个工具，在实际的 BI 项目开发过程中一样会遇到类似于传统软件开发过程中的很多挑战，例如数据仓库的设计。

第二，软件程序开发人员的角色更为细分，会包括 WEB 前端开发、后端开发、数据库设计、UI 与测试等多种角色。而商业智能 BI 在大多数情况下开发人员集数据库设计( 数据仓库设计 )、ETL 实现 ( BI 系统与底层数据的交互 )、报表开发 ( 前端可视化呈现 )为一体的角色。

在商业智能 BI 领域更加细分的角色只会在特别大的项目中出现，有专业的数据仓库架构师、ETL 开发工程师与报表开发人员，但传统上我们提到 BI 开发人员就一定是一个全栈的角色。

第三，软件程序开发人员和商业智能 BI 开发人员都需要通过 IDE 进行编程，但开发语言有很大的不同。例如软件开发人员从前端往后端看，有：HTML、CSS、JS、VUE、JQUERY、PHP、JSP、ASP.NET、JAVA、C#.NET、C、C++ 等等。商业智能 BI 开发人员主要就是 SQL 语句，再结合一些存储过程和 ETL 工具 ( Kettle、Informatica、DataStage、Pentaho )等就可以解决 BI 项目开发的问题。

05

总结

通过传统软件开发与商业智能 BI 的开发过程对比，还是可以看到很多能互相映射的地方，对于企业的 IT 信息化部门特别是有过传统软件开发和维护经验的管理人员来说，通过这篇文章可以更加清晰的理解商业智能 BI 在开发过程中的特点，也便于企业未来商业智能 BI 项目的规划与管理。

而对于商业智能 BI 开发人员来说，也可以通过上述的对比更加理解商业智能 BI，以及在与企业信息化部门、业务部门的沟通的过程中寻找更加通俗的表达方式，利于推进商业智能 BI 的建设，减少必要的工作阻力。

从职业的发展角度上来看，有过一定传统软件开发背景的 BI 开发人员对于业务信息化和数据信息化的认识会相对深刻一些，特别是经历过传统软件底层数据库设计开发的人员，再从事 BI 开发工作对于模型的建设也会更加有经验一些。重点需要转变的只是从业务过程解决思维方式到业务分析思维方式，这些可以通过努力学习和实际项目沉淀、复盘总结来有效提升的。

( 全文完，作者：派可数据 吕品，编辑：派小可)

作者介绍：十五年 IT 行业经验，从事过大型软件项目与大型商业智能 BI 项目规划、设计、开发与项目管理。商业智能 BI 行业专家，数据架构师，对于企业 IT 业务信息化和数据信息化的建设有非常深厚的认知。如需对企业 IT 信息化建设、商业智能 BI 等相关话题交流，可通过下方 派小友 联系我们。