持续创造，加速成长！这是我参与「日新方案 10 月更文挑战」的第31天，点击检查活动详情
BI商业智能这个概念已经提出好几十年了，这个概念自身比较广泛，不同人也有不同的了解和界说，但落实到技能环节，特别是面向事务用户的环节，所称的BI，根本便是指的多维剖析或许自助报表
不论是叫自助报表仍是多维剖析，也都是一回事，都是让用户自己去经过拖拽的办法查询数据或制造报表
用户想经过BI，完成查询和报表自在，也便是能够灵敏地剖析自己想要的数据，挖掘出更大的价值
厂商想经过BI，给用户赋能，盘活用户数据价值的一起，也能体现出BI产品自身的价值
那实践的状况如何呢，BI有没有发挥出它预期的效果呢，咱们就来探究一下
BI多维剖析的实质
做技能的都清楚，要查询剖析数据，其实便是编写SQL语句去查询（咱们假设要剖析的数据都在联系数据库中，这是绝大多数BI的实践场景），那给事务人员运用的BI多维剖析的技能实质，其实便是经过页面拖拽出这个SQL
关于单表的查询，并不是很难了解和实施，选出字段再配上过滤条件及排序，和用Excel差不太多，分组汇总会稍杂乱些，但也不是多难懂
可是，有事务含义的查询常常触及多表相关，比如查询存储余额10万元以上的储户中本地人的份额，看看某月回款额与发票额的对比。这些都需求多表相关，也便是要用到SQL的JOIN
事务人员很难了解SQL的JOIN，多个表及其联系是个网状办法，要指定相关字段，还会触及自相关、递归相关还有子查询再相关的杂乱状况。三五个相关表之间的数据联系连技能人员都可能会晕，就更甭说事务人员了，这时分，界面再炫丽、操作再流通都没有什么含义了
剖析被禁锢在宽表内
多表的JOIN拖拽把用户难住了，BI厂商就只能绕路处理，总不能和用户说咱们的剖析只能根据单表进行吧（究竟相当多有事务含义的剖析都是多表的，国际是普遍相关的嘛），现在选用的变通手段便是建模，当前市场上的产品，根本都是这么做的
所谓建模，便是把表间相关运算做成逻辑视图或物理宽表，这样事务人员在查询时相当于面临的仍是逻辑上的单表，这就又变的简略了，又能够拖拽了
问题完美处理？不，并没有，宽表并不是一个好的处理方案
宽表的约束性很明显，数据冗余，维护费事这些就不说了
单单是：剖析也只能根据宽体现有的相关去做这一条，就让用户和厂商都无法忍受了
用户剖析需求超出范围，或许有变化，就得技能人员修正或许从头再做一次宽表，用户不自在，啥也得厂商帮助，今日想做的剖析，可能得一周今后才能做；厂商更不乐意，每一次修正和重做，都是人工成本，可是自己产品供给的自助相关又欠好用，也只能任用户摆布了
当然有的BI厂商的建模，不叫宽表，事实上他们也的确比宽表做了更多的准备和优化，但归根到底，不论是CUBE,仍是立方体，仍是其他姓名，实质都仍是一个宽表，逻辑上并没有脱离宽表的领域，剖析需求变化时，仍是得技能人员去改
在一个数据系统中,BI的效果原本就有限，然后还被死死的约束在了需求技能人员介入的宽表上，所谓的自在灵敏就更得打折扣了
BI厂商为什么做欠好JOIN
那为什么这么多厂商都做欠好多表的JOIN，供给的JOIN功能，用户根本不会用，只能被逼用宽表呢？
构成这些难题的根本原因是，SQL 自身关于 JOIN 的界说过于简略了，用来描绘杂乱的相关场景时，就会很难了解，简略犯晕，就像用加法来描绘乘法相同
咱们经过两个比如来看下
查询：北京号码打给上海号码的通话记载
触及通话记载表和电话帐户表以及区域表的多次相关
查询：我国司理的美国职工
人事系统里职工表，还有部分表。职工表中有所属部分的字段与部分表相关，部分会有司理，而司理也是个职工，部分表中的司理字段会再和职工表相关。这就产生相互相关的状况，转圈了
这俩比如是很正常，很普遍的查询，可是即使是技能人员来写这个SQL，也得费点劲儿，这是SQL自身的约束性构成的
BI 厂商们也没有在数据模型层面针对这个难题进行优化封装，只是简略的把表对事务人员做了可视，把技能人员都觉得难的问题丢给了没有技能才能的事务人员，那当然没人能用的起来了
更多的关于BI厂商做欠好JOIN的剖析，能够参阅： 为什么 BI 软件都搞不定相关剖析
从头界说JOIN的DQL
要处理这个难题，就需剖析研究SQL的JOIN运算，打破SQL的约束才能够
咱们发现，BI多维剖析中需求的JOIN，都归于这么3+1种状况：
-
外键相关，多对1的JOIN和LEFT JOIN
-
同维表相关，1对1的LEFT JOIN或FULL JOIN
-
主子表相关，1对多的JOIN和LEFT JOIN
-
按维对齐，1对1的FULL JOIN或JOIN，LEFT JOIN较少见
第四种维度对齐，稍有特别，但也并没有超出前三种状况的范围，所以咱们说成3+1
这儿说的是BI中的JOIN，并不是SQL中悉数的JOIN，有些相关核算依然需求原始的JOIN界说来描绘，比如做矩阵乘法，但在BI中碰不到
咱们针对这3+1种状况，从头界说JOIN运算，改造SQL语法构成另一品种似的查询语言，也便是这儿所说的DQL，它是润乾开宣布的新一代BI多维剖析引擎，D是即Dimensional维度的意思
咱们来别离看一下这几种状况下的SQL的杂乱度以及DQL是怎样处理的
外键特点化
咱们用前面说到的那个查询我国司理的美国职工的比如来看一下SQL要怎样写，职工表里有个部分外键字段指向部分表的主键，部分表里又有司理外键字段指回职工表，这是很常见的数据结构规划
SQL写出来是这样的：
SELECT A.*
FROM 职工表 A
JOIN 部分表 ON A.部分 = 部分表.编号
JOIN 职工表 C ON 部分表.司理 = C.编号
WHERE A.国籍 = '美国' AND C.国籍 = '我国'
职工表和部分表JOIN，再JOIN回职工表，也便是同一个表要衔接两次，这就起个别名。在WHERE中写上JOIN的条件和终究咱们期望的条件。整个语句要看一会才能了解
运用DQL会写成这样：
SELECT *
FROM 职工表
WHERE 国籍='美国' AND 部分.司理.国籍='我国'
这个语句中，美国职工好了解，我国司理的条件稍杂乱一点，字段有了子特点，子特点又有子特点，但并不难了解，也便是部分的司理的国籍是我国
在DQL的语法系统中，外键被当作了特点，外键指向表的字段可直接用子特点的办法引用，也允许多层和递归引用
同维表等同化
这是两个一比一的表，主键相同，在数据库规划中常常有这种状况，字段的事务分类不同，不适合都放在一个表里，太宽的表在各字段丰满度相差较大时还会构成空间冗余糟蹋，拜访功能也下降，因而常常会分到多个主键相同的表中
现在咱们要查询核算一切职工的收入
SQL中需求做JOIN：
SELECT 职工表.姓名, 职工表.薪酬 + 司理表.津贴
FROM 职工表
LEFT JOIN 司理表 ON 职工表.编码 = 司理表.编号
DQL则能够把这两个表当作一个表拜访：
SELECT 姓名,薪酬+津贴
FROM 职工表
“薪酬+津贴”的的部分实践上来自两个表，DQL把主键同维的表等同化，视为一个宽表，拜访其间任何一个均可引用其它表的字段
子表调集化
订单及订单明细是典型的主子表，前者的主键是后者的一部分
现在咱们想核算每张订单的总金额
用 SQL 写出来会是这样：
SELECT T1.订单编号,T1.客户,SUM(T2.价格)
FROM 订单表 T1
JOIN 订单明细表 T2 ON T1.订单编号=T2.订单编号
GROUP BY T1.订单编号,T1.客户
要完成这个运算，不只要用到 JOIN，还需求做一次 GROUP BY，否则选出来的记载数太多。
假如咱们把子表中与主表相关的记载当作主表的一个字段，那么这个问题也能够不再运用 JOIN 以及 GROUP BY：
SELECT 订单编号,客户,订单明细表.SUM(价格)
FROM 订单表
与普通字段不同，订单明细被当作订单表的字段时，其取值将是一个调集，由于两个表是一对多的联系。所以要在这儿运用聚合运算把调集值核算成单值。这种简化办法称为子表调集化
这样看待主子表相关，不只了解书写更为简略，并且不简略犯错
假如有多个子表时，SQL需求别离先做GROUP,然后在一起和主表JOIN才行，会写成子查询的办法，可是DQL则依然很简略，SELECT后直接再加字段就能够了
按维对齐
这儿有三个表：合同表、回款表和库存表
咱们期望按日期计算合同额、回款额和库存金额
用SQL写出来是这样的：
SELECT T1.日期,T1.金额,T2.金额
FROM (SELECT 日期, SUM(金额) 金额 FROM 合同表 GROUP BY 日期）T1
LEFT JOIN (SELECT 日期, SUM(金额) 金额 FROM 回款表 GROUP BY 日期）T2
ON T1.日期 = T2.日期
LEFT JOIN (SELECT 日期, SUM(金额) 金额 FROM 库存表 GROUP BY 日期 ) T3
ON T2.日期=T3.日期
用子查询把每个表分组汇总后再JOIN起来，假如偷闲不必子查询先JOIN后GROUP，那结果是过错的，计算值会变多。这个问题必须运用子查询
这儿触及的三个子查询都要衔接上，SQL的JOIN联系要写成若干个两表相关，在表比较多时，增删相关表有可能把某个表漏掉而没有衔接条件，呈现彻底叉乘
用DQL写出来是这样的：
SELECT 合同表.SUM(金额),回款表.SUM(金额),库存表.SUM(金额) ON 日期
FROM 合同表 BY 日期
LEFT JOIN 回款表 BY 日期
LEFT JOIN 库存表 BY 日期
在DQL中，只需把这几个表别离按日期对齐别离汇总就行了，而不必关怀这些表之间的联系，在增删表时也不简略产生遗失
假如按维对齐再与外键搅到一起，状况就会更杂乱：
咱们期望按区域计算销售员人数和合同额
用SQL写出来是这样：
SELECT T1.区域,T1.数量,T2.金额
FROM (SELECT 区域,COUNT(1) 数量 FROM 销售员 GROUP BY 区域）T1
LEFT JOIN (SELECT 客户表.区域 区域,SUM(合同.金额) 金额
FROM 客户表,合同表
WHERE 客户表.编号=合同表.客户
GROUP BY 客户表.区域 ) T2
ON T1.区域 = T2.区域
这个子查询很杂乱
而在DQL中，能够和外键特点化结合，这样查询会写成：
SELECT 销售员.count(1),合同表.sum(金额) ON 区域
FROM 销售员 BY 区域
JOIN 合同表 BY 客户表.区域
这儿又呈现了子特点，但整个语句依然很简略，DQL允许每个表独立设定计算维度，无须关怀表间相关，还能够与特点化的外键配合运用
对这些JOIN更深入的讨论，能够参阅衔接运算 1-SQL 中的 JOIN
处理相关
前面讲的这几个JOIN的比如，都是在实践使用中常见的，具有事务含义的查询需求，
这些比如都是能够用来查验BI产品的“自助”灵敏程度的，能否不需求技能人员更新模型就由完成这些查询。结果会发现，业界的大部分BI产品，不论界面多炫丽、操作多流通，都经不起这个查验
原因就在于，低层模型上，并没有处理好JOIN问题
有了DQL之后，咱们就能处理BI中的JOIN问题了
早年面的DQL比如中能够明显的看出，前3个查询用SQL的JOIN都没有了，多表变成单表了，只是字段变成有子特点了，而这并不难了解，事务人员能够驾轻就熟地搞定。最终一个按维对齐的状况虽然还有JOIN，但也很简略，用户无需关怀这些表之间的相相联系，只需向统一的目标维度对齐就行了
从头界说JOIN后，就彻底把不易于了解和拼写的JOIN变的简略易懂了，再做一个拖拽的前端界面，能让事务人员做JOIN的BI就做成了
有人可能会问，多表变一表，那不仍是宽表吗？那不也还得技能人员做吗？
DQL和宽表大有不同!!!
DQL当然也需求技能人员提早界说好元数据，可是用到技能人员的地方也仅此一次
元数据中预先界说好了各种相相联系，但并没有做实践相关，当用户在前端拖拽剖析的时分，才实时生成相关查询，不需求像宽表相同预先相关，占用数据库资源
它的相相联系只需数据表自身结构不变，就不必修正元数据，不需求像宽表相同总得从头生成，相当于一次界说能够适应无数次不同的剖析需求，它具有宽表的优势但从根本上处理了宽表的各种坏处
这便是所谓的非按需建模，建模只需考虑数据结构自身，而与用户需求无关。宽表（不论逻辑仍是物理的）则是按需建模，需求一变就要再建模
用DQL语法还能降低犯错率
很多程序员习惯用 WHERE 来写 JOIN 运算的过滤条件，表少的时分没有问题，表多的时分漏写了 JOIN 条件意味着将产生多对多的彻底叉乘，而这个 SQL 却还能够正常履行，一方面核算结果会犯错，另一方面，假如漏写条件的表很大，笛卡尔积的规模将是平方级的，这极有可能把数据库直接“跑死”！
选用DQL的 JOIN 语法，就不可能产生漏写 JOIN 条件的状况了。由于对 JOIN 的了解不再是以笛卡尔积为根底，并且规划这些语法时已经假定了多对多相关没有事务含义，这个规矩下写不出彻底叉乘的运算
关于多个子表分组后与主表对齐的运算，在 SQL 中要写成多个子查询的办法。但假如只要一个子表时，能够先 JOIN 再 GROUP，这时不需求子查询。有些程序员没有仔细剖析，会把这种写法推广到多个子表的状况，也先 JOIN 再 GROUP，能够防止运用子查询，但核算结果是过错的
运用维度对齐的写法就不简略产生这种过错了，不论多少个子表，都不需求子查询，一个子表和多个子表的写法彻底相同
DQL还能让数据结构显得更为明晰
这是咱们平时看到的E-R图，它是个网状结构的，表与表之间可能都有相关，表多了就会显得很零乱，增删表的时间很简略遗失或重复表间的相关。
而在DQL系统下看到的表间相关是总线式的：
表与表之间没有直接的相关，都只处在中间地位的维度相关，增删表的时分不会影响到其它表，数据结构耦合度低
不过，要阐明的是，不论是E-R图仍是后边的总线图，其间连线的数量都是相当的，这是数据联系自身决定的，不会由于改变了看待办法而变少，只是总线式看着更明晰些
DQL让BI告别了宽表，完成了更大程度的自在自助；也拓宽了BI剖析的鸿沟，让剖析能够应对更多的数据场景，让BI成了更自在更好用的新一代的BI
告别宽表的新一代BI
DQL从低层模型上处理了JOIN的问题后，前端的界面要怎样来做其实也就变的简略了，不需求再费心去想怎样样规划才能让用户更好的了解数据了，由于不论怎样做，都能轻松了解拖拽了
下面是润乾根据DQL完成的一套界面，咱们仍是按前面的比如，挨个看看每个JOIN是怎样呈现给事务人员，怎样拖拽的
外键相关—我国司理的美国职工
经过DQL解析后，数据就都变成事务人员能够了解的明晰的树状结构了
原先的两个表变到一个表里了，事务人员已经彻底不必去管后台是几个表，怎样相关了，直接拖拽职工姓名，再拖拽部分司理姓名，然后再设置一下两个的国籍，就能够了
同维表相关
相同的，多表变一表，主键相同的表，像职工表，司理表；客户表，VIP客户表，直接同化到一个表中了
主子表相关—每个订单的总金额
主子表，被视为一个表了，拖出订单，再挑选求和办法拖出明细金额就能够了，不操心怎样相关的
按维对齐汇总—按日期计算3个不同表的汇总金额
这个虽然仍是三个表，但事务人员也不必管各个表之间有什么相相联系，找到对应的金额目标，挑选求和，然后直接拖拽就能够，再选一个“日”当做共同的计算条件，那便是按日期汇总了
并且查询控件还会主动把和已挑选数据不匹配的数据项过滤隐藏掉，有汇总的还会主动建立汇总项与计算维度之间的匹配联系，运用起来就愈加智能了，不只防止了犯错，确保了拖拽剖析的事务正确性，也使得查询剖析愈加流通了
润乾根据DQL引擎的全新一代BI，打破宽表的约束，真正做到自在灵敏剖析，让事务人员能能轻松应对各种数据JOIN场景的BI
DQL引擎会把DQL语句翻译成SQL履行，所以能够根据任何联系数据库工作。这款DQL引擎现在是免费供给的哦，前端界面部分还开源，你能够轻松把这些强大的功能集成到自己的BI使用中
总结
BI的定位是自在的剖析，它能够隐忍一时的由于技能约束而带来的不自在，但它绝不会永远这样委曲求全，技能是需求改造的，也会有人去改造，当新的技能打破瓶颈，捅破约束它的天花板今后，新一代的BI就到来了
润乾报表资料
- 润乾报表官网
- 润乾报表下载
