1.1DBMSの役割とアーキテクチャ

データベーススペシャリストの午前IIでは、単に「DBMSとはデータを管理するソフトウェアである」という定義暗記ではなく、業務システムで障害や高負荷が起きたときにDBMSがどこまで保証してくれるのか、そのために設計者は何を選択すべきかが問われます。ファイルシステムで単純にデータを扱う場合と比べ、DBMSは複数ユーザーの同時アクセス・突然の電源断・アプリケーションのバグといった現実の脅威に対して、一貫性を保ったままデータを守る仕組みを提供します。この節では、DBMSが担う役割を機能単位で切り分け、それぞれが具体的に何を防ぎ、何を防がないかを理解します。

1.1.1DBMSの5つの役割

• DBMS（データベース管理システム）＝データの定義・格納・操作・保護を一元的に担うソフトウェア基盤。ファイルシステムを直接扱う自作プログラムでは実装が難しい同時実行制御・障害回復・アクセス制御を標準機能として提供する。
• 5つの主要な役割＝
  ①データ定義（DDL）：表・制約・索引などのスキーマを定義、
  ②データ操作（DML）：SQLによる検索/更新、
  ③同時実行制御：複数トランザクションが同時に実行されても矛盾が生じないよう調停、
  ④障害回復：システム障害・媒体障害後もデータを一貫した状態に戻す、
  ⑤データ独立性：物理的な格納方式やアプリケーションの変更が互いに影響しないようにする。

1.1.2ACID特性という約束の中身

• DBMSがトランザクションに対して保証する性質をACID特性と呼ぶ＝原子性（Atomicity）：トランザクションは全実行か全取消のいずれか、一貫性（Consistency）：制約を満たした状態間のみを遷移、隔離性（Isolation）：同時実行するトランザクション同士が互いに干渉しない、耐久性（Durability）：コミット済みの結果は障害後も失われない。
• ACIDはトランザクション単位の保証であり、アプリケーションが誤ったビジネスロジックでコミットした更新まで「正しい」と保証するものではない。例えば口座残高をマイナスにする更新でも、アプリ側の制約チェックが無ければDBMSの整合性制約に反しない限りコミットは成功してしまう。

あなたはECサイトの在庫管理システムを担当するDBAで、深夜バッチ処理中に瞬間的な停電が発生し、サーバが再起動したという報告を受けました。まず確認すべきは「耐久性（Durability）が守られたか」＝停電直前にコミット済みだった注文確定処理の結果がディスクに残っているかどうかです。DBMSは通常、WAL（ログ先書き）の仕組みでコミット時にログを永続化してから応答を返すため、コミット済みトランザクションの結果は失われません。次に問題になるのは「停電時点でコミットされていなかった、進行中のトランザクション」の扱いです。ここで「進行中だった処理も可能な限り完了させてから再起動する方がデータを活かせる」と考えるのは誤りです。原子性（Atomicity）の原則に従い、DBMSは未コミットのトランザクションをロールバックし、その更新の痕跡を完全に取り消して再起動後の一貫性を保ちます（中途半端に一部の更新だけ残ることは許されない）。もう一つ検討すべきは、この障害が「同時に複数の在庫更新トランザクションが競合していた」ケースと混同しないことです。同時実行制御（隔離性）が扱うのはあくまで複数トランザクションの干渉防止であり、単一トランザクション中の電源断からの回復は障害回復（原子性・耐久性）の管轄です。役割ごとに保証範囲を切り分けて考えることが、誤った復旧手順（例えば手動で仕掛中データを補完しようとする）を避ける鍵になります。

1.1.3この節のまとめ

• DBMSはデータ定義・データ操作・同時実行制御・障害回復・データ独立性の5つの役割を統合的に担う
• ACID特性（原子性/一貫性/隔離性/耐久性）はトランザクション単位の技術的整合性の保証であり、アプリ側のビジネスロジックの正しさまでは保証しない
• 電源断など障害からの回復は原子性（未コミットのロールバック）と耐久性（コミット済みの保持）が管轄し、同時実行制御（隔離性）とは役割が異なる