関係データベースの基本とスキーマ

結論：関係データベースは「データを2次元の表で持つ」

関係データベース（RDB）は、データを行と列からなる2次元の表で表すデータベースです。管理するソフトは RDBMS（関係データベース管理システム。MySQL や PostgreSQL など）と呼びます。

試験では「関係データベースの説明はどれか」と聞いて、ほかのデータモデルの説明を選択肢に並べます。次の表のキーワードで見分けてください。

ポインタは「次のデータの置き場所を指す矢印」、カプセル化は「データとそれを扱う処理をひとまとめにすること」です。この4択の組み合わせは2011年度・2013年度でほぼ同じ形で出ています。

理論（関係モデル）と実装（関係データベース）の用語対応

関係データベースのもとになった理論を関係モデルといいます。理論側と実装側で呼び名が違うだけで、指しているものは対応しています。

順序と重複のルールは次のとおりです。理論と実装で差が出るのは「行の重複」だけと覚えてください。

たとえるなら、名簿の列を「氏名・住所」から「住所・氏名」に並べ替えても、名簿の中身は同じです。これが2016年度の問題の答えの筋道で、「関係は表に対応する」が正解。「列は左から右に順序付けられる」は順序に意味がないので誤り、「行も重複しない」は実装では重複し得るので誤り、「定義域は文字型に対応」は数値なども含むので誤りです。

属性の性質：順序に意味なし・名前は必須で重複不可

関係モデルの属性は名前で区別します。だから並び順を入れ替えても同じ関係です（2019年度の正解）。

• 同じ関係の中で、二つの属性に同じ名前は付けられない（名前で区別できなくなる）
• 名前のない属性は作れない
• 二つの属性が同じ定義域を使うのは問題ない（例：「出発日」と「到着日」はどちらも日付の集合）

定義域（ドメイン）：属性が取り得る値の集合

定義域（ドメイン）は、ある属性が取り得る値の集合です。たとえば「血液型」の定義域は {A, B, O, AB} です。

選択肢では、タプル（＝行）、関係（＝表全体）、実現値（＝実際に入っている値）、ビュー（＝演算で導出した表）などの説明と入れ替えてきます。「取り得る値の集合」とあれば定義域です。

スキーマ：データ定義の集合（＝データベースの設計図）

スキーマは、データの性質・形式・他のデータとの関連などを定めたデータ定義の集合です。API 設計でいう「リクエストやレスポンスの型定義」に近く、中身のデータそのものではなく入れ物の決まりごとです。

「スキーマの説明はどれか」では、ほかの用語の説明が並びます。2014年度と免除試験でまったく同じ4択が出ています。

3層スキーマ：外部・概念・内部に分けて、変更の影響を止める

3層スキーマアーキテクチャは、スキーマを3つの層に分ける考え方です。目的はデータ独立性、つまりある層を変えてもほかの層（特にアプリケーション）に影響が及ばないようにすることです。

たとえば内部スキーマで「データの置き場所」を変えても、概念スキーマが同じならアプリはそのまま動きます。これを物理データ独立性といい、2015年度の正解「格納構造を変更してもアプリケーションに影響が及ばないようにする」がこれです。

flowchart TB
  A["アプリ・利用者"] --> E["外部スキーマ（見え方）"]
  E --> C["概念スキーマ（論理構造）"]
  C --> I["内部スキーマ（物理的な格納）"]

ひっかけ：概念スキーマを「物理的」、内部スキーマを「論理的」と役割を入れ替えた選択肢が出ます。また3層スキーマに**「物理スキーマ」という層はありません**（物理的な格納を表すのは内部スキーマ）。

DBMS の機能と、データディクショナリ

DBMS（データベース管理システム）の機能は大きく3つです。

「スキーマを決める機能はどれか」は免除試験と本試験（2015年度）で同じ4択が繰り返し出ており、答えは必ず定義機能です。機密保護・障害回復・保全はどれも名前がもっともらしいですが、制御機能の仲間です。

データディクショナリは、DBMS が管理するデータ・利用者・プログラムなどの定義情報と、それらの関係を保持するデータの集合体です。データについてのデータ（メタデータ）の辞書、と覚えます。

データベース管理者（DBA）の職務

データベース管理者（DBA）は、データベースの設計・保守・運用の監視・障害からの回復を担当します。選択肢には、アプリの作成（アプリ開発者）、受入検査（発注側の検査担当）、要員と資源の配置（プロジェクトマネージャ）といった別の役割の仕事が混ざります。