sapbi系統(tǒng)取數(shù)的簡單介紹

sap bi是什么

SAP BI 是SAP的智能商務(wù)(Business Intelligence)部分。2007年10月，SAP以68億美元收購Business Object(BO)后，其BI部分較前有了很大的進(jìn)步。

在仙游等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供網(wǎng)站制作、成都網(wǎng)站建設(shè) 網(wǎng)站設(shè)計制作定制網(wǎng)站開發(fā),公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站建設(shè),成都營銷網(wǎng)站建設(shè),成都外貿(mào)網(wǎng)站制作,仙游網(wǎng)站建設(shè)費用合理。

BI的主要功能是對積累的業(yè)務(wù)數(shù)據(jù)的分析挖掘。

BI包含以下一些編輯器和平臺工具：

水晶報表-Crystal Report

水晶易表-Crystal Xcelsius

報表服務(wù)器-Web Intelligence

等。

BI的高級應(yīng)用，會涉及到數(shù)據(jù)建模(DM-Data Modeling)和數(shù)據(jù)倉庫(BW Business Information Warehouse)，這兩方面網(wǎng)上有很多開放的資料。

淺談如何利用第三方軟件將SAP財務(wù)數(shù)據(jù)導(dǎo)入

隨著SAP軟件在企業(yè)的應(yīng)用比重不斷擴大，如何將SAP后臺Oracle數(shù)據(jù)庫中的數(shù)據(jù)信息導(dǎo)入到AO軟件中供審計人員進(jìn)行分析篩選是我們經(jīng)常需要面對的問題。由于目前AO軟件提供的數(shù)據(jù)導(dǎo)入模板無法覆蓋到全部財務(wù)軟件，使得在現(xiàn)場審計時經(jīng)常遇到無法導(dǎo)入數(shù)據(jù)或?qū)霐?shù)據(jù)需要做大量數(shù)據(jù)轉(zhuǎn)換整理的情況，這嚴(yán)重影響了審計人員查處違法違紀(jì)問題及案件線索的效率。如何解決數(shù)據(jù)導(dǎo)入問題就顯得尤其重要。

在某公司審計中，筆者所在的審計組在向AO軟件導(dǎo)入企業(yè)財務(wù)數(shù)據(jù)備份文件時，由于內(nèi)置財務(wù)數(shù)據(jù)模板與SAP系統(tǒng)備份不匹配，導(dǎo)致無法將該公司的財務(wù)數(shù)據(jù)導(dǎo)入AO軟件供審計人員分析篩選。

經(jīng)過分析研究，審計人員先將SAP系統(tǒng)備份導(dǎo)入到鼎信諾審計軟件中進(jìn)行財務(wù)數(shù)據(jù)整理，然后再將整理后的財務(wù)數(shù)據(jù)導(dǎo)出到excel表格中，最后將所得的excel文件導(dǎo)入AO軟件完成財務(wù)數(shù)據(jù)重建。具體過程如下：

第一步：提取財務(wù)數(shù)據(jù)備份文件。利用鼎信諾前端取數(shù)工具dataget.exe，進(jìn)入取數(shù)界面之后，點擊確認(rèn)進(jìn)入SAP系統(tǒng)取數(shù)工具界面（如圖1所示）。以SAP客戶端的方式登錄，并連接SAP服務(wù)器，選擇所需的賬套以及相應(yīng)的會計年度，按照提示操作，將取得的財務(wù)數(shù)據(jù)保存到指定目錄下，例如：C：\Documents?and?Settings\gwzhangjing\桌面\SAP（如圖2所示）。

圖1為鼎信諾前端取數(shù)工具界面。

圖2為SAP系統(tǒng)取數(shù)工具界面。

第二步：將取得的財務(wù)數(shù)據(jù)導(dǎo)入鼎信諾審計軟件。先創(chuàng)建對應(yīng)的項目，并且登錄該項目。然后，點擊主界面右側(cè)區(qū)域準(zhǔn)備階段中的“前端數(shù)據(jù)導(dǎo)入”，選擇保存到指定目錄中對應(yīng)的財務(wù)數(shù)據(jù)備份文件，將數(shù)據(jù)導(dǎo)入到建好的項目中，完成賬表重建（如圖3所示）。

圖3為前端數(shù)據(jù)導(dǎo)入界面。

第三步：導(dǎo)出excel數(shù)據(jù)表。對導(dǎo)入到鼎信諾審計軟件中的數(shù)據(jù)進(jìn)行整理，使審計人員能夠?qū)λ钄?shù)據(jù)進(jìn)行初步篩選，將有價值的財務(wù)數(shù)據(jù)導(dǎo)出生成excel表（如圖4所示）。

圖4為將數(shù)據(jù)導(dǎo)出生成excel表。

第四步：編制生成財務(wù)數(shù)據(jù)采集標(biāo)準(zhǔn)表。將從鼎信諾審計軟件中導(dǎo)出的excel表，按照AO軟件自帶模板的格式進(jìn)行轉(zhuǎn)換，調(diào)整對應(yīng)的科目名稱生成科目表、科目余額表、記賬憑證表、輔助余額表、輔助余額期初表等標(biāo)準(zhǔn)表，以便將其導(dǎo)入AO時順利完成賬表重建（如圖5所示）。

圖5為財務(wù)數(shù)據(jù)采集標(biāo)準(zhǔn)表。

第五步：將生成的數(shù)據(jù)采集標(biāo)準(zhǔn)表導(dǎo)入AO軟件。在得到財務(wù)數(shù)據(jù)標(biāo)準(zhǔn)表后，依照AO軟件的數(shù)據(jù)采集向?qū)В鸩酵瓿韶攧?wù)信息的重建，從而滿足了審計人員對財務(wù)數(shù)據(jù)分析篩選的要求（如圖6所示）。

圖6為將標(biāo)準(zhǔn)表導(dǎo)入AO軟件。

審計人員利用上述方法，對導(dǎo)入的財務(wù)數(shù)據(jù)進(jìn)行分析，發(fā)現(xiàn)該公司向其下屬公司違規(guī)出借資金問題，提高了審計效率，擴大了審計成果。

sap系統(tǒng)中，如何從系統(tǒng)界面上獲取某數(shù)值，來用為我編寫的程序代碼所用，請大家指教。

你說的這個問題有點難。根據(jù)你的描述，可以推知你的BADI的接口沒有相應(yīng)的你要取得地這些屏幕內(nèi)容。

屏幕上的這些內(nèi)容是用戶在運行VL02N的時候手動輸入的么？還是這些內(nèi)容是系統(tǒng)根據(jù)某些條件自動顯示出來的。如果是后者，那么你可以找到這些條件，根據(jù)相同的條件在你的BADI里通過Select或者FM取得這些數(shù)據(jù)。

BI 不是可以拖拉拽取數(shù)嗎？為什么還要 SQL 取數(shù) ? | 專家視角

36氪企服點評專家團——呂品

————正文————

BI 工具不是可以直接拖拉拽取數(shù)嗎 ？為什么還要寫 SQL 取數(shù) ? 這是很多初次接觸商業(yè)智能 BI 的朋友會提到的一個問題，因為在他們接觸到一些 BI 市場或者產(chǎn)品宣傳的時候，很多人就是這么來介紹BI 的。

簡單來說，這個問題背后的邏輯等同于： 拿著碗和筷子不是可以直接吃飯嗎 ？為什么還要自己動手做飯 ？有沒有想過，即使是直接吃飯，飯總是要有人來做的吧，無論這個人是自己還是別人，“做飯”這個過程并不會少。

所以，從這個問題背后能看出來還是有很多人對于 BI 的理解還是存在一定的誤區(qū)，我們可以從以下這幾個角度來分析講解一下。

可視化 BI

很多人對于 BI 的印象就停留在數(shù)據(jù)的可視化圖表，但可視化圖表只是 BI 的最終呈現(xiàn)，可視化的拖拉拽并不是 BI 的全部。

一個完整的商業(yè)智能 BI 解決的應(yīng)該是端到端（ End to End ) 的問題，需要從各個業(yè)務(wù)系統(tǒng)的數(shù)據(jù)源取數(shù)，通過 ETL （ Extract 抽取、Transformation 轉(zhuǎn)換、Loading 加載 ）的過程 將要分析的數(shù)據(jù)從規(guī)范的不可分析的、或不規(guī)范不可分析的數(shù)據(jù)最終變?yōu)橐?guī)范的、可分析的形式 ，最終通過 BI 可視化拖拉拽的方式將數(shù)據(jù)進(jìn)行有效的、帶有邏輯性的組織形成可視化分析報表。

派可數(shù)據(jù)大屏可視化分析

而大部分的 BI 工具如果重在強調(diào)前端可視化的能力，這類 BI 工具的定位就是解決數(shù)據(jù)可視化分析展現(xiàn)的問題，屬于 BI 前端可視化報表工具，但并不能代表 BI 的全部。

如何形象的理解 BI

如果把 BI 可視化實現(xiàn)的過程比作到餐廳出菜的過程，那就是：

數(shù)據(jù)源環(huán)節(jié) vs 菜市場

從各個業(yè)務(wù)系統(tǒng)取數(shù) —— 按照餐廳營業(yè)需求準(zhǔn)備所需菜品的原材料，就需要到各個市場買菜。不同的業(yè)務(wù)系統(tǒng)對應(yīng)不同的菜市場，不同的菜市場有不同的攤位對應(yīng)的就是業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫中不同的數(shù)據(jù)表。攤位上的菜就可以理解為數(shù)據(jù)表中的數(shù)據(jù)，要分析什么就取什么樣的基礎(chǔ)數(shù)據(jù)。

數(shù)據(jù)倉庫 vs 后廚倉庫

數(shù)據(jù)倉庫環(huán)節(jié) —— 從各個市場買回來的菜堆在哪里呢？后廚倉庫。有的菜是今天要用的，有的菜是明天要用的，所以先買回來堆起來。從各個系統(tǒng)抽取上來的數(shù)據(jù)也是如此，這些數(shù)據(jù)有的來源于 Oracle 系統(tǒng)，有的來源于 MySQL 或者 SQL Server，按照分析需求從不同的數(shù)據(jù)庫抽取之后放到自己的數(shù)據(jù)倉庫中集中管理起來。

ETL 過程 —— 廚師做個豬肉燉粉條不可能把整扇豬肉、一顆一顆的大白菜扔到鍋里，一定是豬肉切片，大白菜去除壞掉的葉子，菜該切切，肉該剁剁剁。同時，還會備好一些輔助的佐料等原材料，最后把所有的原材料放到操作臺上，這個就是備菜（ 擇菜、洗菜、切菜 ）的過程。

數(shù)據(jù)也是如此，把數(shù)據(jù)從各個業(yè)務(wù)系統(tǒng)先 抽取（ Extract ） 上來，等同于把放在不同倉庫格子的菜拿過來。數(shù)據(jù)要做 轉(zhuǎn)換（ Transformation ） ，比如一些臟數(shù)據(jù)的處理、格式的轉(zhuǎn)換、數(shù)據(jù)計算口徑的統(tǒng)一、指標(biāo)的計算等等，就如同洗菜、擇菜、切菜的過程。最后將處理之后的數(shù)據(jù)按照一定的模型或者格式 加載（ Loading ） 到指定的可被前端調(diào)用的數(shù)據(jù)表中，就如同把所有備好的菜放到一起準(zhǔn)備下鍋。

報表可視化 Reporting vs 上菜

Reporting 報表可視化就是最后的呈現(xiàn)，也通常視為 BI 的前端，所以也叫做 BI 前端可視化。用戶需要什么樣的可視化報表，就如同用戶點菜一樣可以高度定制化，前提是基于已有的原材料（數(shù)據(jù)）。

派可數(shù)據(jù)大屏可視化分析

所以，大家可以看到從業(yè)務(wù)系統(tǒng)數(shù)據(jù)取數(shù)到最后的報表呈現(xiàn)實際上經(jīng)歷了很多的階段。 在商業(yè)智能 BI 開發(fā)過程中，80% 的時間在處理底層數(shù)據(jù)（ 跑菜市場、買菜、運菜、擇菜、洗菜、切菜到備好菜 ），20% 的時間在做可視化分析報表（ 做菜 ）。 底層數(shù)據(jù)的處理重點就是 ETL 過程，而實現(xiàn) ETL 過程的主要方式就是通過 ETL 工具（ 例如：Kettle、Informatica、Pentaho、IBM DataStage、Microsoft SSIS 等 ）或其它 ETL 框架結(jié)合 SQL 查詢語句、Stored Procedure 存儲過程等方式來組織和管理數(shù)據(jù)處理的先后順序。

特別是企業(yè)級 BI 項目建設(shè)，不僅僅是簡單的 ETL 過程還需要涉及非常專業(yè)的數(shù)據(jù)架構(gòu)設(shè)計、數(shù)據(jù)倉庫建模、分層設(shè)計等數(shù)據(jù)倉庫的構(gòu)建，這里面最常用的開發(fā)語言就是 SQL。

BI 直接取數(shù)分析并不可行

很多 BI 工具會經(jīng)常強調(diào)直連取數(shù)，這樣就不需要寫 SQL，直接通過表與表之間的關(guān)系進(jìn)行表間建模，形成一個大寬表，文本類型的就是維度 Dimension，數(shù)值類型的變成度量 Measure，通過 BI 前端可視化進(jìn)行拖拉拽操作形成很多 Ad-hoc Report 即席報表。

在實際演示案例的時候也是如此，最常見的就是一個標(biāo)準(zhǔn)的、數(shù)據(jù)格式極為標(biāo)準(zhǔn)規(guī)范的 EXCEL 表上傳一下按照上面的方式來一遍；要么就是銷售訂單表和銷售明細(xì)表關(guān)聯(lián)一下，算算訂單數(shù)量、訂單金額等等。

其實驗證一下 BI 工具的這種直連且拖拉拽的能力到底有多強非常簡單，讓業(yè)務(wù)部門提幾個實際的分析需求，現(xiàn)場拿 BI 產(chǎn)品從實際的業(yè)務(wù)系統(tǒng)中取數(shù)來驗證一下是否那么容易就明白了。

以下面一個小 DEMO 為例，可以使用任意的國內(nèi)外 BI 可視化分析工具嘗試一下當(dāng)直連到這張表的時候，是不是就可以直接、任意的進(jìn)行拖拉拽分析。

案例：統(tǒng)計外包業(yè)務(wù)的人工效率（時長）

背景：某金融公司把一部分貸款業(yè)務(wù)外包出去給第三方公司，第三方公司業(yè)務(wù)人員每與客戶聯(lián)系一次，就會根據(jù)溝通的狀態(tài)記錄一下，形成了以下的業(yè)務(wù)數(shù)據(jù)表 DurationTime，有以下三個核心字段：

ID - 客戶的身份證號，唯一標(biāo)識 ID

Operation - 一個操作記錄，重點節(jié)點有 0034、0036、0048

Date - 一個操作記錄的時間日期（實際上是時間，為了簡化用日期表示）

業(yè)務(wù)系統(tǒng)中的原始數(shù)據(jù)表

計算規(guī)則如下：

1) 計算0034-0036，0036-0048，0034-0048的時間間隔。

2) 如0036之前沒有0034，不可單獨計算0036-0048的時間間隔。

3) 如0036后跟著多個0048，則取到最晚的一個0048的時間間隔。

4) 如0034后跟著多個0048，則取到最早的一個0048的時間間隔。

5) ....

實際的計算規(guī)則多達(dá) 20 多種，就以上面 4 條計算規(guī)則為例，最后的計算結(jié)果是：

Transformation 表

為了得到上面的最終結(jié)果，通常往往會創(chuàng)建一些中間轉(zhuǎn)換表，用來記錄轉(zhuǎn)換的過程，便于檢查和糾正邏輯，這種表我們通常叫做 Transformation 表。

業(yè)務(wù)系統(tǒng)中的原始數(shù)據(jù)表的數(shù)據(jù)規(guī)范嗎 ？非常規(guī)范。但是適合分析嗎 ？并不適合。所以在 BI 分析之前要做什么？ 那就是寫 SQL、ETL 取數(shù)，把這種在業(yè)務(wù)系統(tǒng)中規(guī)范的不可分析的、或不規(guī)范的不可分析的變成規(guī)范的、可分析的數(shù)據(jù)格式 —— 結(jié)果表。

在實際的 BI 項目開發(fā)過程中，來自各個業(yè)務(wù)系統(tǒng)數(shù)據(jù)源的數(shù)據(jù)大部分情況下就是一種不可直接分析的狀態(tài)，與分析思維不同，他們是描述業(yè)務(wù)過程的。

還會有一種說法是：可以直連業(yè)務(wù)數(shù)據(jù)源，通過寫 SQL 查詢一個數(shù)據(jù)集再通過前端 BI 可視化分析工具來呈現(xiàn)做可視化分析報表行不行？ 我們的建議是，除了以下幾種情況，不要這樣做：

第一，這類可視化分析報表基本上就是一次性的，一年可能就改不了幾回。

第二，本身數(shù)據(jù)量不大，使用頻率也不會非常的高。

原因在于： 沒有合理的建模、指標(biāo)計算復(fù)用性太差、影響業(yè)務(wù)系統(tǒng)性能、無法應(yīng)對后續(xù)日益增長和不斷變化的業(yè)務(wù)分析需求，按照這種方式做的 BI 基本上不會超過兩年就會面臨推翻重做的風(fēng)險。

所以，在使用 BI 的時候，不管是直連業(yè)務(wù)系統(tǒng)數(shù)據(jù)源的表進(jìn)行表間關(guān)系建模，還是通過寫 SQL 查詢數(shù)據(jù)結(jié)果集的方式直連業(yè)務(wù)系統(tǒng)，在大多數(shù)情況下都不合理，BI 開發(fā)人員應(yīng)極力避免采用這樣的數(shù)據(jù)操作方式，這些還都是在沒有涉及到多異構(gòu)數(shù)據(jù)源取數(shù)、主數(shù)據(jù)檔案不一致、組織架構(gòu)缺失補位、緩慢漸變維度等問題的前提下。

BI 直接取數(shù)分析什么樣的情況下是可行的 ？

也有朋友說到，我們公司就是直連數(shù)據(jù)庫取數(shù)做可視化分析的。我們讓朋友回去問了一下，原來連接的是企業(yè)已經(jīng)構(gòu)建好的數(shù)據(jù)倉庫。在這種情況下，底層的數(shù)據(jù)模型相對比較標(biāo)準(zhǔn)，數(shù)據(jù)也經(jīng)過了非常良好的格式轉(zhuǎn)換，可以直接使用一些前端 BI 可視化分析工具進(jìn)行快速的分析，這樣的一種搭配就非常好。

所以，BI 直連數(shù)據(jù)庫不是不可行，但得分清楚直連的是業(yè)務(wù)系統(tǒng)的數(shù)據(jù)源數(shù)據(jù)庫，還是直連的是已經(jīng)通過 SQL 從業(yè)務(wù)系統(tǒng)的數(shù)據(jù)源取數(shù)和建模處理后的數(shù)據(jù)倉庫、數(shù)據(jù)集市。

派可數(shù)據(jù)自助開發(fā)平臺包括數(shù)據(jù)倉庫與BI可視化分析

IT 和業(yè)務(wù)的邊界就在這里，IT 負(fù)責(zé)底層數(shù)據(jù)建模、數(shù)據(jù)倉庫的構(gòu)建，業(yè)務(wù)基于已經(jīng)建好的基礎(chǔ)分析模型通過 BI 前端可視化分析工具來進(jìn)行拖拉拽的可視化分析操作。 倘若是這樣，也確實實現(xiàn)了不通過 SQL 取數(shù)使用 BI 前端工具就可以做報表的目標(biāo)。但絕對不能認(rèn)為，不通過 SQL 取數(shù)就可以對接任何業(yè)務(wù)系統(tǒng)數(shù)據(jù)源做任何 BI 可視化分析。

所以，當(dāng)一家企業(yè)底層已經(jīng)有架構(gòu)非常良好的數(shù)據(jù)倉庫，這個時候使用一個輕量的 BI前端可視化分析工具基本上就夠用了。但如果所在企業(yè)底層還沒有良好的數(shù)據(jù)倉庫系統(tǒng)，只寄希望單純的使用一個 BI 前端可視化報表工具解決一切分析問題，這個時候就需要認(rèn)真思考一下是否可行。

原文標(biāo)題：《BI 不是可以拖拉拽取數(shù)嗎？為什么還要 SQL 取數(shù) ? | 專家視角》

作者： 呂品

本文來源于36氪企服點評

分享題目：sapbi系統(tǒng)取數(shù)的簡單介紹
網(wǎng)址分享：http://muchs.cn/article44/dohedee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供靜態(tài)網(wǎng)站、搜索引擎優(yōu)化、網(wǎng)站策劃、網(wǎng)站營銷、外貿(mào)建站、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)