spawn ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@47.251.180.146 cat /www/wwwroot/kivtools.com/application/index/view/index/sql-lineage.html Warning: Permanently added '47.251.180.146' (ED25519) to the list of known hosts. ** WARNING: connection is not using a post-quantum key exchange algorithm. ** This session may be vulnerable to "store now, decrypt later" attacks. ** The server may need to be upgraded. See https://openssh.com/pq.html root@47.251.180.146's password: SQL リネージ分析(カラム・テーブル・影響範囲) | KivTools

SQL リネージ & 影響範囲の分析

SQL・CTE・ビュー・MERGE をまたいでカラム・テーブル・JOIN の依存関係を追跡します。SQL や dbt プロジェクトを取り込み、リネージのデータや図を出力できます。

ブラウザ内でローカルに実行
ローカル処理のみ カラムリネージ 静的解析
SQL・スキーマ・アップロードしたファイルは、このブラウザ内で解析されます。リネージ分析のために KivTools がこれらをアップロードすることはありません。
INPUT

入力ワークスペース

ローカルの SQL エンジンを準備中…
ファイルが選択されていません SQL・ZIP・dbt ファイルをここにドロップ

方言が分かっている場合は実際の SQL 方言を選ぶと、より正確に解析できます。

OUTPUT

リネージグラフ

解析を待機中
エクスポート

カラムを入力から出力まで追跡

サンプルを読み込むか SQL を貼り付け、ローカルの SQLGlot エンジンで解析します。

Direct Transformation コンテキスト

詳細

グラフ内のノードを選択

ノードの詳細、SQL の断片、テキスト形式のリネージ経路がここに表示されます。

下流への影響

決定的な経路

元のカラムを選ぶと、影響を受けるカラム・ビュー・最終結果の数を確認できます。

SQL リネージ

クエリを変更する前に SQL の依存関係を追跡

カラムリネージは、元のカラムが式・CTE・ビューを通って各出力に至るまでをたどります。影響分析はその経路を逆にたどり、元の変更がどこに影響するかを示します。

このアナライザーが解決できること

SELECT、別名、JOIN、サブクエリ、CTE、UNION、集計関数、ウィンドウ関数、QUALIFY、MERGE、CREATE VIEW、CTAS、INSERT SELECT。

スキーマ情報が役立つ場面

CREATE TABLE の定義があると、SELECT * の展開、曖昧なカラムの解決、修飾がより正確になります。

静的解析の限界

動的 SQL とストアドプロシージャは完全には追えないことがあります。データベースの実行時挙動を実際に実行することはありません。

SQL のカラムリネージの読み方

SQL を貼り付けるか .sql ファイルを読み込み、方言を選んで「リネージを解析」を押します。解析エンジンは Web Worker 内の Pyodide 上で動く SQLGlot 30.17.0 です。エンジンのファイルは初回だけダウンロードされ(ステータス表示が Pyodide、次に SQLGlot と進みます)、以降の解析はすべてこのページ内で完結します。解析のためにサーバーへ送信されるものはなく、データベースにも接続しません。

結果はグラフとインスペクターです。「列」モードは元の列から式を経て各出力までの値を追い、「テーブル」モードはテーブルとビューの依存関係に絞り、「結合」モードは ON の関係だけを残します。下の「分析対象」カードはステートメントごとに解決済み・一部・未対応・解析エラーを示し、「警告」カードは解決できなかった原因を挙げます。

  1. ステートメントを入力または貼り付けるか、「例を読み込む」を押します。「スキーマ」タブには CREATE TABLE 定義を入れます。SELECT * の展開や曖昧な列の修飾はこれがある場合に効きます。
  2. 方言は「自動判定」のままにするか、23 件の一覧から選びます。判定はテキスト中の固有の手掛かりを読み取ります。手掛かりが乏しいときは推測せず、方言の選択を求めます。
  3. 「リネージを解析」を押します。カバレッジとグラフが同時に表示されます。「キャンセル」で実行中の解析を止めると、次の解析のためにエンジンが読み直されます。
  4. 確認します。テーブル・ビュー・列を検索し、選択したノードの周辺を「上流」「下流」で絞り込み、「コンテキスト」をオンにすると、フィルタ条件や GROUP BY のキーなど、通過しないが使われている依存関係が加わります。ノードをクリックすると SQL 断片と式が表示され、「下流への影響」カードが変更の及ぶ列・ビュー・最終結果を数えます。
  5. JSON・CSV・PNG・SVG・GraphML でエクスポートします。ファイルはすべてブラウザ内で作られ、CSV は 1 行 1 エッジで、source・target・relation・statement・file・expression を持ちます。

解析できる範囲と、できないこと

グラフの読み方

直接のエッジは、参照や別名のように値がそのまま元から来ていることを表します。計算が入ると変換ノードが現れます。集計・型変換・文字列連結・関数適用などがそれで、「詳細」パネルに対応する式が出ます。キャンバスの上には現在の表示のノード数とエッジ数が出て、ズーム・全体表示・ミニマップ・全画面は描画されたグラフに作用します。

コンテキストは、使われるが通過しない依存関係(WHERE のフィルタ列、結合キー、集計キー)を追加します。オンにするとグラフが目に見えて広がるため、リネージの絞り込みボタンとは分けています。

方言と判定

一覧は ANSI / 汎用 SQL から PostgreSQL、MySQL、SQL Server / T-SQL、Oracle、SQLite、Teradata、Snowflake、BigQuery、Amazon Redshift、Databricks SQL、Microsoft Fabric、DuckDB、ClickHouse、Materialize、Apache Doris、Dremio、Spark SQL、Hive、Trino、Presto、Amazon Athena まであります。パーサーは選んだ方言に従うため、識別子の引用記号、LIMIT / TOP / FETCH FIRST、MERGE の構文などの違いで、同じ文が一方では通って他方では失敗します。

判定は根拠ベースです。MySQL のダンプヘッダー、ENGINE=InnoDB、バッククォートや AUTO_INCREMENT、:: の変換や COPY … FROM stdin、GO や [dbo.]、VARCHAR2 と TABLESPACE、PRAGMA、TIMESTAMP_NTZ などがそれぞれの方言に投票します。ベンダー固有の構文がない SELECT には根拠がないため、推測せず選択を求めます。そのうえで「例」ボタンは選んだ方言向けの例(BigQuery と Snowflake は QUALIFY、Databricks は MERGE、Oracle は NVL など)を読み込みます。

カバレッジ・警告・制限

カバレッジはステートメント単位で、解決済み・一部・未対応・解析エラーと、信頼度の高・中・低を報告するので、長いスクリプトでもどこまで理解できたかが分かります。警告は原因を具体的に示します。スキーマのない SELECT *、結合した 2 つのテーブルに同じ名前の列がある場合、動的 SQL、リネージエンジンがまだ十分に対応していないステートメントなどです。

ここでの解析はすべて静的解析です。動的 SQL やストアドプロシージャはテキストから読み取れる範囲までしか追えず、いかなる文も実行されず、結果の細かさは与えたスキーマに依存します。読み込みは .sql のテキストファイル、プロジェクトの取り込みはフォルダまたは ZIP / dbt プロジェクトで、圧縮 25 MB・展開後 50 MB まで、合計入力は 50 MB が上限です(5 MB を超えると通知が出ます)。エンジン本体は数メガバイトの WebAssembly なので、キャッシュがない初回の解析は以降より明らかに時間がかかります。

最近使ったツール: