查询女经理的男员工？这很难吗？
是滴，就拿这么个简单问题来测试 BI 软件，无论国际大牌还是国产新秀，几乎全部歇菜，一试一个准

这个查询涉及两个表的关联，员工表和部门表

写出 SQL 是这样的：

这里，员工表被关联了两次，需要起个别名才能在 SQL 中区分出来

那么，BI 怎么做呢？
我们先看下 BI 查询的原理，就是把拖拽动作转换成 SQL 交给数据库执行

如果是单表，那直接拖拽需要的字段就可以了，但遇到多表时，就要指定关联关系，这就超出许多业务人员的理解能力了

如果两表之间只有唯一的关联，比如只是从员工表关联到部门表，那么 BI 也能自动找出来关联上
但这个例子中，两表之间关联并不唯一，部门表的经理还需要再关联员工表的编号

这时候，BI 就晕掉了，不知道该用哪个关联，更不知道还要把员工表起个别名关联两次才能解决问题了

这种多种关联的情况在企业数据系统中一点也不罕见，而且常常还会关联多层，这会导致途经的每一层表都有多种关联，还会形成圈状
比如“北京住址的用户在上海注册电话打给上海本地电话的通话时长”，各个表之间的关联关系是这样的，这可比员工的例子要复杂得多了

这些复杂的关联关系，不仅业务人员自己搞不定，BI 软件也不能自动识别搞定

那么怎么办？
还可以找技术人员做宽表，毕竟没有技术人员做不了的事情
提前把这些复杂的关联拼成一个大宽表，就又变成容易理解的单表了
所谓 BI 里的建模，数据立方体就是这么一回事

现在，大家应该都明白了，宽表要把关联信息都抄过来，表变得很宽，所以叫宽表
这显然不是个什么好主意，情况复杂时可能会抄出几百上千个字段出来，这也太累赘了

而且极不灵活，比如，我们又想看一下“总监和经理都是女性的男员工有哪些”
原先的宽表不够了，还得加上经理的上级部门以及员工表再关联，那只能再找技术人员把宽表再加宽
只要遇到没想到的关联，就得找技术人员，BI 的所谓自由灵活荡然无存。

这种基于宽表的建模也叫做按需建模，就是根据需求去建模，需求一变就得重新建模
技术人员也没办法一次性把宽表做完善，就只能一次次改，所以，用宽表来做 BI 分析，就等于绑架了技术人员！

就没有不依赖宽表让用户随便查询的 BI 技术吗？

有！

使用 DQL 可以消除掉 SQL 中的关联
比如前面说的查询女经理的男员工，在 DQL 语句被简化成了这样：

FROM 后面只有一个表了，没有关联

复杂的关联关系可以用简单明了的树状结构呈现给用户，关联路径清清楚楚，再也不会晕了

拖拽出来的就是没有关联的 DQL，然后自动翻译成 SQL 来查询

使用 DQL，只需要一次性定义好元数据，就能应对所有想到和没想到的关联，再也不用麻烦技术人员频繁修改模型了
这叫做非按需建模，建模只要考虑数据结构本身，与需求无关，一次建模，各种关联需求都可以满足

润乾 DQL 引擎现在可以完全免费使用，它配的拖拽界面还是开源的哦，快去下载试试吧