數據品質投資的普遍理由是基於營運風險：84% 的組織會因數據品質不佳而遭受可衡量的業務中斷，超過四分之一的組織每年因此直接損失超過 5 萬美元。標準的應對措施是建立資料品質管理程序，該程序會根據既定閾值衡量資料的準確性、完整性、一致性、及時性、有效性和唯一性，並透過指標儀表板追蹤流經營運系統的資料是否符合既定標準。
此標準架構並非為現代化專案而設計。將資料從基於 COBOL 的大型主機遷移到雲端原生平台並非持續的維運品質問題，而是一項具有特定遷移前要求、特定遷移時風險和特定遷移後驗證需求的轉型事件，而標準資料品質維度只能部分滿足這些需求。適用於現代化專案的資料品質評分架構與適用於維運監控的架構在三個根本方面存在差異：它必須評估資料是否適合遷移，而非是否適合當前運維；它必須評估遷移風險，而非維運錯誤率；它必須為遷移驗證過程提供證據，以確認資料來源轉換後的資料是否與資料行為一致。
為什麼標準數據品質框架不足以滿足現代化需求
DAMA（資料管理知識體系）架構的六個維度－準確性、完整性、一致性、及時性、有效性和唯一性－用於衡量資料品質是否符合運作要求。準確率達到 95%、完整性達到 98%、一致性達到 99% 的資料記錄滿足大多數系統的運作品質閾值。但它是否適合遷移以及在目標系統中是否能產生正確結果，則尚待商榷。
不足之處不在於尺寸本身，而是它們衡量的內容以及它們對於現代化專案的具體目的而言所缺少的內容。
遷移適應性與運作適應性並不相同。例如，一個 VSAM 記錄，其包含一個有效的 COMP-3 壓縮十進位字段，該字段在 COBOL 中運作正常。但如果目標資料庫中該欄位被定義為 FLOAT 而非 DECIMAL，則遷移到目標資料庫時可能會出現錯誤。這種精度錯誤雖然能夠透過執行品質檢查，因為讀取原始欄位的 COBOL 程式能夠根據 COMP-3 表示計算出正確的結果，但在使用浮點運算的目標系統中會產生捨入誤差。因此，運行品質得分很高，但遷移適應性得分很低。
源系統的隱式資料契約對外部品質工具是不可見的。 COBOL程式透過流程程式碼、IF 語句中的範圍檢查、EVALUATE 區塊中的格式驗證以及 COMPUTE 語句中的計算規則來強制執行資料品質。這些品質規則存在於原始程式碼中，而非資料本身。外部資料品質工具如果只分析資料而不分析產生資料的程序，就無法看到這些隱式約束，因此也無法確定目標系統是否強制執行了等效的約束。
人工智慧就緒度引入了營運和遷移適應性之外的第三個維度。 Gartner預測，到 2026 年，60% 缺乏人工智慧就緒資料支援的人工智慧專案將被放棄。 「人工智慧就緒資料」與營運定義中的「乾淨資料」並不相同。人工智慧模型並不知道財務系統中的「收入」不包含退款，而客戶關係管理系統 (CRM) 中的「收入」則包含退款，它會將兩者視為同一指標，並利用這種不一致性進行構建。作為人工智慧或分析轉型一部分的現代化專案必須根據第三個標準來評估資料品質：遷移後的資料能否在下游人工智慧和分析工作負載中產生可靠的結果。
現代化特有的資料品質維度
針對現代化項目的資料品質評分框架，在標準的六個維度基礎上增加了五個專門針對遷移的評估維度：
標準六維度（應用於遷移環境）
準確性準確性是指資料正確表示其所描述的現實世界實體或事件的程度。在遷移環境中，準確度必須同時針對來源系統和目標系統的表示進行評估。例如，儲存為 的財務金額。 PIC S9(11)V99 COMP-3 在 COBOL 中，DECIMAL(13,2) 表示以壓縮十進位格式儲存的兩位小數。目標資料庫中儲存為 DECIMAL(13,2) 的相同數值表示的是相同的值。而儲存為 FLOAT(8) 的相同數值表示的是近似值，但並非完全相同，因為有些數值無法用二進位浮點數精確表示。
完整性是指所有必需資料存在的程度。 COBOL 程式經常使用填滿欄位、填滿位元組和哨兵值（全空格、全零、高值）作為 NULL 的功能等效項，但這些值並不能直接轉換為 SQL 的 NULL 語意。遷移的完整性評估必須識別這些功能性空值（即物理上存在但表示缺少有效資料的值），並確定它們如何對應到目標系統的空值處理機制。
一致性是指資料在不同資料集之間或同一資料集內部不存在矛盾的程度。對於大型主機資料而言，跨程序的一致性特別重要：同一個業務實體（例如客戶、帳戶或保單）可能存在於多個由不同程序維護的 VSAM 檔案或 DB2 表中。每個程式都記錄著該實體的目前狀態。一致性評分必須評估這些表示是否一致，或識別出在遷移產生一致目標資料集之前必須解決的差異。
及時性是指資料在可接受的時間範圍內反映當前實際情況的程度。對於批量處理的大型主機數據，及時性取決於批次週期：每月一次的批次可以產生一個月內更新的數據。目標系統對及時性的要求較高，可能需要近乎即時的資料來處理來源系統原本設計不支援的分析工作負載，這就造成了僅靠遷移無法彌補的及時性差距。
合法性資料符合已定義格式和類型約束的程度。 COBOL 的 88 級條件名稱創建了資料類型系統無法捕獲的語義有效性約束：一個定義為 PIC 9(2) 在 COBOL 程式中，此欄位僅當包含 01-12（月份）或 01-31（日期）的值時才有效，其有效性由 88 級條件強制執行。外部資料品質工具在分析該欄位時，看到的是一個兩位數的數字欄位；它們無法識別語義約束，該約束使得值 00 和 13-99 在上下文中無效。
唯一性是指資料實體被表示為唯一一次的程度。對於 COBOL 資料而言，唯一性維度需要瞭解：VSAM KSDS 檔案在檔案層級強制執行主鍵唯一性，但同一個邏輯實體可能出現在由不同程式維護的多個 VSAM 檔案中，且具有不同的鍵。跨檔案實體解析，即確定 CUSTMSTR.VSAM 中的 CUSTOMER-RECORD 和 ACTHLD.VSAM 中的 ACCOUNT-HOLDER 是否代表同一個現實世界的人，是一個唯一性問題，無法透過單獨檢查任一檔案來評估。
五個與移民相關的向度
結構完整性是指資料實體佈局與程式預期模式定義相符的程度。 COBOL 資料根據 PIC 子句規範儲存；磁碟或 VSAM 記錄中的實體位元組必須符合這些規範，程式才能正確解釋它們。結構完整性故障（例如，COMP-3 欄位包含壓縮十進位無效的位元模式，或數值欄位包含非數字字元）通常存在於遺留資料中，並且對於從未執行過這些無效值的程式來說是不可見的。當轉換工具嘗試讀取這些欄位時，它們就會成為遷移失敗。
模式變體覆蓋率，是指資料品質評分對源模式中所有 REDEFINES 變體的解釋程度。正如在 VSAM 檔案結構分析中討論的那樣，一條 VSAM 記錄可能具有多個透過 REDEFINES 子句定義的重疊佈局。僅分析基本記錄佈局的標準資料品質評估會忽略 REDEFINES 變體的品質特徵，包括用於確定每個記錄適用哪個變體的鑑別器欄位中的值，以及每個變體欄位值在相應條件下的有效性。
跨程序一致性是指維護相同業務實體重疊表示的程式之間資料值的一致程度。這一維度特別指大型主機環境，在大型主機環境中，多個程式透過共享資料集維護同一實體。如果一條業務規則在兩個程序中的實現方式不同（例如，規則變更時一個程序進行了更新，而另一個程序沒有），則會產生跨程序不一致性，而這種不一致性對於任何單程序資料品質評估都是不可見的。
精度感知品質是指數值資料在目標系統中能夠以相同精度表示的程度。此維度專門針對 COBOL 程式中常見的 COMP-3、COMP 和 COMP-5 字段，這些字段需要精度感知的目標類型映射。品質評估會識別所有數值字段，並評估其值是否在目標字段類型的範圍和精確度範圍內，這是標準分析工具無法執行的遷移特定品質檢查。
遷移準備度評分是對每個資料實體是否可以直接遷移、是否需要遷移前修復或是否需要在目標端進行轉換以實現等效行為的全面評估。遷移準備度評分是上述維度綜合輸出的結果：在準確性、完整性、一致性、有效性、唯一性、結構完整性、模式變體覆蓋率、跨程序一致性和精確性感知品質方面得分高的記錄即可遷移。如果記錄在上述任何維度上未達標，則需要進行處置、清理、轉換、排除或在記錄風險的情況下接受增量資料。
計算綜合品質評分
現代化項目的綜合資料品質評分是各維度評分的加權平均值，其中權重反映了每個維度對特定遷移環境的相對重要性：
| 尺寸 | 標準重量 | 財務數據調整 | 分析目標調整 |
|---|---|---|---|
| 準確性 | 30%（精度要求極高） | ||
| 完備性 | 25%（人工智慧需要完整的功能） | ||
| 一致性 | 20%（監管） | ||
| 合法性 | |||
| 唯一 | 15%（人工智慧去重） | ||
| 及時性 | 5% | 5% | 10%（模特兒新鮮度） |
| 結構完整性 | 5% | 2% | 0%（轉換後） |
| 模式變體覆蓋率 | 3% | 2% | 0% |
| 跨節目一致性 | 1% | 1% | 0% |
| 精準意識質量 | 1% | 1% | 0% |
每個維度得分範圍為0-100分，綜合得分是各維度得分的加權總和。綜合得分決定了移民準備程度的分類：
| 綜合得分 | 遷移準備狀況 | 建議處置 |
|---|---|---|
| 90-100 | 各就各位 | 使用標準驗證進行遷移 |
| 75-89 | 已準備好監控 | 遷移時需增強遷移後驗證 |
| 60-74 | 條件 | 在遷移之前修復特定維度故障 |
| 40-59 | 沒有準備好 | 遷移前需要進行大量補救工作。 |
| 在40下面 | 關鍵品質問題 | 在完成根本原因分析和補救措施之前，請勿遷移。 |
實際測量：評估工作流程
現代化專案的數據品質評分評估遵循特定的工作流程，這與營運品質監控有所不同：
步驟 1：模式發現和文件編制。在對任何數據進行評分之前，必須先了解定義該數據的模式。對於大型主機數據，這表示要解析存取每個資料集的每個 COBOL 程式中的 FD 條目、COPY 成員和 SELECT 子句。模式發現階段會產生：包含資料類型、長度和 COMP 規範的完整欄位清單；所有 REDEFINES 層次結構及其鑑別條件；88 級條件名稱及其語義約束；以及嵌入在 PROCEDURE DIVISION 邏輯中的程式級資料品質規則。
步驟 2：根據發現的模式進行資料分析。根據步驟 1 中發現的模式（而非假定的或已記錄的模式）對每個資料集進行資料分析。資料分析內容包括：空值等效頻率（空格、零、預期為空語義的欄位中出現高值）；值範圍分佈是否符合 88 級約束；結構完整性（有效的 COMP-3 位元模式、有效的 COMP-5 表示）；跨欄位一致性（日期欄位中日期值共享最大值的情況）；以及跨記錄一致性（相關屬性記錄本應具有一致的記錄值）。
步驟 3：跨程序一致性評估。對於每個在多個程序或資料集中都有體現的業務實體，評估其在不同表示形式下的一致性。這需要：識別哪些程式維護重疊的表示形式（透過依賴關係映射）；提取每個實體在每種表示形式下的記錄；比較應該保持一致的值；並記錄差異及其頻率和嚴重程度。
步驟 4：精度影響分析。對於每個 COMP-3 和二進制數值字段，計算目標字段類型映射的精度影響。具體而言：識別來源資料中任何無法在目標欄位類型中精確表示的值；量化類型轉換導致的捨入誤差；並根據下游用例（監管報告與內部分析的容差閾值不同）確定該舍入誤差是否可以接受。
步驟 5：維度評分和綜合評分計算。應用維度評分，並根據資料類型和遷移目標上下文進行加權。產生每個資料集以及整個資料集組合的綜合評分和遷移準備度分類。
步驟 6：補救計畫。對於得分低於遷移準備閾值的資料集，制定補救計劃，明確以下內容：哪些具體資料元素未通過品質檢查；受影響的記錄數量；用於糾正故障的業務規則或轉換；以及用於確認補救已完成的驗證檢查。
用於資料品質測量的 SQL 模式
實際的品質評估需要可執行的測量方法。以下 SQL 模式針對從舊系統提取到暫存環境中的數據，實現了最常見的現代化特定品質檢查：
SQL
-- 1. Completeness: detect functional nulls (spaces/zeros as NULL equivalents)
SELECT
COUNT(*) AS total_records,
SUM(CASE WHEN TRIM(CUSTOMER_NAME) = ''
THEN 1 ELSE 0 END) AS functional_null_name,
SUM(CASE WHEN ACCOUNT_BALANCE = 0
AND ACCOUNT_STATUS NOT IN ('ACTIVE','CLOSED')
THEN 1 ELSE 0 END) AS suspicious_zero_balance,
ROUND(100.0 * SUM(CASE WHEN TRIM(CUSTOMER_NAME) = ''
THEN 1 ELSE 0 END)
/ COUNT(*), 2) AS functional_null_pct
FROM staging_customer_master;
-- 2. Validity: check 88-level equivalent constraints (month range)
SELECT
COUNT(*) AS total_records,
SUM(CASE WHEN TRANSACTION_MONTH NOT BETWEEN 1 AND 12
THEN 1 ELSE 0 END) AS invalid_month_count,
SUM(CASE WHEN TRANSACTION_DAY NOT BETWEEN 1 AND 31
THEN 1 ELSE 0 END) AS invalid_day_count,
SUM(CASE WHEN TRANSACTION_YEAR < 1900
OR TRANSACTION_YEAR > 2100
THEN 1 ELSE 0 END) AS invalid_year_count
FROM staging_transaction_header;
-- 3. Precision impact: identify values that lose precision in FLOAT conversion
SELECT
RECORD_KEY,
ORIGINAL_AMOUNT,
CAST(CAST(ORIGINAL_AMOUNT AS FLOAT) AS DECIMAL(13,2)) AS float_roundtrip,
ABS(ORIGINAL_AMOUNT -
CAST(CAST(ORIGINAL_AMOUNT AS FLOAT) AS DECIMAL(13,2)))
AS precision_loss
FROM staging_financial_amounts
WHERE ABS(ORIGINAL_AMOUNT -
CAST(CAST(ORIGINAL_AMOUNT AS FLOAT)
AS DECIMAL(13,2))) > 0.005
ORDER BY precision_loss DESC;
-- 4. Cross-program consistency: compare entity representations across programs
SELECT
a.CUSTOMER_ID,
a.CUSTOMER_NAME AS name_in_custmstr,
b.ACCOUNT_HOLDER_NAME AS name_in_acthld,
a.CUSTOMER_ADDRESS AS addr_in_custmstr,
b.MAILING_ADDRESS AS addr_in_acthld,
CASE WHEN a.CUSTOMER_NAME <> b.ACCOUNT_HOLDER_NAME
THEN 'NAME_MISMATCH' ELSE 'OK' END AS name_consistency,
CASE WHEN TRIM(a.CUSTOMER_ADDRESS) <> TRIM(b.MAILING_ADDRESS)
THEN 'ADDRESS_MISMATCH' ELSE 'OK' END AS addr_consistency
FROM staging_customer_master a
JOIN staging_account_holder b
ON a.CUSTOMER_ID = b.CUSTOMER_ID
WHERE a.CUSTOMER_NAME <> b.ACCOUNT_HOLDER_NAME
OR TRIM(a.CUSTOMER_ADDRESS) <> TRIM(b.MAILING_ADDRESS)
ORDER BY a.CUSTOMER_ID;
-- 5. Uniqueness: identify duplicates on logical keys
SELECT
CUSTOMER_ID,
COUNT(*) AS occurrence_count,
MIN(RECORD_TIMESTAMP) AS first_occurrence,
MAX(RECORD_TIMESTAMP) AS last_occurrence
FROM staging_customer_master
GROUP BY CUSTOMER_ID
HAVING COUNT(*) > 1
ORDER BY occurrence_count DESC;遷移浪潮的品質門控框架
現代化專案通常分批次進行遷移，每次遷移一組應用程式和資料集。資料品質評分架構決定了各批次遷移的組成：
遷移波次資格標準：資料集只有在其綜合品質評分超過該波次的最低閾值時，才有資格參與遷移。對於一級（任務關鍵型）應用，最低閾值為 85 分；對於二級應用，最低閾值為 75 分。這可防止任務關鍵型應用程式遷移到未經充分驗證的資料上。
遷移前品質控制：在任何遷移階段開始執行之前，都會進行最終品質掃描，以確認資料品質評分自初始評估以來沒有下降。如果來源系統持續運作並持續累積不符合評估期間確定的品質標準的新記錄，則資料品質可能會在初始評估和遷移執行之間惡化。
遷移後等效性驗證：每次遷移完成後，品質架構都會提供一個比較基準：基於來源資料計算的每個維度分數都會在遷移後的資料上重新計算，來源資料得分與目標資料分數之間的差異即為遷移品質報告。如果某次遷移產生的目標資料集的準確性、完整性或跨程式一致性低於來源資料集，則表示該遷移引入了品質下降，必須在進行下一輪遷移之前進行調查。
SMART TS XL 支持數據品質評分以實現現代化
遷移特有的品質維度，例如模式變體覆蓋率、跨程式一致性、精確度感知品質和結構完整性，都依賴對來源應用程式程式碼的深入理解，而標準資料品質工具無法提供這種理解。它們要求了解產生數據的程式如何定義有效數據，哪些欄位是 COMP-3 類型並需要精度感知目標映射，以及哪些程式維護相同業務實體的重疊表示。
SMART TS XL“ 靜態程式碼分析 提供模式發現層：解析 COBOL 產品組合中的每個 FD 條目、COPY 成員和 SELECT 子句，以產生完整的模式清單，包括所有欄位定義、所有 REDEFINES 層級結構、所有 88 級約束以及所有 COMP-3 精度規格。此清單是遷移特定品質維度所需的基礎，無法從資料本身匯出。
應用程式依賴關係映射能夠實現跨程式一致性評估：透過建立程式間資料關係圖，確定哪些程式維護哪些資料、哪些程式寫入哪些 VSAM 資料集以及哪些資料集包含相同業務實體的重疊表示，依賴關係映射可以識別需要進行跨程式一致性評分的程式對和程式組。如果沒有此映射圖，則無法評估跨程序一致性維度，因為評估人員無法得知哪些程序和資料集表示相同的實體。
影響分析功能使品質門框架能夠大規模運行：當在特定資料集中發現品質問題時，影響分析會識別依賴該資料集的每個應用程式、程式和業務流程，確定品質問題下游後果的範圍，並根據受影響的依賴程序的數量來確定補救措施的優先順序。
企業級搜尋功能使得在整個遷移過程中都能查詢品質清單：尋找讀取特定 VSAM 檔案的每個程式（以評估跨程式的一致性），尋找定義為 COMP-3 的每個欄位（以建立精確的品質清單），尋找每個 88 層級條件名稱（以枚舉外部工具無法識別的語義有效性約束）。此搜尋功能支援初始品質評估和持續監控，確保在評估和遷移執行之間品質不會下降。
對於進行以下活動的組織 遺產現代化 程式， SMART TS XL這項分析彌合了為運行監控而設計的資料品質框架與決定現代化專案能否產生正確結果的遷移特定品質要求之間的差距。標準資料品質維度是必要的，而遷移特定的擴展則使它們變得充分。
結論：遷移品質不等於營運品質。
2026 年的數據品質格局已涵蓋眾多框架、工具和指標，這些框架、工具和指標均專為營運數據管理而設計。 DAMA 維度已充分發展和廣泛應用。相關工具，例如 Great Expectations、Monte Carlo、Collibra 和 dbt，也已日趨成熟。定義品質規則、分析資料並根據閾值進行監控的標準方法，對於其最初設計的營運用途而言，效果顯著。
現代化專案需要不同的方法。它們需要評估遷移的適用性，而非運作的適用性，並進行品質評分。它們需要理解生成資料的原始程式碼，而不僅僅是資料本身。它們需要精確的數值欄位分析、REDEFINES 變體覆蓋率以及跨程式一致性評估——這些方面是運行品質框架所不涉及的，因為運行系統本身並不需要這些。
那些能夠確保遷移結果正確的組織，會先針對遷移這一特定目標建立資料品質評分框架，然後再將其擴展到後續的營運監控。遷移資料品質並非營運資料品質管理的子集，而是一門獨立的學科，擁有自身的維度、閾值和驗證要求。只有將其視為獨立的學科，才能確保現代化專案兌現其技術承諾。
