レガシーDBの分かりにくいテーブル名を調査するときに気を付けたいこと

古い業務システムを引き継ぐと、テーブル名を見ただけでは用途が分からないことがあります。T_MST01、wk_data、JUCHU_H のような名前が並んでいて、どの画面や帳票に関係するのか、今も使われているのか判断できない。そんな状態で修正や移行を進めるのは危険です。

大切なのは、テーブル名から意味を当てにいくことではありません。

名前、カラム、制約、データ、アプリケーション側の利用箇所を順に見て、根拠を積み上げることです。

この記事では、レガシーDBの分かりにくいテーブル名を調査するときの初動手順を整理します。

最初に決めるのは「何を触るか」ではなく「何を確認するか」

テーブル名が分からないときほど、先にSQLを実行して中身を見たくなります。ただ、最初に決めるべきなのは「このテーブルを修正するか」ではなく、「何を確認すれば用途を説明できるか」です。

まずは調査を読み取り専用に限定します。可能であれば本番DBではなく、検証環境や参照用DBで確認します。本番DBを見る必要がある場合も、更新系SQLを実行しない権限で入るのが基本です。

最初のメモには、次の3つだけでも書いておくと調査がぶれにくくなります。

• 調べたいテーブル名
• 調査の目的
• いま分かっている仮説

たとえば「wk_sales_tmp は売上集計の一時テーブルらしい」程度の仮説で構いません。重要なのは、仮説を事実として扱わないことです。以降の手順では、この仮説を支える根拠、または否定する根拠を集めていきます。

テーブル名だけで用途を断定しないことが大事です。レガシーDBでは、名前と実態がずれていることが多々あります（経験談）。

メタデータからテーブルの輪郭をつかむ

次に見るのはテーブルの中身そのものではなく、メタデータです。

メタデータとは、テーブル名、カラム名、データ型、NULL可否、デフォルト値、制約、コメントなど、データ構造を説明する情報です。

カラム名を見ると、テーブル名よりも業務の手がかりが多く見つかります。たとえば customer_id、order_no、billing_month、deleted_flg のような列があれば、顧客、受注、請求、論理削除といった用途を推測できます。

あわせて見るべきなのは、主キー、ユニーク制約、外部キー、インデックスです。外部キーが定義されていれば関連テーブルを追いやすくなります。外部キーがない場合でも、インデックス名や同じカラム名から関連候補を探せます。

最低限見るSQLの例

多くのDBでは、INFORMATION_SCHEMA やシステムカタログからテーブル定義を確認できます。実際のSQLはDB製品や権限によって変わりますが、最初は次のような観点で確認します。

SELECT
  table_schema,
  table_name,
  column_name,
  data_type,
  is_nullable,
  column_default
FROM information_schema.columns
WHERE table_name = '調査対象テーブル名'
ORDER BY ordinal_position;

SELECT
  table_schema,
  table_name,
  column_name,
  data_type,
  is_nullable,
  column_default
FROM information_schema.columns
WHERE table_name = '調査対象テーブル名'
ORDER BY ordinal_position;

SQL Serverで外部キーの関係を見る場合は、sys.foreign_key_columns などのカタログビューが手がかりになります。外部キーが正しく定義されているDBなら、どのテーブルのどの列を参照しているかを確認できます。

SELECT
  fk.name AS foreign_key_name,
  parent_table.name AS parent_table,
  parent_column.name AS parent_column,
  referenced_table.name AS referenced_table,
  referenced_column.name AS referenced_column
FROM sys.foreign_key_columns fkc
JOIN sys.foreign_keys fk
  ON fkc.constraint_object_id = fk.object_id
JOIN sys.tables parent_table
  ON fkc.parent_object_id = parent_table.object_id
JOIN sys.columns parent_column
  ON fkc.parent_object_id = parent_column.object_id
 AND fkc.parent_column_id = parent_column.column_id
JOIN sys.tables referenced_table
  ON fkc.referenced_object_id = referenced_table.object_id
JOIN sys.columns referenced_column
  ON fkc.referenced_object_id = referenced_column.object_id
 AND fkc.referenced_column_id = referenced_column.column_id;

SELECT
  fk.name AS foreign_key_name,
  parent_table.name AS parent_table,
  parent_column.name AS parent_column,
  referenced_table.name AS referenced_table,
  referenced_column.name AS referenced_column
FROM sys.foreign_key_columns fkc
JOIN sys.foreign_keys fk
  ON fkc.constraint_object_id = fk.object_id
JOIN sys.tables parent_table
  ON fkc.parent_object_id = parent_table.object_id
JOIN sys.columns parent_column
  ON fkc.parent_object_id = parent_column.object_id
 AND fkc.parent_column_id = parent_column.column_id
JOIN sys.tables referenced_table
  ON fkc.referenced_object_id = referenced_table.object_id
JOIN sys.columns referenced_column
  ON fkc.referenced_object_id = referenced_column.object_id
 AND fkc.referenced_column_id = referenced_column.column_id;

ここでの目的は、完璧なER図を作ることではありません。対象テーブルが「マスタなのか」「トランザクションなのか」「一時作業用なのか」「連携用なのか」を絞ることです。

関連テーブルとデータの動きから用途を絞る

メタデータで輪郭が見えたら、次は関連テーブルを探します。

レガシーDBでは外部キーが定義されていないことも珍しくありません。その場合は、同じカラム名、似た接頭辞、ID列、日付列、ステータス列を手がかりにします。

たとえば customer_id を持つテーブルが複数あるなら、顧客マスタ、受注、請求、問い合わせ履歴などにつながっている可能性があります。order_no や slip_no のような番号列があれば、ヘッダテーブルと明細テーブルの関係を疑います。

実データを見るときは、まず件数、最新更新日、代表的な値の分布を確認します。いきなり全件を取得するのではなく、件数や日付範囲を見てからサンプルを絞ります。

SELECT COUNT(*) FROM target_table;

SELECT
  MIN(updated_at) AS first_updated_at,
  MAX(updated_at) AS last_updated_at
FROM target_table;

SELECT COUNT(*) FROM target_table;

SELECT
  MIN(updated_at) AS first_updated_at,
  MAX(updated_at) AS last_updated_at
FROM target_table;

ただし、件数が少ないから不要とは限りません。年次処理だけで使うテーブル、障害時だけ使う退避テーブル、外部連携の履歴テーブルなど、普段は動きが少ない重要テーブルもあります。

見るべきなのは、件数そのものより「どの業務タイミングで増減するか」です。日次バッチの後に増えるのか、画面登録で増えるのか、月末だけ更新されるのか。データの動きが分かると、テーブル名よりも用途に近づけます。

アプリケーション側の参照箇所を必ず見る

DBだけを見ても、現行システムでどう使われているかまでは分からないことがあります。特にレガシーシステムでは、DB上に外部キーがなく、アプリケーション側のSQLだけで関係が作られていることがあります。

そのため、対象テーブル名でソースコード全体を検索します。SQLファイル、DAO、Repository、Mapper、ORMのモデル定義、バッチ、帳票出力、CSV連携、設定ファイルを確認します。テーブル名が直接出てこない場合は、カラム名や画面項目名でも検索します。

見るポイントは次の通りです。

• SELECTだけで使われているか、INSERT/UPDATE/DELETEもあるか
• どの画面、API、バッチ、帳票から呼ばれているか
• JOINしている相手のテーブルは何か
• WHERE句でよく使われる条件は何か
• 更新タイミングが業務イベントと一致するか

ここで参照箇所が見つかれば、テーブルの用途はかなり絞れます。逆に、DBには存在するのにアプリ側参照が見つからない場合は、外部ツール、手動運用、古い連携、削除漏れの可能性を分けて確認します。

「参照が見つからないから未使用」とすぐに決めるのは危険です。ジョブ管理ツール、BIツール、別リポジトリ、ストアドプロシージャ、DBリンクなど、アプリケーション外から使われていることもあります。

調査メモは「分かったこと」と「未確認」を分けて残す

調査結果は、あとから見た人が同じ判断を再現できる形で残します。単に「売上関連っぽい」と書くのではなく、なぜそう考えたのかを根拠付きで書きます。

特に重要なのは、分かった内容と未確認のことを分けることです。レガシーDB調査では、すべてを一度に確定できないことがあります。そのときに未確認点を曖昧にしたまま修正へ進むと、後で影響漏れが起きます。

調査メモの書き方例

対象テーブル:
  wk_sales_tmp

調査目的:
  月次売上集計処理で使われているか確認する

分かったこと:
  - sales_id, customer_id, billing_month を持つ
  - 月次バッチの SQL から INSERT/DELETE されている
  - 画面からの直接参照は見つかっていない

根拠:
  - information_schema.columns の確認結果
  - batch/monthly_sales.sql の参照
  - 更新日時が月末処理時間帯に集中

未確認:
  - BIツールや手動SQLから参照されているか
  - 古い帳票処理で使われていないか

次の確認:
  - ジョブ定義と帳票リポジトリを検索する

対象テーブル:
  wk_sales_tmp

調査目的:
  月次売上集計処理で使われているか確認する

分かったこと:
  - sales_id, customer_id, billing_month を持つ
  - 月次バッチの SQL から INSERT/DELETE されている
  - 画面からの直接参照は見つかっていない

根拠:
  - information_schema.columns の確認結果
  - batch/monthly_sales.sql の参照
  - 更新日時が月末処理時間帯に集中

未確認:
  - BIツールや手動SQLから参照されているか
  - 古い帳票処理で使われていないか

次の確認:
  - ジョブ定義と帳票リポジトリを検索する

このように書いておくと、レビューする人も「どこまで分かっていて、どこから先が仮説なのか」を判断できます。テーブル名の意味を当てるより、判断の根拠を残すほうが実務では役に立ちます。

まとめ

レガシーDBのテーブル名が分かりにくいときは、名前だけで用途を決めないことが重要です。まず読み取り専用で安全に入り、メタデータ、関連テーブル、実データ、アプリケーション側の参照箇所を順に確認します。

外部キーがない、コメントがない、仕様書が古いという状況でも、根拠を積み上げれば用途は少しずつ絞れます。反対に、根拠が足りない部分は未確認として残すべきです。

次に同じDBを見る人のためにも、調査メモには「分かったこと」「根拠」「未確認」「次の確認」を分けて残しておくことをお勧めします。分からないまま更新作業に進まないことが、レガシーDB対応で一番大事な安全策です。