基本情報技術者 2015年春期午前（科目A）問26

問題文

DBMSが、3層スキーマアーキテクチャを採用する目的として、適切なものはどれか。

🖊️ 解答を隠して解いてみる

選択肢

ア：関係演算によって元の表から新たな表を導出し、それが実在しているように見せる。

イ：対話的に使われるSQL文を、アプリケーションプログラムからも使えるようにする。

ウ：データの物理的な格納構造を変更しても、アプリケーションプログラムに影響が及ばないようにする。（正解）

エ：プログラム言語を限定して、アプリケーションプログラムとDBMSを緊密に結合する。

🔒 解説は解答すると表示されます

3層スキーマアーキテクチャ【午前解説】

正解の理由

正解はウです。3層スキーマ（ANSI/SPARCモデル）は外部（利用者視点）、概念（全体論理）、内部（物理実装）の三つを分離します。内部スキーマ（物理格納構造）を変更しても概念スキーマや外部スキーマへのマッピングを更新すれば、アプリケーションプログラム（外部スキーマを参照）に直接の影響が及ばない、つまり物理的独立性が保たれます。従って「物理構造変更がアプリに影響を及ぼさないようにする」という選択肢が目的に合致します。

解法ステップ

問題文のキーワード「3層スキーマアーキテクチャ」を思い出す（外部・概念・内部の三層）。
各選択肢を「外部・概念・内部」のどの層の役割と関連するかで照合する。
「物理的な格納構造を変更してもアプリに影響しない」は内部スキーマの役割であり、3層の目的そのものと一致するため選択する。

選択肢別の誤答解説

ア: 関係演算で導出される表（ビューに相当）を「実在しているように見せる」という表現はビューの説明であり、3層スキーマの目的を表す説明ではありません。
イ: 対話的SQLをアプリから使えるようにすることはインタフェースやAPIの問題であり、3層スキーマの本質的目的ではありません。
ウ: 正解。物理（内部）スキーマの変更を概念・外部スキーマから分離して、アプリに影響を与えないようにする点が3層の主目的です。
エ: プログラム言語を限定してDBMSと緊密に結合することは独立性を損なう方針であり、3層スキーマの逆であるため不適切です。

よくある誤解

「ビューを作れば全て解決できる」と考える誤解：ビューは外部スキーマの一形態であり、抽象化はするが物理的独立性はスキーマレイヤの設計に依存します。
「SQLを使えるようにすればプログラム結合が減る」とする見当違い：SQLの可用性はAPI的問題で、3層スキーマの目的（独立性確保）とは別次元です。
「プログラム言語を限定して結合すれば効率化できる」が目的だとする誤り：それは可搬性や独立性を損ない、3層アーキテクチャの逆を行く考えです。

補足コラム

ANSI/SPARCの3層モデルは教育や設計上の抽象概念として広く参照されます。具体的には次のような利点があります：

物理的独立性：ファイル構造、インデックス、配置を変更しても概念・外部スキーマは不変にできる。
論理的独立性：概念スキーマの変更が外部スキーマやアプリに与える影響を最小化できる。
実務では、ビュー（外部スキーマ）とORマッパーやDBアクセス層を組み合わせてこれらの独立性を実現します。また、インデックス追加やパーティション化などの物理最適化は内部スキーマ側の作業であり、正しくマッピングを保てばアプリ改修は不要です。

FAQ

Q1: 物理的独立性と論理的独立性はどう違いますか？
A1: 物理的独立性は内部スキーマ（格納方法）の変更が概念・外部スキーマに影響しないこと、論理的独立性は概念スキーマの変更が外部スキーマに及ぼす影響を抑えることです。

Q2: ビュー（外部スキーマ）を使えば物理変更の影響は完全になくなりますか？
A2: ビューは有効ですが、概念スキーマと外部スキーマのマッピングが適切に維持されることが前提で、完全に自動で解決するわけではありません。

Q3: 実際のRDBMSで3層はどの程度守られていますか？
A3: 理想は守られており、多くのRDBMSは内部と概念の分離をサポートしますが、運用やアプリ設計次第で独立性が損なわれることもあります。

関連キーワード: 3層スキーマ、外部スキーマ、概念スキーマ、内部スキーマ、物理的独立性、論理的独立性、ビュー、ANSI/SPARC

← 前の問題へこの年度をクイズで解く次の問題へ →

\ せっかくなら /

基本情報技術者を
クイズ形式で学習しませんか？

クイズ画面へ遷移する→

すぐに利用可能！