データベース方式
このノートの問いがそのまま復習カードになり、忘れかけたころに出題されます。
シラバス案 Ver.0.1 の小分類 4-17-1「データベース方式」（大分類 4：デジタル技術／中分類 17：データベース）。
2026-09-26 にシラバス本文と突合済み。
0. 何を押さえるか
シラバスがこの中分類で問うのは、日々扱うデータの整合性と一貫性を、システムがどう守っているかです。
その土台が「データを表の形で持ち、専用のソフトウェアに管理させる」という考え方です。
言葉が 3 段に重なっているので、まず位置関係を固定します。
| 用語 | 何か | 例え |
|---|---|---|
| 関係モデル | データを表（関係）として捉える考え方・理論 | 設計図の書き方 |
| 関係（リレーション） | 関係モデルでいう表そのもの | 1 枚の表 |
| RDBMS | 関係モデルに従ってデータを管理するソフトウェア | 表を預かる管理人 |
取り違えやすい分かれ目は 2 つです。
- 「関係（リレーション）」は表のことで、表と表のつながりのことではありません
（つながりは E-R 図の「リレーションシップ」。→ データベース設計）。 - RDBMS は「データベースそのもの」ではなく管理ソフトです。データを直接ファイルで持つ代わりに、
RDBMS を通して読み書きすることで、同時利用や障害時にも矛盾が出ないようにします。
1. なぜデータベースを使うか
根拠: シラバス 4-17-1
業務のデータを部署ごとのファイルで持たず、データベースで一元管理するのはなぜか？
同じデータを何か所にも持つと、食い違いが生まれるから。
| ファイルで個別に持つ | データベースで一元管理 | |
|---|---|---|
| 同じデータ | 部署ごとに重複して持つ | 1 か所に持つ |
| 住所変更 | 全部のファイルを直す必要（直し漏れ＝矛盾） | 1 か所直せば全員に反映 |
| 同時利用 | 上書きし合う危険 | 管理ソフトが調整する |
データの整合性（矛盾がない）と一貫性（どこから見ても同じ）を保つのが目的。
RDBMS とは？ 主に何をしてくれるか？
RDBMS（Relational DataBase Management System）＝ 関係データベース管理システム。
データを表の形で管理するソフトウェア。
| 機能 | 中身 |
|---|---|
| 同時実行の制御 | 複数の人が同時に更新しても矛盾させない |
| 障害からの回復 | 故障や停電のあとでも正しい状態に戻す |
| 機密保護 | 権限のない人に見せない・変えさせない |
| 整合性の維持 | 重複や、ありえない値の登録を防ぐ |
利用者やアプリケーションは RDBMS に「何がほしいか」を頼むだけで、
データがディスクのどこにどう置かれているかを知らなくてよい。
2. 関係モデル
根拠: シラバス 4-17-1
関係モデルとは？
データを「表（関係）」の集まりとして表す考え方
- 1 件のデータは表の 1 行
- データの項目は表の 1 列
- 表と表は、共通する項目の値でつながる（ポインタのような「線」は持たない）
この考え方に基づくデータベースを関係データベース（リレーショナルデータベース）、
それを管理するソフトを RDBMS という。
関係モデルでいう「関係（リレーション）」とは何のことか？
表そのもののこと。
| 関係モデルの言い方 | ふだんの言い方 |
|---|---|
| 関係（リレーション） | 表（テーブル） |
| タプル（組） | 行（レコード） |
| 属性 | 列（フィールド・項目） |
「表と表の関係」の意味ではない点に注意。
表どうしのつながりは、設計の段階でリレーションシップと呼ぶ。
関係モデルでデータを表として持つと、何がよいか？
表という単純な形にそろえておけば、どんな取り出し方にも同じ操作で応えられる。
- 「東京の顧客だけ」「氏名だけ」「注文と顧客を合わせて」——
どれも選択・射影・結合の組み合わせで表せる（→ データ操作） - 取り出し方を後から変えても、データの持ち方を作り直さなくてよい
問い合わせには、SQL という RDBMS 共通の言語を使う。
RDBMS は、おかしなデータが登録されるのをどうやって防いでいるか？
表を作るときに列ごとの決まり（制約）を定義しておき、登録・更新のたびに RDBMS が自動で確かめる。
| 決まりの例 | 防げること |
|---|---|
| 列のデータ型（数値・日付など） | 金額の欄に文字が入る |
| 空を許さない（NOT NULL） | 必須の項目の入れ忘れ |
| 主キー | 同じ番号の行の二重登録 |
| 外部キー（参照整合性） | 存在しない顧客番号の注文 |
アプリケーションごとに確認を作り込まなくても、データベースの側で整合性が守られる。
3. 関係データベース以外の方式
根拠: シラバス 4-17-1
RDBMS と NoSQL の違いは？
| データの持ち方 | 得意なこと | |
|---|---|---|
| RDBMS | 決まった列を持つ表 | 整合性の維持、複雑な条件での検索・集計 |
| NoSQL | 表に縛られない形（キーと値の組、文書、グラフなど） | 大量・多様なデータ、規模の拡大 |
NoSQL は「SQL を使わない」ではなく「関係モデルに限らない（Not only SQL）」という意味。
形の定まらないデータを大量に扱う場面で使われるが、整合性の保証は RDBMS より緩いことが多い。
関係データベースが向いている業務と、向きにくいデータの例は？
| 向いている | 向きにくい |
|---|---|
| 受発注・在庫・会計・顧客管理など、項目が決まっていて、正確さが最優先のデータ | SNS の投稿、センサーの記録、形の揃わないログなど、項目がまちまちで量が膨大なデータ |
お金や在庫は1 件でも矛盾すると困るので、整合性に強い RDBMS が今も中心。