《universe 聯(lián)接問題》由會(huì)員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在行業(yè)資料-天天文庫。

1、Universe3大陷阱環(huán)路定義：環(huán)路指經(jīng)過模式中一組表的閉合聯(lián)接，聯(lián)接形成維表之間多條路徑時(shí)將出現(xiàn)環(huán)路結(jié)果：返回太少行例：如下圖的universe中存在一個(gè)環(huán)路，環(huán)路中本應(yīng)該包含兩個(gè)上下文，需要描述的均是顧客與服務(wù)之間的關(guān)系，但是由于服務(wù)有已消費(fèi)和已預(yù)約兩種，所以兩個(gè)上下文在業(yè)務(wù)上分別表示預(yù)約顧客和服務(wù)間的關(guān)系和已消費(fèi)顧客和服務(wù)之間的關(guān)系。由于此universe未設(shè)置任何上下文，導(dǎo)致出現(xiàn)環(huán)路錯(cuò)誤。在universe中創(chuàng)建3個(gè)對(duì)象，分別為：顧客姓名，服務(wù)，預(yù)約天數(shù)。以下為在webi報(bào)表開發(fā)時(shí)，將以上3個(gè)對(duì)象均放入query中時(shí)生成的SQL

2、，由于沒有未環(huán)路指定不同上下文，整個(gè)環(huán)路被當(dāng)做一個(gè)上下文，在SQL的where子句中會(huì)出現(xiàn)環(huán)路中所有表的關(guān)聯(lián)限制。實(shí)際上我們只需要對(duì)SQL進(jìn)行其中一個(gè)上下文的限制。聯(lián)接應(yīng)用了比預(yù)期更多的限制，導(dǎo)致返回的結(jié)果是既預(yù)約了又消費(fèi)了的用戶，導(dǎo)致返回的數(shù)據(jù)不正確。解決方法：1.別名1.定義上下文別名有時(shí)候并不能解決所有環(huán)路的問題，或者有些環(huán)路問題需要定義不止一個(gè)別名來解決，如下圖：為customer表定義別名后，發(fā)現(xiàn)city表仍然造成環(huán)路。此時(shí)需要定義上下文解決環(huán)路。指定上下文后，query會(huì)自動(dòng)按相關(guān)的上下文生成SQL，此時(shí)where子句中的關(guān)聯(lián)

3、限制來自同一上下文的表之間的聯(lián)接。斷層陷阱定義：斷層陷阱是當(dāng)兩個(gè)“多對(duì)一”聯(lián)接會(huì)聚在一個(gè)表上時(shí)三個(gè)表之間的一種聯(lián)接路徑，并且沒有適當(dāng)?shù)胤指魰?huì)聚聯(lián)接路徑的上下文。需要注意的是：基于以下即將描述的原因，聯(lián)接的基數(shù)必須是“多對(duì)一”是才會(huì)產(chǎn)生斷層陷阱。結(jié)果：返回?cái)?shù)據(jù)變大例：universe中兩張事實(shí)表invoice_line和reservation_line分別描述消費(fèi)信息和預(yù)訂信息，均與service表多對(duì)一關(guān)聯(lián)。此時(shí)Universe中未指定任何上下文。為universe創(chuàng)建如下五個(gè)對(duì)象：將所有對(duì)象放入query中，此時(shí)query生成的SQL如

4、下圖：在webi報(bào)表上將下圖所示3個(gè)字段拖入報(bào)表中，顯示的數(shù)據(jù)如下：通過在數(shù)據(jù)庫端驗(yàn)證，此數(shù)據(jù)是錯(cuò)誤數(shù)據(jù)。錯(cuò)誤原因如下圖所示：之前的query的SQL截圖中where語句中內(nèi)容決定了結(jié)果會(huì)產(chǎn)生笛卡爾積。由上圖可知，為何必須是多對(duì)一關(guān)聯(lián)才會(huì)出現(xiàn)斷層陷阱問題。解決方法：指定上下文扇形陷進(jìn)當(dāng)“一對(duì)多”連接鏈接了依次由另一個(gè)“一對(duì)多”連接鏈接的表時(shí)，扇形陷阱是三個(gè)表之間的一種連接路徑。當(dāng)查詢包括同時(shí)基于兩個(gè)表的對(duì)象時(shí)，“一對(duì)多”連接的分散影響可能會(huì)導(dǎo)致返回不正確的結(jié)果。結(jié)果：返回的值變大。例：假設(shè)下圖為以上涉及的3表中的相關(guān)數(shù)據(jù)：以下圖為報(bào)表中含

5、有的字段，分兩種情況：1、query中不含SALE_MODEL中的字段model_id，此時(shí)結(jié)果是正確的：具體原因如下圖：Query中不含model_id時(shí)，在query返回的結(jié)果集中，sale_QTY會(huì)根據(jù)sale_id自動(dòng)匯總，匯總數(shù)據(jù)是正確的。2、query中含SALE_MODEL中的字段model_id，此時(shí)結(jié)果是不正確的：具體原因如下圖：此時(shí)返回的結(jié)果集如上圖所示，由于model_id各不相同，SALE表中的數(shù)據(jù)復(fù)制后與SALE_MODEL表數(shù)據(jù)關(guān)聯(lián)，圖中紅線框內(nèi)即為復(fù)制后重復(fù)的數(shù)據(jù)，所以導(dǎo)致salevalue的數(shù)據(jù)匯總后是錯(cuò)誤

6、的。解決方法：定義別名并指定上下文合并維：結(jié)論：一個(gè)包含在合并維中的維度A，和同它不在同一query的度量處于同一報(bào)表塊時(shí)，如果合并維中存在與此度量處于同一query的維度B，維度A會(huì)自動(dòng)與此度量產(chǎn)生關(guān)聯(lián)，效果等同于與此度量屬于同一query。Query1：Query2：場景一：不合并維結(jié)果：1、維度：[Query1].[Lines],[newmeasure]2、維度：[Query2].[Lines],[newmeasure]場景二：合并維結(jié)果：1、維度：[Query1].[Lines],[newmeasure]2、維度：[Query2]

7、.[Lines],[newmeasure]