BI的資料模型就是透過關係相互連線的一組表。這組表裡面有事實表、維度表，透過關係把他們連在一起。
來源：BI實戰，作者Danarui
兩個不同表之間存在以下3種關係型別：一對一（1 : 1），一對多（1 : N），多對多（N : N）。
1:1 & 1:N很容易理解，但N:N就複雜多了，理解起來沒那麼直觀。
N:N關係的基礎理論來自於集合論。在集合論中，可以將實體看作集合，實體之間的關係可以看作集合之間的關係。N:N關係可以透過兩個集合之間的笛卡爾積來表示。
笛卡爾積：
指由兩個集合中的每個元素組成的每一對有序元素構成的集合。例如，S={1, 2}，T={a, b}，則它們的笛卡爾積為{(1,a),(1,b),(2,a),(2,b)}。這個集合中每個元素都是一個有序對，表示S和T之間的所有可能的對應關係。因此，透過兩個集合之間的笛卡爾積，可以表示兩個集合之間的多對多關係。
在資料建模中，N:N關係的建模，我們天然的認為會發生資料膨脹，導致多條重複資料出現，最終會影響統計結果。這麼認為其實沒錯，SQL中多對多的JOIN連線，確實會導致資料膨脹。為了避免這個問題，常規的做法就是使用橋表，將N:N轉化為兩個1:N後再進行join連線，這個處理方法也通用於BI的N:N關係處理。
去年，FineBI 釋出了“主題模型”功能，除了讓資料準備更簡單、多表分析更高效外，還能更加友好的支援 N:N 計算場景。可以說是大大的減少了N:N場景的計算準備工作量，但隨之而來的就是高度抽象的合併&計算邏輯，大大的增加了理解成本。
能夠深度理解主題模型計算原理的人可能會使用後發出驚呼：wow，太棒了！
不能夠理解主題模型計算原理的人，可能就會“想用卻不敢用”，因為搞不清楚用了之後哪裡會暴雷。
所以今天想拆解下FineBI的N:N計算步驟，把抽象的計算過程具體化一些，便於大家理解。
我們透過一個案例來看：
需求背景：
BYD是一家日用品倉儲超市，主要經營紙巾、洗衣液等相關產品，每年2月、6月、7月和11月是超市的固定大促月，基本可以享受全年最低價，另外，為了方便顧客，超市提供一項寄存服務，比如，7月付款買10箱紙巾（預售單），後續用到的月份再來提貨，用幾箱提貨幾箱即可，也允許一筆訂單提多個預售單的貨（提貨單），對那些家中存在空間有限的顧客來說，這是一項完美的服務。所以每到大促月，很多顧客會選擇寄存。
Tom是這家連鎖超市的運營經理，近期他在分析經營資料的時候發現，超市預售的業績越來越高，就想了解下預售提貨的資料，所以向資料部提了如下需求：
1、2023年超市每月的預售件數、提貨件數是多少，還有多少未提？
2、哪些會員還未提貨完成，分別還有多少未提件數？
這個需求聽起來很簡單，但如果深入瞭解業務過程，你就不會認為簡單了。
最大的障礙點在於：超市允許一筆訂單多次提貨，也允許一筆訂單提多個預售單的貨。
什麼意思呢？翻譯成關係就是：
一筆預售訂單多次提貨 ，即1筆預售單，對應多個提貨單（1：N），這個簡單
一筆提貨單提多個預售單的貨 即 1筆提貨單，對應多個預售單（1：N），這個簡單
但是，關鍵是但是，算未提得合在一起看，然後。。。就成了N:N。就不簡單了。
不過幸好，FineBI6.0的主題模型支援N:N，我們來看看這個需求怎麼透過主題模型實現~
01 FineBI的N:N
1、資料匯入
彈出【選擇資料】框，將Excel資料匯入。
預售單：
提貨單：
P.S.為了便於理解，資料做了簡化處理，但請注意預售單的「訂單ID」是存在重複的，提貨單表內的「關聯預售單號」也是存在重複的。
2、模型構建
模型檢視內，關係選擇N:N，連線依據選用預售表的「訂單ID」以及提貨表的「關聯預售單號」
3、指標計算
1.計算每月的未提數量，新增計算欄位，未提數量 = SUM_AGG(銷售數量)-SUM_AGG(提貨數量)
2. 然後將預售表的「訂單日期」拖入維度欄，將預售表的「銷售數量」、提貨表的「提貨數量」、上一步的計算欄位「未提數量」拖入指標欄即可。
3. ok了，如此簡單，算對了沒有？敢不敢用？
回到Part1的資料仔細看看，算一下。發現沒錯！
怎麼樣？驚喜麼？
4. 繼續算每個會員還有多少未提。
繼續驗證下資料對不對，可以放大圖片，口算下結果。
5. 到這裡，Tom的這個需求就完成了，一切都很完美。
然而，當我們想進一步知道每個會員是什麼產品沒提貨的時候，異常出現了。下圖紅框的部分，客戶實際上是沒有提貨資料的，然の，此處卻有計數。
為什麼會有計數？
答：這個模型的合併依據是預售表的「訂單ID」以及提貨表的「關聯預售單號」，而且分析維度是站在預售表的角度看的。模型在用連線欄位合併的時候，優先保證預售表的資料完整，而後開始呼叫「訂單ID」這個連線條件，如果出現一筆訂單中多個單品，資料就會出錯。比如下圖：
6. 怎麼辦呢？
答：聯合關聯，多欄位合為一個欄位來唯一標識一行記錄。就是把合併依據從預售表的「訂單ID」以及提貨表的「關聯預售單號」，調整為預售表的「訂單ID+產品ID」以及提貨表的「關聯預售單號+產品ID」，在資料處理階段新增列合併訂單ID和產品ID即可。
合併介面如下：
模型的連線關係欄位調整為合併後的欄位
計算結果：
一切又回到了完美！
02 N:N計算步驟拆解
為了方便理解，我們拆解下計算步驟，把抽象的計算過程稍微具象化一點。依每月未提件數的元件舉例：
每月的預售數量、提貨數量、未提數量結果如下：
主題模型的計算過程：
1. 識別分析欄位和關聯欄位
此例中分析欄位為預售表中的「年月」
關聯欄位為預售表的「訂單ID」、提貨表的「關聯預售單號」。
2. 計算預售表中每月的預售數量，分析維度為「年月」、「訂單ID」，聚合結果為SUM(預售數量)
3. 計算提貨表中每月的提貨數量，分析維度為「關聯預售單號」，聚合結果為SUM(提貨數量)
4. 依據預售表的「訂單ID」、提貨表的「關聯預售單號」關聯欄位合併
5. 依據「年月」進行聚合。
比如，2月有兩筆訂單，計算這兩筆訂單的合計預售件數，提貨件數。其它月份依次類推。
03 小結
FineBI的主題模型合併邏輯：
- 只有分析欄位和關聯欄位參與模型的合併計算
- 先聚合，再合併
如果類比到SQL的JOIN連線，這個計算過程就是透過兩個子查詢得到的：聚合的子查詢a JOIN 聚合的子查詢b。
相比較來說，FineBI透過主題模型實現還更便捷呢！
拿例子去練手吧，多換幾個分析欄位觀察下計算結果。會對主題模型的合併邏輯理解的更深刻。
☞☞☞點選下方鏈接免費體驗FineBI工具demo！
※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※
我是「數據分析那些事」。常年分享數據分析乾貨，不定期分享好用的職場技能工具。各位也可以關注我的Facebook，按讚我的臉書並私訊「10」，送你十週入門數據分析電子書唷！期待你與我互動起來~
文章推薦
回顧十週入門數據分析系列文：
關注數據君的臉書：
我是「數據分析那些事」。常年分享數據分析乾貨，不定期分享好用的職場技能工具。按贊我的臉書，會有豐富資料包贈送唷！
