医院的信息化与公司比还处于非常原始的阶段，对于还没“建仓”的单位来说，一上来就说要上BI，可能还没搞清楚BI是什么，以及什么是数据仓库。有一个笑话被吐槽大会作为段子说过，说的是某人要开始认真研究问题了，于是他去知乎上研究了一下。事实上，现在人们对于知识的获取除了书，那就是网络了。我也不免俗，去知乎上“研究”了一下，给大家汇报一下学习进度。
目前国内在BI这块做的不错的有两家公司：永洪和帆软，我04年接触帆软的产品finereport，对他家的东西比较熟悉。永洪这家公司，最近也在接触，永洪后面有腾讯资本注资，最近也开始在湖北发力。帆软来湖北来的比较早，大概08年左右，每年都会与他们的人接触，属于来的早的。两家公司属于竞争关系，永洪是报表BI二合一，帆软的产品线是先有报表，后有BI。帆软的报表目前在国内已经属于无敌的存在。帆软BI在永洪的分析报告里，性能上处于追赶者的角色，特别是千万级数据。当然这些都是关起门的数据，谁也没法证实。
两家公司的BI产品，如果只从界面上看，无非就是大屏、报表、多维分析。我也问过永洪的经理，这不和finereport做出来的效果一样吗？如果从数据表现形式，无非就是表格、饼、柱、折线，BI与报表有什么区别。表现形式上的确没有什么区别，BI能做出来的效果，通过报表工具也能做出来。但数据源是不同的，后面还差了一个数据仓库。
我们对数据库比较熟悉，但对数据仓库一般不太了解。我们先说下数据库的特点。数据库一般都是为相应的业务流程定制的，在设计表之间的关系时，要使用范式，范式在英文中叫Normalization，在比较老的数据库系统概论中叫第一范式、第二范式、第三范式。我们一起来回顾一下：
第一范式（1NF，First Normal Form）：列不再分
第二范式（2NF，Second Normal Form）：消除非主属性对码的部分函数依赖
第三范式（3NF，Third Normal Form）：消除非主属性对码的传递函数依赖
你也不用记，我也不会考，这个东西主要的目的就是要让每张表中存的冗余数据尽量少，较少数据的冗余度可以提供数据一致性。不然你想想，你在好几个表里都存了科室代码与科室名称，哪一天你需要把科室名称改一下，你不得把带个数据库刨一遍，少改一个地方就会造成数据不一致。实际上这样设计是非常有助于数据一致性的，但对于数据分析来说就比较可怕，你如果想在医院的HIS系统中获取一份完整的患者信息的话，需要查门诊挂号表、住院主表、LIS检验结果表、PACS影像报告表、各种药品、非药品主表、手术排班表。光病案的表都有好几套，这个信息说不定还不全。当多表联合查询时，特别是千万级的表，那个查询的速度可以把大部分人搞崩溃。
我们说的数据库主要是指OLTP数据库（OnLine Transaction Processsing 联机事务处理）。它的主要作用是用来跑业务的，每个表的数据冗余度都很低，不同的表通过主键和依赖来关联，也就是上面说的Normalization做的事。
而我们今天要讨论的数据仓库，它也是数据库，但它是OLAP数据库（On-Line Analytical Processing）。它的设计就与OLTP数据库很不一样。OLTP数据库讲究表的设计范式 Normalization，第一范式、第二范式、第三范式，根据业务类型尽量把表设计成一堆小表，然后通过主键来关联。而数据仓库则反其道而行之，数据仓库搞的叫Denormalization，它要做的是根据数据分析的目的，把相关的表通过 left join, right join，尽量整成一张表，表中的数据会存在冗余，但是查询优化方便，一张表就能把要查的都查出来。
通用数据库讲究读写均衡，数据仓库更关注读性能的优化，写性能不重要，ETL数据抽取工具定时从源数据库中抽取，频率并不高，慢就慢点呗。数据仓库建仓的过程，就是对目标数据分析的过程。我们要查什么数据，把它从数据源整合到一起，ETL定时的入仓，后面再需要用到数据时，就从数据仓库中去取，不用从多个数据源、多个业务模块单独去找。
如果说数据仓库建仓还需要懂SQL、懂ETL、做数据建模、mapping表、数据清洗、数据比对。BI需要你懂什么，BI只需要你懂数据，懂维度，懂分析方法。目前的BI工具，都做到了“低代码”，拖拽加类EXCEL公式就可完成数据可视化，大部分工具都在BI内部完成了。
一套带建仓的BI搭建，市场价格不会低于100万。如果不负责建仓，只是买它的BI工具也就六七十万。目前我接解的两家BI公司，都是跑在tomcat上的，我以前跑过tomcat的报表，出现内存泄露很崩溃，他们两家的东西大部分都是用java写的。
如果只是从界面以及demo和帮助手册上来说，平心而论，永洪做的还是要差一点。
