このアナライザーが解決できること
SELECT、別名、JOIN、サブクエリ、CTE、UNION、集計関数、ウィンドウ関数、QUALIFY、MERGE、CREATE VIEW、CTAS、INSERT SELECT。
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・CTE・ビュー・MERGE をまたいでカラム・テーブル・JOIN の依存関係を追跡します。SQL や dbt プロジェクトを取り込み、リネージのデータや図を出力できます。
ブラウザ内でローカルに実行スキーマがあると、SELECT * の展開、曖昧なカラムの解決、修飾の精度が向上します。
方言が分かっている場合は実際の SQL 方言を選ぶと、より正確に解析できます。
サンプルを読み込むか SQL を貼り付け、ローカルの SQLGlot エンジンで解析します。
| Source | ステートメント | 状態 | 信頼度 |
|---|
ノードの詳細、SQL の断片、テキスト形式のリネージ経路がここに表示されます。
元のカラムを選ぶと、影響を受けるカラム・ビュー・最終結果の数を確認できます。
カラムリネージは、元のカラムが式・CTE・ビューを通って各出力に至るまでをたどります。影響分析はその経路を逆にたどり、元の変更がどこに影響するかを示します。
SELECT、別名、JOIN、サブクエリ、CTE、UNION、集計関数、ウィンドウ関数、QUALIFY、MERGE、CREATE VIEW、CTAS、INSERT SELECT。
CREATE TABLE の定義があると、SELECT * の展開、曖昧なカラムの解決、修飾がより正確になります。
動的 SQL とストアドプロシージャは完全には追えないことがあります。データベースの実行時挙動を実際に実行することはありません。
SQL を貼り付けるか .sql ファイルを読み込み、方言を選んで「リネージを解析」を押します。解析エンジンは Web Worker 内の Pyodide 上で動く SQLGlot 30.17.0 です。エンジンのファイルは初回だけダウンロードされ(ステータス表示が Pyodide、次に SQLGlot と進みます)、以降の解析はすべてこのページ内で完結します。解析のためにサーバーへ送信されるものはなく、データベースにも接続しません。
結果はグラフとインスペクターです。「列」モードは元の列から式を経て各出力までの値を追い、「テーブル」モードはテーブルとビューの依存関係に絞り、「結合」モードは ON の関係だけを残します。下の「分析対象」カードはステートメントごとに解決済み・一部・未対応・解析エラーを示し、「警告」カードは解決できなかった原因を挙げます。
直接のエッジは、参照や別名のように値がそのまま元から来ていることを表します。計算が入ると変換ノードが現れます。集計・型変換・文字列連結・関数適用などがそれで、「詳細」パネルに対応する式が出ます。キャンバスの上には現在の表示のノード数とエッジ数が出て、ズーム・全体表示・ミニマップ・全画面は描画されたグラフに作用します。
コンテキストは、使われるが通過しない依存関係(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 なので、キャッシュがない初回の解析は以降より明らかに時間がかかります。