DB2データリネージ：IBM DB2 SQLの列レベルのリネージ

DB2データリネージ これは、IBM DB2 SQL 内でデータがどのように移動するかを示す列レベルのマップです。どのソース列が各ビュー、ウェアハウステーブル、レポート抽出にデータを提供し、どの結合、フィルタ、式、および MERGE ブランチを通過するかを示します。 Gudu SQLFlow この機能はマップを自動的に構築します。専用のDB2方言パーサーを使用してDB2 SQLを解析し、インタラクティブでドリルダウン可能な系統図を表示します。構造化された系統データは、JSON、CSV、PNG、またはREST API経由で利用可能です。

DB2の資産管理において、他の資産管理よりも血統管理が重要な理由

DB2は、誰も壊すことが許されないようなシステム、例えば銀行の中核となる元帳、保険契約管理、請求処理、支払処理などを運用する傾向があります。これらのシステムには3つの共通点があり、そのためデータ系列の維持はあれば良いというものではなく、必須条件となっています。

• 年。 数十年にわたって蓄積されたビュー、バッチSQLジョブ、SQL PLルーチンが重なり合っているため、誰も完全な依存関係グラフを頭の中で把握できておらず、元のコードを書いた人々はすでに退職している場合が多い。
• 規制。 銀行や保険業界の監査人は、列レベルの質問を投げかけます。どのソースフィールドがこの規制報告の行に流れ込んでいるのか、といった質問です。BCBS 239のようなフレームワークでは、2014年に誰かが描いた図ではなく、文書化され証明可能なデータの出所が求められます。
• 移住圧力。 多くのDB2ユーザーがクラウドウェアハウスへの移行を計画しています。どのオブジェクトが何に依存しているか、つまりどのオブジェクトが不要なコードで残しておくべきかを把握せずに、移行の範囲、順序、検証を行うことはできません。

手動マッピングは生き残らない コンタクト 実際のDB2環境において、SQL自体からの自動的なデータリネージは、コードが変更されても正確性を維持できる唯一のアプローチです。

SQLFlowがDB2のデータリネージを構築する方法

SQLFlowは、 汎用SQLパーサー（GSP）DB2は、2000年代半ばから開発され、方言ごとに約13,600のSQLテストフィクスチャで検証された商用SQLコンパイラのフロントエンドです。 独自の構文解析器を持つ39の方言 一般的なANSI文法にDB2特有の構文を付け加えたものではありません。これは重要な点です。なぜなら、DB2 SQLには一般的なパーサーでは処理できない構文が多数含まれており、解析エラーが発生するたびに、データ系列グラフに穴が開いてしまうからです。

分析は完全に静的です。SQLFlowはJDBC経由でSQLテキストと、オプションでスキーマメタデータを読み取りますが、テーブルの行を読み取ることはありません。以下のデータを入力できます。

• 貼り付けたSQL、またはアップロードしたスクリプトファイル（バッチジョブ、DDLの表示、ソースリポジトリからのエクスポートなど）。
• JDBC経由でリアルタイムのDB2メタデータを取得するため、ビュー定義とテーブルスキーマはカタログから直接取得されます。
• 全データベーススキャン：エンタープライズ展開では、100以上のデータベースと100万以上の列をバッチスキャンし、増分再スキャンと永続的なデータリネージリポジトリを備えています。

SQLFlow は、各出力列に対して、どのソース列がどの関数、キャスト、サブクエリ、結合、セット演算子を介してフィードしているかを識別し、共通テーブル式、ネストされたサブクエリ、ビュー、および 選択 * 拡大。

DB2パーサーが理解するもの

DB2 構築	SQLFlow がどのように処理するか
ビュー	ビュー定義は系統グラフに解決されるため、ビューに対するクエリは、ビューが5階層も重なっている場合でも、基底テーブルまでトレースされます。
マージ	両方とも マッチングした場合...更新 と 一致しない場合は...挿入 枝が分析され、 使用 対象列へのサブクエリ。
共通テーブル式	列参照は、 と ブロックには、以前のCTEを参照するCTEも含まれます。
SQL PL構文	解析可能な SQL として処理されます — 選択, 入れる, アップデート、 と マージ DB2ルーチン内のステートメントは、系統グラフに影響を与えます。

一つ注意点があります。SQLFlowの専用の手続き型文法（パラメータ、一時テーブル、動的SQLのトレース、および手続き呼び出しグラフのレンダリングを行うもの）は、Oracle PL/SQLとSQL Server T-SQLを対象としています。DB2 SQL PLは、DB2固有の手続き型エンジンではなく、実際のデータフローが存在するステートメントレベルでカバーされています。

例：DB2 MERGE による列レベルの系統追跡

MERGE ベースのアップサートは DB2 ウェアハウスのロード処理の中核を成すものであり、まさにテーブルレベルのデータリネージでは不十分な部分です。顧客残高サマリーを維持する夜間ジョブを考えてみましょう。

MERGE INTO dw.customer_balance AS tgt USING ( SELECT c.customer_id, c.branch_code, SUM(t.amount) AS balance_amt, MAX(t.posted_ts) AS last_posted FROM core.transactions t JOIN core.customers c ON c.customer_id = t.customer_id WHERE t.status = 'POSTED' GROUP BY c.customer_id, c.branch_code ) AS src ON tgt.customer_id = src.customer_id WHEN MATCHED THEN UPDATE SET balance_amt = src.balance_amt, last_posted = src.last_posted WHEN NOT MATCHED THEN INSERT (customer_id, branch_code, balance_amt, last_posted) VALUES (src.customer_id, src.branch_code、src.balance_amt、src.last_posted);

このステートメントのSQLFlowの図は、対象列ごとに以下のように表示されます。

• dw.customer_balance.balance_amt 供給源は core.transactions.amount を通して 和（） — UPDATE ブランチと INSERT ブランチの両方を介して。
• dw.顧客残高.最終投稿 供給源は core.transactions.posted_ts を通して MAX().
• ブランチコード 直接 core.customers.branch_code変換されていない。
• core.transactions.status そして 顧客ID 結合キーはターゲットには含まれませんが、ターゲットのすべての行を形作ります。SQLFlow はこれらを次のように記録します。 間接的な系統.

直接的な系譜と間接的な系譜：監査においてなぜ重要なのか

SQLFlowは区別します 直系の血統 （ソース列の値がターゲット列に流れ込む） 間接的な系統 （列は、 どこ 句、 参加する 状態、 グループ分け（または集計）。この2つは図上で個別に切り替えることができ、競合するほとんどのツールではこの区別が全くありません。

監査人にとって、その違いは学術的なものではありません。上記のMERGEでは、 t.ステータス コードは上流で再マッピングされ、すべてのバランスが dw.顧客残高 変更 — 価値がないにもかかわらず 状態 表に現れることは決してない。直接的な系統のみではその依存関係を見落とすだろうが、「報告された数値を変更する可能性のあるものは何ですか？」と尋ねる規制当局は見落とすことはない。

DB2からの移行を計画するために系統情報を使用する

DB2を移行元とする場合、リネージはスコープ設定ツールです。環境全体のスキャンを実行すると、以下の情報が得られます。

• 真の依存関係グラフ — どのビュー、ジョブ、および下流の抽出処理が実際に各テーブルを使用しているかを把握することで、移動の順序を決定し、途中でフィードが中断されることを回避できます。
• デッドコード識別 — 読み取りが行われないオブジェクトは、移行するよりも廃止する候補となります。
• 両端での検証 SQLFlowは、DB2に加えてSnowflake、BigQuery、Redshift、Databricks、PostgreSQLなど39種類のSQL方言に対応しているため、書き換えられたSQLを対象プラットフォーム上で分析し、書き換え前後のSQLの系統を比較することができます。

複数のレガシープラットフォームを同時に統合するチームは、エンジン間で同じワークフローを使用します。詳細については、関連ページを参照してください。 Oracle データ系統 と Teradataデータリネージこれらは、それらの方言に対して同じアプローチを扱っています。

導入形態：規制対象のDB2運用環境向けオンプレミス

ほとんどのDB2環境は、SQLテキストがネットワーク外に送信されることのない環境に設置されている。 SQLFlow オンプレミス SQLFlowは、お客様のインフラストラクチャ内で完全にDockerまたはKubernetes上で動作し、完全なエアギャップインストールにも対応します。SQLはネットワーク外に出ることはなく、SQLFlowはテーブルの行データをどこからも読み取ることはありません。 価格 選択したデータベースタイプごとに、月額$500または1回限りの$4,800で、2台のサーバーにインストール可能です。

クエリまたはビューチェーンのトレースのみが必要なチームは、SQLFlow Cloud の無料ティア (プレミアムは月額 $49.99) から始めることができます。エンタープライズ展開では、エクスポートアダプタが追加されます。 DataHub、Microsoft Purview、およびOpenMetadataそのため、DB2 の系統情報は、既に実行しているカタログに取り込まれます。詳細については、 価格ページ.

他のアプローチと比べてどうでしょうか？

Collibra、Atlan、DataHubなどのカタログファーストプラットフォームは、ガバナンスワークフロー、所有権、ビジネス用語集に優れていますが、データを生成するためのリネージソースが必要であり、DB2のカバー範囲は、一般的なSQL解析が通常破綻する部分です。 SQL Lineage と sqlglot DB2は、単純なSELECT文とINSERT文を適切に処理します。 マージスタックビューや SQL PL ルーチンでは、方言の忠実度がグラフの完全性を決定するようになります。SQLFlow の DB2 パーサーは、約 20 年にわたる商用パーサー開発で改良された 39 の方言固有の文法の 1 つであり、エクスポート アダプタを介して、既に所有しているカタログにデータを供給する DB2 系統エンジンとして機能します。公平なテスト: 最も醜い DB2 バッチ ジョブを 無料ビジュアライザー そして、何が返ってくるか見てみよう。

よくある質問

SQLFlowはIBM DB2をサポートしていますか？

はい。DB2は、SQLFlowに専用のパーサーが用意されている39種類の言語のうちの1つです。DB2ビュー、MERGEステートメント、共通テーブル式、SQL PL構造を解析可能なSQLとして扱い、それらすべてにわたって列レベルのデータ系列を生成します。

SQLFlowは私のDB2テーブル内のデータにアクセスする必要がありますか？

いいえ。SQLFlowはSQLテキストの静的解析を行い、必要に応じてJDBC経由でスキーマメタデータを読み取ります。テーブルの行を読み取ることはありません。オンプレミス版では、SQLテキストもネットワーク内に留まり、エアギャップ環境でも問題ありません。

SQLFlowはDB2のMERGEステートメントを通してデータの流れを追跡できますか？

はい。MERGE の UPDATE ブランチと INSERT ブランチの両方が分析され、USING サブクエリから各ターゲット列への列レベルの系統が記録され、結合キーとフィルタ列については間接的な系統が記録されます。

系統追跡機能はDB2からの移行に役立ちますか？

はい。リネージスキャンを実行すると、移行の順序付けに必要な実際の依存関係グラフが得られ、移植する代わりに廃止できる未使用オブジェクトが特定されます。さらに、SQLFlowはSnowflake、BigQuery、Redshift、Databricksなども解析するため、書き換え後にターゲットプラットフォーム上でリネージを検証できます。

DB2の系統情報をDataHub、Purview、またはOpenMetadataにエクスポートできますか？

はい。エンタープライズ向け展開では、DataHub、Microsoft Purview、OpenMetadata用のエクスポートアダプタに加え、JSONおよびCSVエクスポート機能、カスタム統合用のREST APIが提供されます。

DB2用のSQLFlowの価格はいくらですか？

SQLFlow Cloudは無料からスタート。プレミアムプランは月額$49.99。SQLFlow On-Premiseは月額$500、または選択したデータベースタイプごとに$4,800の一括払い（DB2は1タイプとしてカウント）で、2台のサーバーにインストール可能。追加のデータベースタイプはそれぞれ月額$100、または$1,000の一括払い。