粒度(granularity)指的是資料的最小單位的間隔大小
舉例來說, 我們在定義KPI的時候, 通常會以"月"來定義
此時的粒度就是到了月的層級,
而實際每日的營運狀況績效當然會以日為單位進行記錄,
其時間的粒度大小就到了日,
而在QlikView將表格載入後就會變成像下圖這個樣子:
為了避免循環參考的情況發生,
QlikView自動將FACT_KPI變成了鬆散表格(loosely coupled tables)了
而肇因起於粒度大小不一致所導致而成, 解決方法有幾種
LinkTable,
Concatenate,
aggr to Dimension table,
拆分成不同檔案再用link doc
通常最簡單的解決方式是將KPI拆分到日的層級合併到銷售表去
但是會造成拆分後的KPI值加總之後不等於原先的KPI值
更麻煩的是如果銷售表含有其他維度, 如產品別
選擇產品分類後, 除非做SET ANALYSIS, 否則無法取得KPI的資訊,
而且每次計算月分KPI時必須從頭加總一次
另外一個方法是將KPI併到業務的表格去
但是KPI並不會只有一個月的資訊, 因此我們要將業務表格改為"業務員編號X業務年月"
意即 業務員與年月的排列組合
這樣做的衍伸問題就是業務表的資料會膨脹,
假使有三年的KPI, 最多就會膨脹到36倍
而且在算業務員人數時就得用到distinct, 效能會差很多
另一個做法是結合Link table的概念
此時不管事點任何產品別, 都能帶出相關業務員的KPI
資料量也不會膨脹, 計算相關業務員人數也可以正確進行運作
然而唯一的缺頂是schema變成了雪花狀,
如果效能下降的幅度可接受的話, 用這個方法就好
否則就得拆成月總結與每日營運這兩個檔案來進行設計了
150507補充:
假設此時 FACT TABLE 裡只有幾個月份的資料
但要計算出 目前累計月份對整年KPI 的比較時
若是點選 "年" 時,
透過 FACT TABLE 關聯到 業務員編號X業務員 欄位
只會帶出有交易紀錄的月KPI,
而尚未有交易紀錄的KPI會帶不出來
解決這個問題的方法就是在FACT TABLE中
加入可以建立關聯的空資料即可
留言列表