實施資訊系統，計畫為先，而計畫制定，資料又得先行，全面、準確、及時的資料是系統正常執行的前提，高質量資料是推動上線的巨大動力。本文所要**的資料轉換（data conversion）在時間軸上橫跨了需求定義、方案設計、建立系統及系統切換四階段。在傳統的aim中，需求定義階段中的資料轉換主要工作是定義資料轉換需求及依據需求制定方案；方案設計階段的資料轉換主要事務是定製轉換標準，準備環境；建立系統階段的資料轉換工作主要是設計和測試匯入的程式及驗證指令碼，為接下來的匯入做好準備；而系統切換階段的資料轉換主要工作是對匯入程式、匯入工具在正式環境中的安裝及最終匯入收集的資料，及最後的資料驗證。
但方**更多的是從理論的角度去考慮整體框架，各階段各流程都是「可選」步驟，怎樣去做，如何做好，上面沒有提到。而資料收集工作具有要求高，時間緊，難度大等特點，從定義開始，就應該按一定的緊急、先後順序開始收集。筆者在這總結一下自己的經驗，供同仁參考。由於水平有限，錯漏之處在所難免，歡迎商討及指正。
一 資料
首先我們來看資料。 通常企業在實施erp時的資料報含三部分內容，一部分我們稱之為基礎資料，基數資料是系統設定過程中需要用到的資料，例如，會計科目、稅率、庫存組織、子庫存、貨位等；第二部分我們稱之為靜態資料，是系統上線後實際操作中需要用到的資料，例如，客戶/**商、員工、銀行賬戶、物料資訊、工藝路線等，基礎資料與靜態資料我們也可以統一稱為靜態資料；另一部分我們稱之為動態資料，動態資料是系統初始化時需要用到的時點資料，例如，期初的賬戶餘額、**商餘額、客戶餘額、庫存現有量，未結銷售/採購訂單，未結工單等。在制定erp上線方案時需要綜合考慮這三方面的資料，按一定的緊急、先後順序進行收集。
基礎資料通常格式固定，對資料質量要求比較高，時效快，資料收集工作有可能需要提前到需求定義階段就著手準備。基礎資料完成後，我們可以通過系統自帶的診斷工具進行測試系統設定的完整性。
對於靜態資料，通常也是相對比較簡單，由於靜態資料在錄入系統後，基本上不會去改變，所以只要保證這些資料是完整並且準確的就足夠了。而事實上，靜態資料往往存在於企業的現時業務中，一方面收集比較方便，另一方面這些資料在整個企業內部已具有通用性，如果對原有的物料編碼進行改進或重編，必須考慮到唯一性、統一性、實用性及易用性。
動態資料按時點來分，分為期初資料和日常資料，最為熟悉的期初資料就是庫存期初值和財務賬戶期初餘額，有條件的企業應該對期初資料進行盤點。而日常資料報括企業未結銷售訂單、未結採購訂單、未結工單。要想準備好這部分資料，企業應該在上線前界定蒐集到哪一天的未結單據， 這些單據只需要統計其未完成數量，也就是說訂單總數減去已交貨數量，工單總數減去已完工入庫數量，而且可以按照一定的條件來彙總，比如乙個**商可能存在多個未結採購訂單，可以按**商來匯**計成乙個未結採購訂單表來匯入系統。而這以後的單據將作為系統的日常操作，在上線過程中隨時根據需要錄入系統。未結單據應當在上線前盡可能的結清，以減少手工和系統切換的難度，同時也降低日後對賬的工作量。
二 資料收集過程
在資料收集過程中，應當遵循一定的先後順序、一定的收集方法來進行。有條件的企業應該做幾輪資料收集，並分析，盡可能避免在匯入正式系統後進行資料的修改。
1) 了解及確認企業所屬行業的特點和資料量
不同的行業對資料的要求不盡相同，例如醫療系統對**商的考核制度與普通企業的考核就是不同，同樣資料量的大小也決定著你會使用什麼方法處理匯入資料，例如分銷渠道較長的企業的客戶可能只管理到**商；而短渠道企業可能會管理到批發商、零售商。較少的資料我們可以使用手工的方法匯入，但資料量一大了，我們得採取程式匯入來協助我們。
2) 討論及確認資料收集的專案及**、詳細計畫
收集的專案通常結合系統對資料的要求及企業行業特殊性來確定哪些資料需要收集，同樣要決定資料**於何處，是從舊資訊系統移植還是從檔案資料獲取，詳細計畫包括評估資料收集工作量、提前期、責任人等。
3) 整理資料收集方案和資料收集表
收集方案是企業對資料的要求及對這些需求做出的收集策略，是資料收集過程中的指導方針；根據資料收集方案合理設計資料收集**，應對資料**進行詳細的資料收集說明。
4) 客戶收集資料
資料從開始收集到結束往往會占用比較多的時間及資源，為了保證資料的準確性，我們除了實時解答任何疑問外，通常要對客戶收集過程分階段取樣分析，從一開始就監控資料朝著我們目的方向邁進。
5) 對於匯入系統的資料進行格式的整理
根據完成的資料收集表，對映系統需求進行格式的變換及調整。以便能夠按照不同的方式匯入或者輸入系統。
6) 確認資料
多方對輸入資料的確認。
三 資料匯入方法
按著資料方案，確定了收集職責及收集期限，最後收集資料、整理（驗證）提交，在各方確認資料後，那就要開始著手匯入資料。oracle 系統從資料庫、應用兩個層面提供多種方案給您選擇資料匯入的方式。下面以資產資料為例舉例說明。
固定資產資料有兩種匯入方法，一種是通過成批增加介面，另一種是手工在系統錄入。
1） 手工錄入資料
如果選擇手工錄入系統，你除了全手工的通過應用介面一條條錄入外，你還可以選用一些工具，諸如dataload、loadrunner 協助你快速完成匯入的工作。
你選擇手工匯入資料的好處是你可以直觀的輸入資料，可以在輸入的同時檢查錯誤，也很方便的修改一些預設資料，例如根據資產類別自動彈出的折舊方法及剩餘使用壽命（這些在通過介面表的方法中，如果匯入的是舊資產，也必需在介面上修改）。當然手工錄入資料只建議資料量相對較小的資料專案上進行，例如稅率資料，如果資料量在千級別以上，還是建議使用通過成批增加介面匯入資料。
2） 成批增加介面匯入
oracle 乙個很重要的功能是在每乙個模組中都預備了乙個或者數個介面表，以方便模組與模組之間、系統與系統之前進行資料的移植操作。例如，資產的乙個很重要的介面表是「成批增加」（fa_mass_additions）；同樣oracle 提供了很多方法匯入資料到介面表中。sql*loader就是其中資料庫層次的乙個軟體，其外還有adi、api：
a) adi
應用桌面整合 (adi) 是乙個第三方工具，可用於於實際的帳務處理及報表輸出。但我們可以使用他來匯入一些財務資料。例如日記帳、資產明細及會計科目，通常我們會先建立乙個基於excel的模板，如下圖，然後按這些模板格式收集資料，然後直接聯接系統一步完成資產的介面及新增動作。adi簡單易用，安全性高，有很好的資料驗證功能。 adi匯入功能通常僅用於財務模組中的總帳及資產模組。
b) sql*loader
sql*loader 是個直接把外部資料檔案插入資料庫表的工具，速度非常快，僅需要少量的程式設計就可以進行資料的匯入，他包含資料檔案、控制檔案及命令語法三部分內容。
命令舉例：
sqlldr userid=internal/oracle control=test.ctl
splldr 是命令提示符，userid後面需要輸入資料庫訪問使用者名稱及密碼，control 是你的控制檔名，詳細引數資訊請查閱相關文件。
資料檔案舉例：
2003-09-23 | 1 | 04490896 | 347.76 | -
2003-09-28 | 2 | 10256837 | 349.40 | -
2003-09-12 | 3 | 09956875 | 532.30 | -
2003-09-26 | 4 | 10256871 | 581.30 | -
資料僅需要簡單的通過特定的分隔符（｜）告訴系統哪些是資料。
ctl控制檔案：
控制檔案包括了資料檔案路徑和檔名，還定義了匯入的表名,分隔符及資料檔案各列如何正確匯入系統表的各段。sql*loader 通常用於有臨時表的資料匯入工作，對資料的準確性需要其他手段進一步的校驗。
c) api
以上幾種方法，由上往下，技術要求越高，由下往上，越容易操作。但不代表一定要選用這種或者說選擇簡易操作的，顯然要oracle對所有的資料表去做api介面是不可能的。應根據資料的整體情況進行選擇合適的方法進行處理。
四 資料驗證
即使我們在資料匯入前經過仔細核對，並在匯入測試中進行嚴格設計，但仍舊不能夠保證所匯入的資料是完全正確的，這就要求我們對匯入資料進行驗證。常用的輸入資料複核校驗方法有列印輸出核對法、螢幕核對法和二次輸入核對法等。
在實施處理中，利用列印輸出進行資料驗證是一種常用方法，通過系統「匯出」功能，把匯入到系統的資料，列印成紙質文件，然後分發給相關人員核對，並可做為檔案永久儲存。
螢幕核對法主要是對於數量量小，資料儲存相對分散的資料進行對累加合計數，核對餘額，核對借、貸方的金額，核對憑證和帳簿等來發現錯誤。
二次輸入法是採用相應的軟體進行測試，錄入過程分三個步驟：一次錄入，兩次錄入，每次錄入資料後儲存退出；最後就是對碰，目的就是檢測前兩次錄入的資料是否一致，如果一致，就通過；如果不一致，會提示出錯的地方，工作看上去是繁複了，卻可以省略了人工檢查這一步，這通常需要特殊的條件，例如臨時表、嚴格的程式邏輯。
選用什麼方法驗證也要因資料而異，但只要做到能夠核對資料準確無誤，能夠讓你放心的資料匯入確認報告中放心簽下您的名字，那就是可以的了。
Oracle ERP資料轉換論 1
需求定義階段 definition 業務分析階段 operations analysis 方案設計階段 solution design 建立系統階段 build 系統切換階段 transition 正式執行階段 production 注 圖例 於aim 3.1.0官方文件。實施資訊系統，計畫為先，而...
論SparkStreaming的資料可靠性和一致性
摘要 眼下大資料領域最熱門的詞彙之一便是流計算了，而其中最耀眼的無疑是來自spark社群的sparkstreaming專案。對於流計算而言，最核心的特點毫無疑問就是它對低時的需求，但這也帶來了相關的資料可靠性問題。2driver ha 由於流計算系統是長期執行 且不斷有資料流入，因此其spark守護...
資料轉換 強制轉換
1 2 強制型別轉換 3 1.特點 需要進行特殊的格式處理，不能自動完成。4 2.格式 範圍小的型別 範圍小的變數名 範圍小的型別 原本範圍大的資料 56 注意事項 7 1.強制型別轉換一般不推薦使用，因為有可能發生精度損失 資料溢位。8 2.byte short char這三種型別都可以發生數 算...