企业部署商业智能BI前，需要进行详细的分析，了解BI能为企业带来多少价值？如何提高工作效率的等等，今天我们就来聊一聊 BI 的工作原理。
一、BI的取数方式
商业智能BI是通过访问和连接业务系统数据源数据库的方式来进行取数的，不管是什么样类型的数据库，商业智能BI通过ETL连接数据库抽取业务系统原表数据到数据仓库中加工处理，最后支撑到前端的可视化分析报表展现。
商业智能BI - 派可数据商业智能BI可视化分析平台
之前有朋友这么提问的：数据源层是需要开发接口吗？
这是回答：
一般不需要，基本上这么提问的都是经历过软件系统的接口对接，软件系统的接口对接是因为有的业务软件是 JAVA 开发的，有的是 .NET 开发的，有的是 B/S 架构，有的是 C/S 架构。软件系统之间的接口是需要开发参与的，主要是串联不同软件的业务流程，这种接口是需要动代码的。 但商业智能BI在获取数据的接口不一样，是与业务系统软件自身无关的，是只需要访问和连接业务系统背后的数据库就可以的，直接从数据库取数，因此是不需要软件接口，或者没有软件接口访问这种概念的。
除非一种情况，这个业务系统是公有云，纯 SAAS 模式，这种情况下就只能通过软件对外开放的 API 接口取数了。
某医药行业销售人员绩效分析 - 派可数据商业智能BI可视化分析平台
某白酒行业渠道终端管理分析 - 派可数据商业智能BI可视化分析平台
二、报表工具是怎么来的？
这十几年我一直在技术领域、信息化领域、商业智能BI 行业，一直没有出这个圈。做过 JAVA ( AWT、SWING、JSP、Hibernate、Spring、ibatis )、.NET ( ASP、//ASP.NET、C#.NET )、Object-C 、JS 等等技术开发，业务软件系统平台开发。
早期前端技术很弱，AJAX 的实现也都需要手写，要实现一个表单内数据的点击编辑和修改需要自己用 JS DOM 操作。做报表基本上就是 JSP、ASP 脚本语言在前端嵌套 HTML 做循环输出，报表样式很原生很丑陋，稍微复杂一点的表格报表样式都需要用 JS 来调整。
那个时候用过的报表像 Crystal Report 水晶报表、润乾报表等等，在前端脚本语言中有标签直接可以引用，报表生成代替了大量的手写代码。早期的前后端技术是不分家的，http://ASP.NET 还稍微好一些，前端逐步有一些集成控件可以直接使用，JAVA 是真没有。上面说到的这个阶段大概在什么时候呢，2005年前后，2007年我觉得已经使用的很广泛了，老的 CSDN 上应该还能找到很多原始的报表标签帖子。
像老一批报表还有像金峰报表 Jreport、思达报表 StyleReport 等等在国内也有一定的市场。早在 2010 年之前，有些报表厂商的收入规模就已经突破了一个亿，说明基础报表这个市场还是非常不错的。
那个时候的报表定位是什么，就是纯粹的 Report 报表，通过程序从后台数据库中查询返回的数据聚合 List 再到前端脚本页面上绑定一下就生成了各种报表，实际上就是用在各个业务软件系统之中的报表展示，还远远没有到 商业智能BI分析这个层面。
并且还有大量的软件开发厂商实际上已经具备了很强的报表能力，不过这些报表能力并没有单独拿出来作为报表产品在市面上运营而已。
数据分析 - 派可数据商业智能BI可视化分析平台
逐步的，随着前端技术、前端框架的完善，从传统表格技术开始到了各类柱状图、条形图、饼状图的可视化展示，到了这个阶段，报表和商业智能BI的边界越来越模糊。为什么？商业智能BI的报表展现能力也就和传统报表效果大致相当，还没有出现那种自助分析、自助拖拉拽就可以实现快速多维分析的能力。
讲这么多主要想说的是我们所看到的很多商业智能BI项目都是拿报表思维去实现的，就是 SQL 到数据集到前端展现。而真正的商业智能BI思维应该是什么呢？ 多维思维、模型思维，这一点决定了一个 商业智能BI 项目的最终走向，后面会具体讲到这些点。
三、商业智能BI 和数据仓库 Data Warehouse 有什么区别和联系？
经常会碰到有人问商业智能BI和数据仓库有什么区别，实际上这个问题的背后能反映出来一些朋友对商业智能BI的理解还是有些不准确和偏差，这个问题实际上从概念上把BI和数据仓库人为的割裂了。这种情况其实也比较正常，因为大家对商业智能BI的第一印象就是各种炫酷的可视化图表、报表，再加上市面上有很多轻量的前端可视化商业智能BI分析工具，就造成大家对BI的认知就停留在可视化这部分了。
准确的来说，商业智能BI不仅仅包含前端可视化分析、报表展现的能力，更包含了底层数据仓库的建设过程。 Gartner 在上世纪九十年代就已经提到了商业智能 Business Intelligence，它更多的认为：BI是一种数据类的技术解决方案，将许多来自不同企业业务系统的数据提取有分析价值的数据进行清洗、转换和加载，就是抽取Extraction、转换 Transformation、加载Loading 的ETL过程，最终合并到一个数据仓库中，按照一定的建模方式例如Inmon 的3NF 建模、Kimball 的维度建模或者两者都有的混合式架构模型，最终在这个基础上再利用合适的分析展现工具来形成各种可视化的分析报表为企业的管理决策层提供数据决策支撑。
商业智能BI - 派可数据商业智能BI可视化分析平台
所以，可以从这里能够看到数据仓库Data Warehouse 的位置是介于可视化报表和底层业务系统数据源之间的这一层，在整个商业智能BI项目解决方案中起到的是一个承上启下的作用。如果把商业智能BI比作是一个人的话，上半身特别是脸这个部分就是颜值，下半身脚踏实地吸取大地的精华，中间这部分的腰腹核心、核心力量就是数据仓库。
那大家也会问到，市面上不是有很多直接链接数据源就可以拖拉拽分析的商业智能BI工具产品吗，不也一样可以做商业智能BI分析报表吗？这种独立的、单独的面向前端的商业智能BI分析工具，他们更多的定位是部门级和个人级的商业智能BI 分析工具，对于深层次的需要复杂数据处理、集成、建模等很多场景是无法解决的。最好的方式就是底层构建一套完整的数据仓库，把很多分析模型标准化，再利用这些前端商业智能BI分析工具结合起来，这样才能真正的把前端商业智能BI分析能力给释放出来。
很多企业认为只要买一个前端商业智能BI分析工具就可以解决企业级的商业智能BI所有问题，这个看法实际上也不可行的。可能在最开始分析场景相对简单，对接数据的复杂度不是很高的情况下这类商业智能BI分析工具没有问题。但是在企业的商业智能BI项目建设有一个特点，是一个螺旋式上升的建设过程。因为对接的业务系统可能会越来越多，分析的深度和广度会越来越多，数据的复杂度也会越来越有挑战性，这个时候没有一个很好的数据仓库架构支撑，光靠前端BI分析工具基本上是无法搞定的。
数据仓库 - 派可数据商业智能BI可视化分析平台
就像去中药店抓药一样，之所以抓药很快，是因为在抓药前，别人已经把各种原生的中药材（原始数据源的数据）分门别类清理干净放好了，这样想怎么搭配药材（维度指标组合的可视化）就很快了。
这样的企业在国内有很多，也是因为对商业智能BI理解的深度不够导致了在商业智能BI项目建设上一些方向性的错误，最后s导致商业智能BI项目很难继续推进。
所以在企业中，我们需要明确我们的商业智能BI建设是面向企业级的还是个人和部门的分析工作。如果是个人数据分析师，使用这类前端商业智能BI分析工具就足够了。如果是需要构建一个企业级的商业智能BI项目，就不能只关注前端可视化分析能力这个层面，更应该关注到底层数据架构的构建，也就是数据仓库这个层面。
四、数据仓库的建模方法论 Kimball vs Inmon 以及混合架构
数据仓库建模时商业智能BI项目建设中的重中之重，Inmon 的三范式 3NF 建模和 Kimball 的维度建模都是 商业智能BI 数据仓库建模的方法论，这两种商业智能BI建模的方式有什么区别和联系。