データベースのモデルと方式

要点と定義

データベースの種類は、データの表し方やレコード間の関連付け方によって特徴が異なります。関係モデルでは、データを表として表現し、表は行に当たるタプルと列に当たる属性で構成します。複数の表は、共通する値などを使って関係付けます。

データモデルは、データベースの論理的な構造を表す方法です。プロパティグラフでは、頂点が対象を、辺が二つの頂点間の関連を表します。プロパティは頂点または辺に所属し、一つのプロパティが両方に同時に所属するものとして扱いません。辺が何を結び付け、属性がどの対象に付くかを確認すると、モデルを正しく読めます。

データベースの3層スキーマでは、利用者やプログラムごとの見え方を外部スキーマ、データ全体の論理構造を概念スキーマ、保存時の物理構造を内部スキーマとして区別します。この区別は、利用者向けの定義とデータ全体の構造、保存方法を分けて考える基礎です。

適用条件と例

データの形や関連付け方に応じて、データベースの種類を選びます。キーに値を対応させて扱うキーバリュー型、頂点と辺で関係を表すグラフ型などがあります。どの種類が適するかは要件によります。キーと値の対応を特徴とする方式は、他の種類との違いを見分ける手掛かりになります。これは過去の出題で扱った補足です。

過去の出題で扱った補足として、ハッシュ方式ではデータ項目の値を関数に入力し、その結果に従って格納場所を決めます。値から格納場所を決定するという原理を押さえます。

過去の出題で扱った補足として、CAPの三要素は整合性、可用性、分断耐性です。ネットワーク分断が起きた場合、整合性を保つために応答を制限するか、可用性を優先して一時的な不一致を許すかという選択が生じます。分断時に三つを同時に保証できない、という判断に結び付きます。二台構成の設問では、一方のサーバを止めて整合性を保つ場合と、両方を動かして可用性を保つ場合が扱われました。これはその構成での判断例であり、物理的な停止が常に必要という意味ではありません。

過去の出題で扱った補足として、結果整合性は、更新が各ノードへ直ちに反映されることを意味しません。更新が伝播し、新たな更新が止まり、障害なく伝播が続く条件では、各ノードが最終的に同じ状態へ収束します。いつでも即時に一致することや、条件にかかわらず収束することとは区別します。

例えば、受付担当者には予約者名と受付状況だけを見せる定義に変更し、データ全体の論理構造と保存方法は維持する場合、変更するのは外部スキーマです。概念スキーマはデータ全体の論理構造、内部スキーマは物理構造を表します。