明确维度定义后,还可以换一种更清晰的方式来审视数据库的结构。
这是我们常见的E-R图:
E-R图是个网状结构,实体(表)之间的外键关系直接画在图上,当实体较多时这个图就会显得非常零乱,关联线很随意,任何两个实体之间都有可能发生关联,表现出来的数据结构耦合度很高。在增加删除实体时就要考虑与之关联的所有其它实体,很可能发生遗漏关联或循环关联的现象。
而如果把维度抽取出来之后,我们可以使用总线式的结构图:
所有维度单独列出来处于中心地位,实体(表)只和维度发生关联,实体之间没有直接的关联线,数据结构的耦合度看起来很低。增加删除实体时不会影响到其它实体,不会发生遗漏关联和重复关联。
不过,需要指出的是。无论是E-R图还是总线图,只要画正确时,其中的关联线数量是差不多的,这是数据本身的关系决定的。总线图并不会比E-R中的关联线更少,但改变了看待方法后会更清晰。
为了提供关联查询能力,有些BI产品将表间关联关系(相当于一个局部E-R图)直接暴露给业务人员,这不是个好办法,业务人员难以理解E-R图,这个方案的可用性很差。如果能够由业务人员选择了数据项(字段)后就自动建立出合理的关联,那样可用性就能提高很多了。
有了维度概念,就可以一定程度地实现这一目标。
业务人员任意选择了字段之后,我们可以找出这些字段所在表,再在这些表之间寻找同维字段(优先选择主键),然后使用这些同维字段建立JOIN关系。当某个表上只有唯一的字段和另一表的主键字段同维时,那么基于这两个字段建立的JOIN关系在绝大多数情况下都是正确合理的。而且,在数据结构不是特别复杂的时候,两表之间只有唯一字段同维的条件也常常能够满足,这时候就真地能只基于数据项自动建立正确的关联关系,有些BI产品确实是这么做的。
不过,这种办法不能处理同表自关联和表间有多个同维字段的情况,以及多次递归关联的问题。想要完善地解决问题,还是需要基于DQL语法来实现关联。
上面的讨论中,我们会把发现的同维字段JOIN起来,DQL语法也是这样,只要同维的(广义)字段就可以JOIN。这样的JOIN一定有业务意义吗?
是的,只要是同维字段,JOIN起来总能想出合理业务意义。反过来,也只有同维字段之间可以JOIN,不同维字段的JOIN是没有业务意义的,不过SQL并不禁止,只要数据类型相同就可以JOIN。字段同维和JOIN有业务意义是等价的,DQL在这方面可以确保这一点。
DQL中GROUP BY总是要对应着ON(如果单表可以看成是省略ON),也就是说,GROUP BY总是针对某个维度进行的。事实上也是这样,针对测度的分组运算没有业务意义,不过SQL并没有明确出维度和测度的概念,也不会禁止这个运算。DQL则确保了不会发生无业务意义的分组。
利用这个特点,可以提高分组运算的性能。维度可能的取值是由维表长度决定的,而维表是事先知道的,这样在分组时可以采用类似基数排序法的手段提速,当然,针对维度的排序运算也可以用这种办法。不过,这个算法细节与本篇主题相关性较低,这里就不详细说明了。
原文发布时间为:2018-01-11
本文作者:蒋步星