BIRT異構跨庫的動態(tài)關聯(lián)查詢該怎樣做

這篇文章主要為大家分析了BIRT異構跨庫的動態(tài)關聯(lián)查詢該怎樣做的相關知識點，內容詳細易懂，操作細節(jié)合理，具有一定參考價值。如果感興趣的話，不妨跟著跟隨小編一起來看看，下面跟著小編一起深入學習“BIRT異構跨庫的動態(tài)關聯(lián)查詢該怎樣做”的知識吧。

BIRT自帶的Data Sources Join以及用ETL轉化為同庫等方案都難以解決此類問題。具體可以通過如下示例討論：

交易明細數(shù)據(jù)(trade表)存儲于生產系統(tǒng)的數(shù)據(jù)庫DB2中，另外一部分業(yè)務數(shù)據(jù)(network表、account表)存儲于業(yè)務系統(tǒng)的Mysql中，它們其中的關聯(lián)關系如下圖所示：

所謂“動態(tài)關聯(lián)”，是指用戶在前臺界面輸入?yún)?shù)，報表通過參數(shù)來決定trade和哪張表做關聯(lián)，并在報表中顯示關聯(lián)后的數(shù)據(jù)，實際運算中可能還要進行數(shù)據(jù)過濾和匯總。查詢流程如下圖所示：

比如查詢場景一：報表根據(jù)傳入?yún)?shù)，能動態(tài)地將trade中的outAccount字段和account中的accountNo字段關聯(lián)，最后查詢結果顯示trade中的所有字段以及account的name,gender,city等字段。

解決此類問題的常見方案與不足，分析如下：

1、BIRT Data Sources Join的問題在于要求表名和字段名是已知、確定的，但這類報表都是通過參數(shù)來動態(tài)關聯(lián)的，因此無法實現(xiàn)。

2、可以用ETL把生產庫的數(shù)據(jù)抽取到業(yè)務庫，這樣跨庫的問題就轉化為同庫了。這個方案思路簡單但實施起來細節(jié)上有很多難點。首先是實時查詢：為了實時查詢數(shù)據(jù)，需要在生產庫使用觸發(fā)器之類的功能來檢測數(shù)據(jù)的實時變化，并將數(shù)據(jù)推送到業(yè)務庫，但生產庫不能輕易改動，因此實時查詢就無法實現(xiàn)。非實時查詢也難以辦到，這是因為生產庫的數(shù)據(jù)極其龐大，不可能每次都全部取過來，只有用增量抽取的辦法，而判斷增量就需要在trade表中加入時間戳字段。同樣，生產庫是不允許有這種改動的，因此也無法實現(xiàn)。

3、從能力上講，BIRT JAVA bean data source是真正能解決報表問題，它比Data Sources Join更具靈活性，也不需要修改生產庫。但這個方案只有一個缺陷：代碼過于復雜，原因在于數(shù)據(jù)計算并非JAVA特長，若每次遇到跨庫問題都用硬編碼方式來實現(xiàn)，并不現(xiàn)實。

建議使用集算器，它是獨立的數(shù)據(jù)計算引擎，擁有不依賴于數(shù)據(jù)庫的計算能力，支持異構數(shù)據(jù)源的混合運算，比較適合進行動態(tài)關聯(lián)再計算，事實上，可以把集算器看作是語法更簡單的BIRT JAVA bean data source。比如實現(xiàn)上面的問題，集算器腳本只需6行：

其中 tradeJoinField，crossJoinField，crossOtherFields，crossTable 為輸入?yún)?shù)。最后將計算結果返回給BIRT的DataSet進行報表展現(xiàn)。從此示例來看，集算器的參數(shù)用法很靈活，非常適合這類動態(tài)關聯(lián)查詢。由于它是專門的計算語言，所以較于常規(guī)辦法，跨庫計算的代碼更加精煉易懂。

關于“BIRT異構跨庫的動態(tài)關聯(lián)查詢該怎樣做”就介紹到這了,更多相關內容可以搜索億速云以前的文章，希望能夠幫助大家答疑解惑，請多多支持億速云網站！