难倒所有 BI 的“女经理的男员工”问题
查询女经理的男员工这很难吗是滴就拿这么个简单问题来测试 BI 软件无论国际大牌还是国产新秀几乎全部歇菜一试一个准这个查询涉及两个表的关联员工表和部门表写出 SQL 是这样的这里员工表被关联了两次需要起个别名才能在 SQL 中区分出来那么BI 怎么做呢我们先看下 BI 查询的原理就是把拖拽动作转换成 SQL 交给数据库执行如果是单表那直接拖拽需要的字段就可以了但遇到多表时就要指定关联关系这就超出许多业务人员的理解能力了如果两表之间只有唯一的关联比如只是从员工表关联到部门表那么 BI 也能自动找出来关联上但这个例子中两表之间关联并不唯一部门表的经理还需要再关联员工表的编号这时候BI 就晕掉了不知道该用哪个关联更不知道还要把员工表起个别名关联两次才能解决问题了这种多种关联的情况在企业数据系统中一点也不罕见而且常常还会关联多层这会导致途经的每一层表都有多种关联还会形成圈状比如“北京住址的用户在上海注册电话打给上海本地电话的通话时长”各个表之间的关联关系是这样的这可比员工的例子要复杂得多了这些复杂的关联关系不仅业务人员自己搞不定BI 软件也不能自动识别搞定那么怎么办还可以找技术人员做宽表毕竟没有技术人员做不了的事情提前把这些复杂的关联拼成一个大宽表就又变成容易理解的单表了所谓 BI 里的建模数据立方体就是这么一回事现在大家应该都明白了宽表要把关联信息都抄过来表变得很宽所以叫宽表这显然不是个什么好主意情况复杂时可能会抄出几百上千个字段出来这也太累赘了而且极不灵活比如我们又想看一下“总监和经理都是女性的男员工有哪些”原先的宽表不够了还得加上经理的上级部门以及员工表再关联那只能再找技术人员把宽表再加宽只要遇到没想到的关联就得找技术人员BI 的所谓自由灵活荡然无存。这种基于宽表的建模也叫做按需建模就是根据需求去建模需求一变就得重新建模技术人员也没办法一次性把宽表做完善就只能一次次改所以用宽表来做 BI 分析就等于绑架了技术人员就没有不依赖宽表让用户随便查询的 BI 技术吗有使用 DQL 可以消除掉 SQL 中的关联比如前面说的查询女经理的男员工在 DQL 语句被简化成了这样FROM 后面只有一个表了没有关联复杂的关联关系可以用简单明了的树状结构呈现给用户关联路径清清楚楚再也不会晕了拖拽出来的就是没有关联的 DQL然后自动翻译成 SQL 来查询使用 DQL只需要一次性定义好元数据就能应对所有想到和没想到的关联再也不用麻烦技术人员频繁修改模型了这叫做非按需建模建模只要考虑数据结构本身与需求无关一次建模各种关联需求都可以满足润乾 DQL 引擎现在可以完全免费使用它配的拖拽界面还是开源的哦快去下载试试吧
