基本情報の3層スキーマを変更例で理解する外部・概念・内部の違い

3層スキーマは、利用者が見るデータ、データベース全体の論理構造、記憶装置への格納方法を分けて考える仕組みです。外部・概念・内部の名前を覚えても、「表を分割した」「索引を追加した」という変更例になると迷いやすいですよね。

基本情報で押さえたいのは、変更した層と、その変更から守られる層の組合せです。概念スキーマの変更から外部スキーマを守るのが論理的データ独立性、内部スキーマの変更から概念スキーマを守るのが物理的データ独立性です。この記事では貸出管理の例を使い、何を変えて何を維持するのかを具体的に確認します。

基本情報の3層スキーマの役割

3層スキーマは、同じデータベースを異なる抽象度から説明する考え方です。データベースを3台に増やすことでも、すべてのデータを3か所へ複製することでもありません。まずは「見せ方」「全体の構造」「しまい方」の順に整理すると、各層の役割をつかめます。

IPAの基本情報技術者試験シラバスVer.9.2でも、データベース方式の学習項目として、3層を区別してデータの独立性を高める考え方が示されています。用語を単独で覚えるより、同じ業務を3つの視点で説明できることが大切です。

外部スキーマは利用者側の見え方

外部スキーマは、利用者やアプリケーションが必要とするデータの見え方を定義します。データベース内の全項目を全員へ同じ形で渡す必要はありません。目的に応じて、必要な列だけを選んだり、複数の表を組み合わせたりしたデータを提供します。

ここからは、学習用に作った図書室の貸出管理を考えます。受付担当は会員番号・氏名・貸出冊数を確認したい一方、蔵書担当は図書番号・書名・貸出中かどうかを確認したいとします。同じ貸出記録を使っていても、必要な項目が違います。この違いが外部スキーマの入口です。

利用する側	必要なデータの例	用途
受付担当	会員番号、氏名、貸出冊数	現在の貸出状況を案内する
蔵書担当	図書番号、書名、貸出状況	返却・貸出の状態を確認する
督促処理	会員番号、連絡先、返却期限	期限を過ぎた貸出を抽出する

関係データベースでは、SQLのビューが外部スキーマを実現する代表的な方法です。ビューを通じて、元の表の一部や結合結果を利用者側へ見せられます。ただし、外部スキーマという考え方と、特定製品のCREATE VIEWという機能を完全に同一視する必要はありません。前者は利用者側のデータ定義、後者はその実装方法の一つです。

また、「見え方」は画面の色やボタンの位置という意味ではありません。氏名列を提供するのか、氏名と連絡先を提供するのかといったデータの構造に注目します。文字を青くするだけなら、通常は外部スキーマの変更を説明したことになりません。データの見え方と画面の装飾を分けて考えてください。

利用者ごとのビューを用意することは、不要な情報を渡さない設計に役立ちます。ただし、ビューを作っただけで権限管理が完成するわけではありません。今回はアクセス権の設定方法ではなく、利用者側へどのデータをどう提供するかに焦点を合わせます。

概念スキーマは全体の論理構造

概念スキーマは、データベース全体で扱うデータと、その関係を論理的に定義します。関係データベースの例なら、どんな表があり、各表にどんな列があり、表同士をどう関連付けるかを考える層です。特定の担当者が必要とする一部分ではなく、全体を対象にします。

貸出管理では、会員・図書・貸出という3種類の情報を持つとします。会員番号を使って貸出と会員を関連付け、図書番号を使って貸出と図書を関連付けます。会員番号を一意にするルールや、存在する会員にだけ貸出を記録するルールも、論理的なデータ構造を説明する材料です。

表の例	列の例	関係や役割
会員	会員番号、氏名、連絡先	会員番号で会員を識別する
図書	図書番号、書名	図書番号で貸出対象を識別する
貸出	貸出番号、会員番号、図書番号、返却期限	誰がどの本を借りているかを表す

受付用の見え方に連絡先を含めなくても、データベース全体の定義には連絡先を持たせられます。「画面に表示されないから存在しない」と判断しないことがポイントです。外部スキーマは用途別の窓口、概念スキーマは全体のデータ構造、と対象範囲を比べると区別できます。

表を分ける理由や、データ間の関係を整理する方法は、基本情報のデータベース正規化の解説とER図の読み方の解説で確認できます。この記事では、正規化の手順そのものを増やすのではなく、表の構成を変えたときに外部へどんな影響が出るかを後半で扱います。

「概念設計・論理設計・物理設計」という設計工程の名前と、外部・概念・内部という3層の名前は、そのまま一対一に置き換えないでください。基本情報の3層スキーマを問う場面では、問題文が指定する外部・概念・内部の分類を使い、表の論理構造を概念スキーマとして判断します。

内部スキーマは格納とアクセス方法

内部スキーマは、データを記憶装置上へどう格納し、どうアクセスするかを定義します。ファイル編成、データの配置、探索を助ける索引などが、この視点に入ります。利用者が何を知りたいかではなく、データを実際に保存して探す方法を考える層です。

たとえば、会員番号に対応する貸出記録を探すとき、貸出表を順に調べる方法と、会員番号の索引を利用する方法があります。会員番号・図書番号・返却期限という表の列が同じでも、探索の進め方は変えられます。列や関係を保ちながらアクセス方法を変更できることが、後述する物理的データ独立性につながります。

ここでいう「物理的」は、SSDやHDDの型番だけを意味しません。格納形式や索引の構成など、記憶装置に記録されたデータへ到達する仕組みも含みます。「機械を交換する話だけが内部」と限定すると、インデックスの設定を概念スキーマと取り違えやすくなります。

3層の定義はWilfrid Laurier Universityのデータベース講義資料でも、利用者・全体の論理構造・物理的な符号化や索引という視点で説明されています。試験では、文中の「利用者別」「表の関連」「格納方式」のどれが中心なのかを見て分類すると分かりやすくなります。

スキーマとデータの値を区別する

スキーマはデータの構造を定めるもので、今入っている個々の値とは区別します。貸出表に返却期限という列があることは構造の話ですが、ある本の返却期限を10月20日から10月27日へ更新することは値の話です。後者だけを根拠に、概念スキーマを変更したとは判断できません。

会員を1人追加する、貸出記録を1行削除する、氏名の誤字を直す、といった操作でも、表の列や関係がそのままなら通常はデータの状態だけが変わります。一方、氏名を姓と名の2列へ分けることは、値を入力し直す作業を伴っていても、構造の変更として扱えます。

この区別は、京都大学OCWの情報技術演習資料が整理するスキーマとインスタンスの違いに対応します。問題でデータ更新が出てきたら、「定義が変わったのか、それとも定義に従う値が変わっただけか」を先に確認しましょう。

SQL製品には、表などをまとめる名前空間をスキーマと呼ぶものもあります。製品の設定画面にschemaという語が出るだけで、それを外部・概念・内部のいずれかに決めつけないでください。3層の分類問題では、単語の表示より、何を定義しているかという内容が判断材料です。

3層の間の対応付けが変更を吸収する

利用者が受付用ビューを問い合わせると、DBMSはその見え方を、会員表や貸出表のデータへ対応付けます。さらに、表のデータを実際の格納場所や探索方法へ対応付けます。このように隣り合う層を結び付ける仕組みがあるため、下の層を変えても、上の層の定義を保つ設計を考えられます。

対応付けは、マッピングとも呼ばれます。重要なのは、独立性が「変更作業が何もない」という意味ではないことです。表を分割したらビューの定義を見直す必要があるかもしれませんし、格納方式を変えたらDBMS側の管理情報を調整する必要があるかもしれません。その調整によって、上位側の定義や利用プログラムへ変更を広げずに済むかが焦点です。

この役割分担は、Webシステムのプレゼンテーション層・アプリケーション層・データ層という3層構成とも区別してください。Webの3層構成は処理の責任分担を説明することが中心です。3層スキーマは、一つのデータベースを説明するデータ定義の階層です。「3層」という数だけで同じ内容だと判断しないようにしましょう。

3層スキーマの独立性を例題で判定する

独立性の問題は、「何を変えたか」と「何を変えずに済んだか」を対にして読むと解きやすくなります。アプリケーションを修正しなかった、という結論だけでは分類できません。表の論理構造を変えたのか、格納・アクセス方法を変えたのかまで確認します。

独立性	変更する側	維持する側	この記事の例
論理的データ独立性	概念スキーマ	外部スキーマやそれを利用するプログラム	会員表を分割しても受付用の列を維持する
物理的データ独立性	内部スキーマ	概念スキーマ。さらに利用者側の定義も保つ	索引を追加しても貸出表の意味を維持する

独立性は下位側の変更が上位側へ及ばない能力を表します。San José State Universityの講義資料は、論理的独立性と物理的独立性を、変更する層と維持する層、層間の対応付けという関係で示しています。以下の変更シナリオは、この定義を練習するための自作例です。

表を分割しても同じ列を提供する例

最初の会員表には「会員番号・氏名・連絡先」が入っているとします。受付プログラムは実表を直接読む代わりに、受付会員ビューから「会員番号・氏名」を取得しています。ここで運用を見直し、会員の連絡先を別の表へ分けることになりました。

変更後は、会員基本表に「会員番号・氏名」、会員連絡先表に「会員番号・連絡先」を置きます。会員番号で両者を結び付ける設計です。このとき変わるのは、データベース全体の表の構成なので概念スキーマです。記憶装置上の配置だけを変えているのではありません。

確認対象	変更前	変更後
実表の構成	会員表に基本情報と連絡先がある	会員基本表と会員連絡先表に分かれる
受付会員ビューの提供列	会員番号、氏名	会員番号、氏名を維持する
受付プログラムの取得先	受付会員ビュー	受付会員ビューを維持する

受付会員ビューの参照先を会員基本表へ対応付け直し、提供する列名・データ型・意味を維持できれば、受付プログラムは同じ見え方を使い続けられます。概念スキーマの変更を吸収して外部スキーマを維持するため、この例は論理的データ独立性です。

連絡先も必要とする別のビューでは、2表を結合して元の項目を提供する方法が考えられます。ただし、「結合すれば必ず元どおり」ではありません。会員基本表の1行に連絡先が何行対応するか、連絡先がない会員をどう扱うかによって、結果の行数や欠損の扱いが変わります。保つべき見え方には、列名だけでなく、行の意味も含まれます。

学習用の例で1会員につき連絡先を1件だけと定め、必要な会員には対応する連絡先がある条件を置けば、元と同じ行単位を保つ説明ができます。条件を置かずに1対多へ変更した場合は、同じ会員が複数行になる可能性があるため、旧プログラムの結果をそのまま保証できません。独立性の判定では、このように問題文の前提も読みます。

ビューによる問合せの対応付けは、PostgreSQL公式のビューとルールシステムの説明でも確認できます。ここでの例は参照するプログラムに絞ったものです。複数表から作るビューを以前と同じ方法で更新できるかは別の条件があるため、参照を維持できたことから更新処理の互換性まで断定しません。

索引を追加しても表の意味を保つ例

次は貸出表の構成をそのままにして、会員番号から該当する貸出を探す処理を改善する例です。変更前は貸出表を順に調べていたとして、変更後は会員番号の通常の非一意索引を追加します。同じ会員が複数の本を借りられるので、この索引は会員番号の重複を禁止しません。

貸出表の列、会員と図書の関係、貸出記録の意味、検索条件は変えません。変わるのは該当データへ到達するためのアクセス方法なので、内部スキーマの変更です。概念スキーマを維持できるため、物理的データ独立性を示す例になります。

検索するプログラムが「この会員番号の貸出を返してほしい」と指定していれば、実際に索引を使うかどうかをDBMS側で判断できます。利用側が、データの格納位置を一件ずつ指示する形でなければ、アクセス方法の変更を利用側へ広げずに済みます。

PostgreSQL公式のインデックスの導入説明でも、索引の作成後はシステムが適切と判断した問合せで索引を利用すると説明されています。検索条件のある同じSQLを使いながら、DBMS側で探索方法を選べる例です。索引の詳細を復習するなら、基本情報のインデックスの解説につなげると理解しやすくなります。

注意したいのは、単に「索引」という語があるから物理だけの変更と決めないことです。新たなUNIQUE制約も同時に追加し、それまで許していた重複データを禁止するなら、論理的なデータのルールも変わります。この例では、重複を許す通常索引を追加し、制約を変更しないという条件が判定の根拠です。

また、物理的データ独立性は、実行時間が変わらないことを保証するものではありません。アクセス方法を改善する例なら性能が変わることを期待しています。変更前後で保つのは表やデータの意味、利用側のデータ定義であり、速さ・使用容量・運用中の停止時間まで全部同じという意味ではありません。

変更した層から順番に判断する

問題文を読むときは、最初から「論理か物理か」を当てに行くより、変更対象を分類してから独立性を決める方が安定します。とくに「アプリケーションを修正せずに済んだ」という言葉は両方に登場できるため、それだけを丸暗記しないでください。

• 変更前後で何が違うかを抜き出す。表・列・関係なのか、格納・索引なのか、利用者へ渡すデータなのかを確認する
• 変更対象を外部・概念・内部のいずれかへ分類する。値や画面装飾だけの変更なら、スキーマ変更と分ける
• 維持する側を確認する。利用者側のデータ定義を保つのか、全体の論理構造を保つのかを読む
• 概念から外部を守るなら論理的、内部から概念を守るなら物理的、と境界に名前を付ける

たとえば「受付担当へ表示する列を減らしたが、会員表自体は変更しなかった」という文なら、まず外部側の見え方を変更した例です。外部側の変更が下位へ波及しない説明にはなりますが、概念側の変更から外部側を守った例ではありません。論理的独立性の典型的な定義と、変更の向きが逆です。

「会員表に列を追加したが、受付ビューの提供列は維持した」なら、概念を変更して外部を維持するので論理的独立性です。一方、受付プログラムが実表を直接参照し、列の位置に依存していたなら、追加の影響を受けるかもしれません。問題文が示す維持条件と、実際の設計で維持できる条件を切り離さずに読みます。

独立性の目的をアプリケーション改修の回避まで結び付ける説明は、UC Davisのデータベース入門資料でも確認できます。ただし、仕組みを分けたという理由だけで、意味を変える変更や削除された情報をすべて吸収できるとは考えないようにしましょう。

自作6問で分類と独立性を確認する

以下はこの記事のために作った練習問題です。過去問の転載ではありません。答えを見る前に「変更した対象」「維持した対象」「対応する独立性」の3つを短く書いてみてください。維持条件がない文で、独立性まで無理に決める必要はありません。

自作問題	変更した対象と判断
会員表へ入会日列を追加した。受付ビューの列と結果は維持し、受付プログラムも変更しなかった	概念を変更、外部を維持。論理的データ独立性
貸出表の格納ファイルを再編成した。表定義と利用プログラムは変更しなかった	内部を変更、概念を維持。物理的データ独立性
督促用ビューに、既存の会員表から連絡先列を追加した。実表の構成は変更しなかった	外部の変更。概念側の変更を吸収した例ではない
会員の連絡先の誤字を修正した。列や制約は変更しなかった	データの値の更新。スキーマ変更ではない
会員表から氏名列を削除した。その列が必要な受付プログラムも修正した	概念の変更が利用側へ波及。この変更では論理的独立性を維持できていない
受付画面の氏名を太字で表示した。取得する項目と値は変わらない	表示装飾の変更。外部スキーマのデータ定義の変更とはいえない

第1問と第2問は、どちらも利用プログラムを変更していません。しかし第1問は表の列を変え、第2問は格納ファイルを変えています。この違いから独立性の種類を決めます。共通する結果より、変更した層の違いを先に読む練習です。

第3問は、利用者側へ渡す列を増やした場面です。実表を維持できたという事実はありますが、論理的独立性の定義が中心とする「概念を変えても外部を保つ」という関係を示していません。「画面に関係するから論理」と飛びつくと、変更の向きを読み違えます。

第4問と第6問では、そもそも構造の変更があるかを確認します。返される値が変化したり、文字の見た目が変化したりしても、列や関係が変わるとは限りません。スキーマと値、データの見え方と画面装飾を分けるための反例です。

第5問は、独立性を魔法のように扱わないための問題です。氏名という必要な情報自体を削除し、元と同じ情報を提供する方法もないなら、利用側をそのまま保つことはできません。概念の変更を行ったというだけで論理的独立性が実現したわけではなく、実際に維持した対象があるかを確認します。

間違えた問題は、正解の用語だけを書き直すのではなく、「索引を列の変更と考えた」「値の更新を構造変更と考えた」「守る側と変える側を逆に読んだ」のように原因を一言で残すと、次の演習で確認するポイントを決められます。知識が足りないのか、問題文の比較が足りないのかを分けて復習しましょう。

3層スキーマは変更と維持を対で覚える

基本情報の3層スキーマは、外部が利用者別のデータ定義、概念が全体の論理構造、内部が格納・アクセス方法です。名前を暗記した後は、同じ貸出管理を受付の視点、表全体の視点、記憶装置の視点から説明できるか確認してください。

独立性を判定するときは、概念を変えても外部を保つ関係が論理的、内部を変えても概念を保つ関係が物理的です。表の分割と通常索引の追加を代表例にしつつ、何を維持できたかという条件まで読むことが大切です。

最後に、表の列追加、索引追加、値の修正という3つの文を自分で作り、それぞれの分類と理由を説明してみましょう。変更対象を言葉にできたら、基本情報の過去問アプリで科目Aを演習することで、選択肢の文章でも同じ判断手順を使えるか確かめられます。解説を覚えるだけでなく、変更した層と守る層を自分で示せる状態を目指してください。