基本情報技術者 2009年 春期 午前(科目A) 問49
問題文
モデリングツールを使用して、本稼働中のデータベースシステムの定義情報からE-R図などで表現した設計書を生成する手法はどれか。
選択肢
ア:コンカレントエンジニアリング
イ:ソーシャルエンジニアリング
ウ:フォワードエンジニアリング
エ:リバースエンジニアリング(正解)
🔒 解説は解答すると表示されます
リバースエンジニアリング【午前解説】
正解の理由
正解は エ(リバースエンジニアリング)です。
理由は次の通りです。問題は「本稼働中のデータベースシステムの定義情報から設計書を生成する」とあります。これは既に存在する(稼働中の)システムから定義(スキーマ、テーブル、カラム、制約など)を抽出して設計書(E-R図など)を作成する作業であり、ソフトウェアやデータベースの実装から上位の設計情報を導出する「リバースエンジニアリング」の定義と一致します。
対照的にフォワードエンジニアリングは設計モデルから実装(DDLなど)を生成する手法なので、本問の状況とは逆方向です。
理由は次の通りです。問題は「本稼働中のデータベースシステムの定義情報から設計書を生成する」とあります。これは既に存在する(稼働中の)システムから定義(スキーマ、テーブル、カラム、制約など)を抽出して設計書(E-R図など)を作成する作業であり、ソフトウェアやデータベースの実装から上位の設計情報を導出する「リバースエンジニアリング」の定義と一致します。
対照的にフォワードエンジニアリングは設計モデルから実装(DDLなど)を生成する手法なので、本問の状況とは逆方向です。
解法ステップ
- 問題文のキーワードを確認:「本稼働中」「定義情報から」「設計書を生成」。
- 逆方向(実装→設計)か順方向(設計→実装)かを判定。今回は実装(稼働中データ)から設計を作るので逆方向。
- 選択肢の定義を照合:リバースエンジニアリング=実装から上位設計を抽出、フォワード=設計から実装生成。該当はリバース。
- 残り選択肢(コンカレント/ソーシャル)は用語の意味で除外。
選択肢別の誤答解説
- ア: コンカレントエンジニアリング
製品開発で設計・製造等を並行して進める手法であり、既存DBから設計情報を抽出する行為とは無関係です。 - イ: ソーシャルエンジニアリング
人間の心理や信頼を利用するセキュリティ攻撃手法で、データベースの設計書生成とは全く関係ありません。 - ウ: フォワードエンジニアリング
設計(モデル)から実装(コードやDDL)を生成する手法で、問題の「既存稼働から生成する」とは逆方向なので不正解です。 - エ: リバースエンジニアリング
実装済みシステムやデータベースから定義情報を解析して上位設計(E-R図など)を生成する手法であり、本問の記述に該当します。
よくある誤解
- 「フォワード=設計図を作るから正解」と考える誤り:フォワードは設計→実装の流れであり、既存の稼働中データベースから設計書を作るのは逆方向です。
- 「ソーシャルエンジニアリング=エンジニアリングだから関係ある」と混同する誤り:ソーシャルエンジニアリングは人的攻撃手法で、設計書生成とは無関係です。
- 「コンカレントエンジニアリング=同時並行で設計するので同種の手法」と誤認:製品開発プロセスの推進手法であり、データ定義の逆解析とは目的が異なります。
補足コラム
- 実務でのリバースエンジニアリングでは、ツールで自動生成したE-R図が完全に業務要件や意味論を反映するとは限りません。外部キーは掴めても業務上の制約や意味(暗黙のルール)は文書化や関係者への確認が必要です。
- よく使われるツール例:MySQL Workbench、DBeaver、SchemaSpy、ER/Studio、PowerDesigner など。これらはDB接続してスキーマを読み取り、図を生成します。
- 自動生成→手動補正のワークフローを確立しましょう。生成物をそのまま公式設計書にすると誤った設計理解や欠落が残るリスクがあります。
- 開発運用の観点では、スキーマの変更はバージョン管理(マイグレーションスクリプト)で管理し、リバースはドキュメント整備や差分確認のために使うのが効果的です。
コード例:既存DBのメタデータを反映してテーブル情報を取得する(SQLAlchemy の例)
from sqlalchemy import create_engine, MetaData
# 接続文字列は環境に合わせて設定してください
engine = create_engine('mysql+pymysql://user:pass@host/dbname')
meta = MetaData()
meta.reflect(bind=engine)
for table_name, table in meta.tables.items():
cols = [col.name for col in table.columns]
print(table_name, cols)
FAQ
Q1: リバースエンジニアリングで外部キーや制約は必ず取得できますか?
A1: 多くのDBは外部キーやNOT NULL、ユニークなどのメタ情報を持つため取得可能ですが、業務的な意味や手続き的制約はスキーマに表現されない場合があり、別途確認が必要です。
A1: 多くのDBは外部キーやNOT NULL、ユニークなどのメタ情報を持つため取得可能ですが、業務的な意味や手続き的制約はスキーマに表現されない場合があり、別途確認が必要です。
Q2: フォワードエンジニアリングと混同しないポイントは?
A2: 「設計から実装へ進める(設計→DDL)」がフォワード、「実装から設計を作る(DDL→図)」がリバースと方向で区別します。
A2: 「設計から実装へ進める(設計→DDL)」がフォワード、「実装から設計を作る(DDL→図)」がリバースと方向で区別します。
Q3: 既存システムのコードからE-R図を作る場合とデータベース接続で作る場合はどちらが良い?
A3: DB接続でスキーマを直接取得する方が正確ですが、アプリ側に定義が散在する場合はコード解析と併用すると冗長な情報や生成ルールも把握できます。
A3: DB接続でスキーマを直接取得する方が正確ですが、アプリ側に定義が散在する場合はコード解析と併用すると冗長な情報や生成ルールも把握できます。
Q4: 自動生成した図をそのまま設計書として使っても良いですか?
A4: 原則は推奨されません。自動生成はベースとして有用ですが、業務ルールや非表現的制約を追記・確認することが重要です。
A4: 原則は推奨されません。自動生成はベースとして有用ですが、業務ルールや非表現的制約を追記・確認することが重要です。
関連キーワード: リバースエンジニアリング、E-R図生成、データベースリバース、スキーマ反映、モデリングツール、フォワードエンジニアリング、ER図自動生成、DB設計ドキュメント、スキーママイグレーション

\ せっかくなら /
基本情報技術者を
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

