データベース方式
要点と定義
データベース方式を選ぶときは、データの形、データ同士の関連付け方、利用者やプログラムに見せる範囲を要件に合わせます。現行シラバスは、データベースの種類と特徴、データモデル、三層スキーマ、DBMSの目的・機能を学習範囲としています。RDBのほか、階層型、網型、ドキュメント指向、列指向、グラフ、キーバリュー型などがあり、NoSQL全体を一つのデータモデルとして扱わず、個々の構造を見分けます。
キーバリュー型は、キーに値を対応付けて管理する方式です。値の形式は一様とは限らず、この分類はNoSQLに含まれる方式の一つです。方式の識別が問われた過去の出題では、キーと値の組で管理する構造が判断の根拠でした。
三層スキーマでは、外部スキーマが利用者やプログラムごとの見方、概念スキーマがデータベース全体の論理構造、内部スキーマが物理的な格納構造を表します。役割を分けることで、利用者の見方や論理構造と物理構造を区別します。三層の対応を正しく使うことが問われた過去の出題では、この役割の違いが正答判断に必要でした。
関係モデルでは、関係を表(リレーション)、タプルを行、属性を列として表します。関係スキーマは列などの構造を定め、実現値はその関係に含まれる行の集合です。データ構造や関連付け方は、要件に応じてモデルで表現します。
親子関係を親コードと子コードの組として複数行に記録する設計では、データの表現だけで循環が自動的に排除されるとは限りません。循環禁止が要件なら、その条件を別途制約として課す必要があります。循環を防ぐ制約の要否が問われた過去の出題では、親子行の表現と制約の有無を分けて考えることが判断の要点でした。
DBMSは、データベースの定義・操作・制御、保全、機密保護などを担います。複数のトランザクションが同じデータにアクセスするときの同時実行制御や、障害時の回復も学習範囲です。実際の設計・運用では、共有するデータの整合性や保護、障害からの復旧を支える機能として捉えます。
適用条件と例
B木では、各ノードに格納できるレコード数と子ノード数の上限から、段ごとの最大数を求めます。次数を表す k が2、段数 n が3の場合、各ノードの最大レコード数は4、子の最大数は5です。段ごとのノード数は1、5、25なので、最大レコード数は 4×(1+5+25)=124 です。一般には各段のノード数が 1, (2k+1), …, (2k+1)^(n−1) となり、各段に最大2kレコードを置くため、合計は (2k+1)^n−1 です。根の子の数と、各ノードに格納するレコード数を分けて数えます。この最大格納数の計算が問われた過去の出題では、各段の倍率とノード当たりのレコード数を正しく組み合わせる必要がありました。
B+木のインデックスで1件を検索する場合は、根から該当する葉までノードをたどります。分岐数を一定とみなせるとき、木の高さとノードへのアクセス回数はデータ総件数 X に対して O(log X) です。全行を順に見る線形探索とは異なります。1件検索のアクセス回数が問われた過去の出題では、この高さに基づく対数オーダが判断の根拠でした。
分散データベースの透過性は、分散の仕方を利用者に意識させずに使える性質です。特に移動に対する透過性は、表の格納サイトが変わっても、その配置変更を意識させないことを指します。分散配置、複製、分割を隠す性質とは区別します。格納サイトの変更を隠す機能が問われた過去の出題では、移動の対象と隠される変更を特定することが必要でした。
分散型データベースについて、過去の出題では、一貫性・可用性・分断耐性の三特性を同時に最大二つまでしか満たせないとするCAP定理の前提が扱われました。この説明は出題上の前提として押さえ、個々の実装が無条件に特性を保証すると一般化しないようにします。
この節の続き
- 誤りやすい点
ここまでが冒頭部分です。ログインすると、無料でも1日2節まで全文をお読みいただけます。
アプリでこの節を読む