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

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

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

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

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

02

原型设计与用户需求分析

蓝湖的原型设计与交互页面

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

派可数据 BI 平台的可视化数据仓库建模

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

简单的 ER 模型示例图

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

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

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

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

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

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

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

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

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

在软件系统的详细设计和开发阶段，数据库表就已 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 维度建模方法论时 ), 数据仓库存在多层表设计分类的不同等等。

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

在商业智能 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 的维度建模 ( 星型和雪花型建模 )这两类。

可以想象它对 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 自动查询来呈现数据可视化报表。

第二，软件程序开发人员的角色更为细分，会包括 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 等相关话题交流，可通过下方 派小友 联系我们。

文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树首页概览31761 人正在系统学习中 相关资源：…这些部分有助于获取您的实时详细信息,而软件则在那上面工作以…

来源：weixin_39634132