歡迎關(guān)注天善智能微信公眾號，我們是專注于商業(yè)智能BI，大數(shù)據(jù)，數(shù)據(jù)分析領(lǐng)域的垂直社區(qū)。 對商業(yè)智能BI、大數(shù)據(jù)分析挖掘、機(jī)器學(xué)習(xí)，python，R等數(shù)據(jù)領(lǐng)域感興趣的同學(xué)加微信：tstoutiao，邀請你進(jìn)入頭條數(shù)據(jù)愛好者交流群，數(shù)據(jù)愛好者們都在這兒。

　　一般來說，是不需要環(huán)狀模型的，環(huán)狀模型通常都可以通過別名等方式轉(zhuǎn)換成非環(huán)狀的(BIEE 10g在邏輯層是不允許建立環(huán)狀模型的(物理層可以)，而11g 則沒有了這個限制)

　　但是某種情況下，還真需要環(huán)狀模型。

　　考慮如下簡單模型

　　可以看到，上圖中的產(chǎn)品維采用了Type2 的緩慢變化維；因此其含有開始時(shí)間和結(jié)束時(shí)間字段為于標(biāo)識對應(yīng)記錄的有效時(shí)間段。

　　考慮如下需求，一個儀表盤提示有兩個字段，分別是“CALENDAR_YEAR”(Dim_Date)、“PROD_DESC”(Dim_Products)；客戶要求當(dāng)我選定了“年”之后，“產(chǎn)品描述”里

　　只能出現(xiàn)對應(yīng)年的“產(chǎn)品描述”，拿同一個產(chǎn)品為例，比如：

　　年 產(chǎn)品編碼 產(chǎn)品描述

　　1998 TP_123 產(chǎn)品A_OLD

　　1999 TP_123 產(chǎn)品A_NEW

　　當(dāng)我選了1999年之后只能出現(xiàn)產(chǎn)品A_NEW，而不要出現(xiàn)產(chǎn)品A_OLD

　　新手拿到這個問題都會覺得很“簡單”，只要PROD_DESC的值受CALENDAR_YEAR限制即可，如下圖所示：

　　OK，大功告成！測試測試，

　　選擇好CALENDAR_YEAR，然后在選擇PROD_DESC。

　　1分鐘、2分鐘.....

　　10分鐘過去了怎么PROD_DESC還出不來！

　　這是很多新手經(jīng)常會遇到的一個問題，為什么會這樣？

　　很簡單，因?yàn)樵诰S度模型中，維表與維表的關(guān)聯(lián)關(guān)系都存在于事實(shí)表之中，想要用一個維度的值去限定另一個維度的值必然要連接事實(shí)表，

　　所以在提示中用一個維度去限制另一個維度肯定會有性能問題(當(dāng)然了，事實(shí)表數(shù)據(jù)量小性能會在可接受范圍內(nèi))

　　那么我們應(yīng)該怎么來處理這種問題呢？

　　實(shí)際上這種問題從根本上是因?yàn)楫a(chǎn)品維和時(shí)間維并非毫無關(guān)聯(lián)，而是存在著一定的聯(lián)系(因?yàn)槟硹l產(chǎn)品記錄只在某個時(shí)間段內(nèi)有效)

　　這個時(shí)候我們可以引入一個支架時(shí)間維，將它與產(chǎn)品維連接起來，如下圖所示：

　　其中Dim_Date_Products_LifeCycle和Dim_Date都是真實(shí)物理表TIMES的別名(使用別名，是我們在BIEE中實(shí)現(xiàn)角色扮演維的常用手段)

　　這樣的話，我們能可以很方便的使用Dim_Date_Products_LifeCycle來對Dim_Products進(jìn)行篩選了(前端只需要使用等于Dim_Date_Products_LifeCycle上的某個時(shí)間點(diǎn)，而不用去寫復(fù)雜的>=開始時(shí)間 and <結(jié)束時(shí)間這樣的邏輯了)

　　接下來又有一個問題，我們是把這個支架維放在邏輯層的產(chǎn)品維度里呢，還是放在時(shí)間維度里呢？

　　如果放在產(chǎn)品維度里把其當(dāng)成產(chǎn)品上的一個屬性是說得過去的，但是這樣的話又回到我們在做提示的時(shí)候還是會遇到前面所說的問題。

　　我們需要的是把這個支架時(shí)間維和真正的時(shí)間維合２為一，也就是說，當(dāng)我們指定了時(shí)間(通過時(shí)間維的字段)，這個值需要自動傳遞到支架維上

　　然后支架維去關(guān)聯(lián)產(chǎn)品維以取出對應(yīng)時(shí)間段的產(chǎn)品描述(而無須關(guān)聯(lián)事實(shí)表)

　　How can we do?

　　一步一步的來吧，合２為一我們肯定就會想到利用邏輯層的多LTS(Logic Table Source)，如下圖所示：

　　注意：不要修改Dim_Date中，兩個LBS的“優(yōu)先級組”，讓它們都默認(rèn)為0

　　我們希望的是，如果我在answer里只選擇時(shí)間和產(chǎn)品兩個字段，那么BI Server就選擇Dim_Date的Dim_Date_Products_LifeCycle去關(guān)聯(lián)Dim_Products表(它們有直接關(guān)聯(lián))而不要選擇

　　Dim_Date(因?yàn)橐坏┻x擇了它，則必然會關(guān)聯(lián)事實(shí)表，因?yàn)镈im_Date和Dim_Products是沒有直接關(guān)聯(lián)的)

　　而當(dāng)我們同時(shí)指定了時(shí)間、產(chǎn)品以及指標(biāo)的時(shí)候，我們希望的是BI Server選擇Dim_date和Dim_Products與事實(shí)表關(guān)聯(lián)

　　通過測試，目前這樣并不能達(dá)到我們的要求，BI Server始終都要去關(guān)聯(lián)事實(shí)表，為什么？

　　大家仔細(xì)看目前的邏輯模型圖，只看邏輯模型的話，BI Server所得知的Dim_Products和Dim_Date之間是沒有直接關(guān)聯(lián)路徑的(雖然它們的LBS在物理層有)，

　　我們需要把這種關(guān)聯(lián)關(guān)系告訴給BI Server，也就是如下圖所示：

　　注：如果沒記錯，邏輯環(huán)狀模型在BIEE 10g中是不支持的

　　這要就行成了一個環(huán)狀的模型！當(dāng)我們只選擇Dim_Date和Dim_Products的時(shí)候，BI Server就會走路徑1；

　　當(dāng)選擇Dim_Date、Dim_Products、Fact_Sales的時(shí)候，BI Server就會走路徑2

　　OK，下面讓我們看一下測試結(jié)果吧！

　　新建如下圖的提示：

　　其中PROD_DESC的取值受CALENDAR_YEAR限制，當(dāng)我們選定好年之后，我們就只能在PROD_DESC中選擇對應(yīng)年的成員值了，SQL如下：

　　select distinctT195345.PROD_DESC asc1

　　from

　　TIMES T195762 /* Dim_Date_Products_LifeCycle */,

　　PRODUCTS T195345 /* Dim_Products */

　　where( T195762.CALENDAR_YEAR = 1999andT195762.TIME_ID < T195345.PROD_EFF_TO andT195762.TIME_ID >= T195345.PROD_EFF_FROM )

　　orderbyc1

　　如我們所愿，沒有關(guān)聯(lián)事實(shí)表

　　下面我們在看看兩都同時(shí)指定，并有指標(biāo)的情況下，會按我們所希望的那樣嗎

　　WITH

　　SAWITH0 AS ( select sum(T195337.AMOUNT_SOLD) asc1,

　　T195298.CALENDAR_YEAR asc2,

　　T195345.PROD_DESC asc3

　　from

　　TIMES T195298 /* Dim_Date */,

　　PRODUCTS T195345 /* Dim_Products */,

　　SALES T195337 /* Fact_Sales */

　　where( T195298.CALENDAR_YEAR = 1999andT195298.TIME_ID = T195337.TIME_ID andT195337.PROD_ID = T195345.PROD_ID andT195345.PROD_DESC = '3DVD-R Discs, 4.7GB, Pack of 5')

　　groupbyT195298.CALENDAR_YEAR, T195345.PROD_DESC)

　　select distinct0asc1,

　　D1.c2 asc2,

　　D1.c3 asc3,

　　D1.c1 asc4

　　from

　　SAWITH0 D1

　　orderbyc2, c3

　　可以看到，此時(shí)走的是路徑２，也就是我們所希望的那樣。

　　完！

　　轉(zhuǎn)載請保留以下內(nèi)容：

　　本文來源自天善社區(qū)風(fēng)在身后老師的博客（公眾號）。

　　原文鏈接： https://ask.hellobi.com/blog/lele5000/658