文章目錄

• 一、做不好關聯分析的原因
• 二、在數據模型層面解決關聯
• 三、給業務人員看的懂的數據結構
• • ??多級關聯表
  • ??自關聯表
  • ?互關聯表
  • ?重復關聯表
• ?結語
• ??潤乾報表資料

事物都是普遍聯系的，很難有一個獨立的事物不和其它發生關聯，數據表也一樣，很多有業務意義的查詢都會涉及多個數據表的關聯

數據分析以及 BI 類軟件通常會提供自助查詢功能，有些軟件還能支持關聯查詢，但實際使用的大多數還是單表的，也就是我們常說的寬表，而提供的自助關聯查詢功能則很少被業務人員使用，這是幾乎所有 BI 類軟件的軟肋，無論大牌小眾，一試一個準
這里有個測試報告看看：國內主流 BI 產品關聯分析能力對比

為什么明明BI軟件提供了關聯查詢，業務人員卻不用呢，因為不會用，簡單的關聯，BI能對付，復雜一些的，BI軟件表現出來的連自己的工程師都看著暈，讓用戶自己去做關聯就更不可能了，于是只能做一個寬表給用戶用

寬表的局限性其實很明顯，數據冗余，維護麻煩這些就不說了，單單是：只能基于寬表現有的關聯做分析，用戶分析需求超出范圍，或者有變化，就得技術人員修改或者重新做寬表這一條，就足夠把用戶和BI廠商都壓垮了，用戶不自由，啥也得廠商幫忙，今天想做的分析，可能得一周以后才能做；廠商更不樂意，每一次修改和重做，都是人工成本，可是自己產品提供的自助關聯又不好用，也只能任用戶擺布了

一、做不好關聯分析的原因

那么，BI軟件提供的自助關聯哪里不好用呢？答案是簡單的還勉強可以，復雜的都搞不了

簡單的每個表之間只關聯一次的情況，業務人員可能還能理解，可以用，比如

我們要查詢：北京號碼的撥打記錄

這時候只需要通話記錄表和電話賬戶表關聯一次就可以，從通話記錄表中查詢賬戶表中注冊地是北京的號碼的所有撥打記錄

但實際分析中，要查詢的情況遠比這個要復雜，有很多重復關聯、相互關聯、自關聯的，這些情況，就算是技術人員也得花挺長時間才能捋順，更別說業務人員了，我們來繼續看

重復關聯

我們要查詢：北京號碼打給上海號碼的通話記錄

這就需要把通話記錄表和電話帳戶表做兩次關聯，分別使用通話記錄表的主叫號碼和被叫號碼關聯，才能分別取出主叫號碼注冊地和被叫號碼注冊地。首先要把同一個電話帳戶表關聯兩次，這就有相當一部分軟件根本不支持了；其次，還要分別取出兩次注冊地字段，要分清楚是用主叫號碼關聯出來的還是用被叫號碼關聯出來的，這就要給電話帳戶表起不同的別名來區分（SQL 就是這么干的），這個概念又會讓非專業人員感覺很糊涂

我們這個例子實際上已經簡化了，通常電話帳戶表中并不會直接存儲北京、上海這種級別的地點，而是會用一個地點編號去和地區表關聯，從地區表中才能再取出這個地點編號對應的地點所在的省級區域（甚至可能再分幾級）。那么上述關聯過程中，這個地區表也會跟隨著被關聯兩次，也要起別名才能區分。如果地區再分級了（這其實是常有的事），被跟隨關聯兩次的表就更多，關聯表稍多時，連技術人員都要小心仔細才能搞得清，業務人員基本上就沒可能理清楚了

相互關聯

我們要查詢：女經理手下的男員工

人事系統里員工表，還有部門表。員工表中有所屬部門的字段與部門表關聯，部門會有經理，而經理也是個員工，部門表中的經理字段會再和員工表關聯。這就發生互相關聯的情況，轉圈了

要查女經理手下的男員工，自己想想 SQL 會寫成啥樣吧。員工表關聯到部門表獲取部門經理，然后再轉回來再和員工表關聯獲取經理的性別，員工表出現兩次，又要起別名，這樣才能區分出從員工表中取出來的性別字段是待查員工的還是其經理的

這樣的關聯，不僅業務人員搞不了，就連很多BI軟件本身都做不好這樣的查詢，工具都不支持，讓業務人員怎么做？

自關聯

互相關聯到極端情況，還會變成自我關聯了

比如前面說過地區可能分級，而分級的地區表很可能并不會做成多個表，而是只有一個表，用一個字段表示其上級地區（編號），這是很常見的數據結構設計，但這也意味著地區表會和自己關聯。從最低層的營業所（或基站）走到省級區域，可能會有三五級之多，這個表也就要被重復關聯三五次，起上三五個別名才分得清，你說業務人員暈不暈？

造成這些難題的根本原因是，SQL 對于 JOIN 的定義過于簡單了，用來描述復雜的關聯場景時，就會很難理解，容易犯暈，就像用加法來描述乘法一樣，而直接原因是BI廠商們也并沒有在數據模型層面針對這個難題進行優化封裝，只是簡單的把表對業務人員做了可視，把難題丟給了沒有技術能力的業務人員，結果可想而知，難題更難了

二、在數據模型層面解決關聯

仔細看過前面那個測試報告就會發現，潤乾報表的DQL引擎，可以很好的解決這個難題

由技術人員先定義好各種關聯關系的DQL元數據，這個元數據，不同于寬表

它預先定義好了各種關聯關系，但并沒有做實際關聯，當用戶在前端拖拽分析的時候，才實時生成關聯查詢，不需要像寬表一樣預先關聯，占用數據庫資源

它的關聯關系只要數據表本身結構不變，就不用修改元數據，不需要像寬表一樣總得重新生成

DQL 換個思路看待表間關聯，允許把外鍵表的字段當成字段的屬性使用，支持無限層級，這樣就很好地解決了關聯問題。頁面端也很好表達，按層展開即可，有多少層都沒關系

想更詳細了解DQL是怎么解決關聯難題的，可以參看：

自助關聯分析方案

三、給業務人員看的懂的數據結構

在后端設置好元數據，經過潤乾DQL引擎的解析，業務人員看到的就是能清晰理解的樹狀目錄數據了

??多級關聯表

逐層展開后看到多級關聯表，可以隨意選用各級字段：

??自關聯表

訂單表的發貨城市關聯到區域表，之后用父區域可以一直展開，第一次展開父區域是發貨省份，再繼續展開父區域是發貨地區：

?互關聯表

員工表里的部門字段展開到部門表，部門表中的部門經理字段又展開回到員工表，這個第三層的員工表，代表的是部門經理這種特殊員工：

?重復關聯表

訂單表里的發貨城市、收貨城市都關聯到區域表，能分別展開，自然的也就分別代表收、發貨的相關信息：

可以看出，我們前面列舉的難題，到這里都輕松化解了，業務人員再也不必去理解復雜的表間關系了，看著前臺一目了然的數據，直接拖拽分析，后端引擎就做好關聯查詢了

DQL還支持同維關聯、主子關聯、多字段關聯等更多關聯需求，還能夠自動選用匯總數據以及支持跨數據庫的多維分析

?結語

大部分的BI多維分析，可能一張寬表、一個cube就搞定了，但是占少部分的復雜關聯分析，才是更考驗一個產品是否強大的地方，用一個能解決關聯分析的BI工具，不僅可以節省自己的技術人員成本投入，更可以讓用戶使用體驗更好

還要說一句，潤乾的DQL是可以免費用的哈，參考：

潤乾開源免費 BI 商業規則

??潤乾報表資料

• 潤乾報表官網
• 潤乾報表下載

歡迎對潤乾報表有興趣的加小助手（VX號：RUNQIAN_RAQSOFT），進技術交流群

總結

以上是生活随笔為你收集整理的为什么 BI 软件都搞不定关联分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。