1. データベース管理システム

    2. コンピュータ上にデータベースを構築するために必要な運用、管理のためのシステムおよびそのためのソフトウェア。

    1. トランザクション

      2.  トランザクションとはデータベースの更新などを含む一つの作業単位。
      コミットまたはロールバックをもって完結する。

      1. ACID（アシッド）特性

        2.  トランザクションの正当性を担保するためにデータベース管理システムが機能として持たなくてはいけない特性。

        ACID特性
        原子性 Atomicity トランザクションの終了時点ですべての処理が完了しているか、まったく行われていないかのどちらかであること。
        一貫性 Consistency トランザクション処理が終了しているか否かに関わらず、データの関係性に矛盾がないこと。
        独立性
        (隔離性)        		 Independence
        (Isolation)        		 更新途中の複数のトランザクションがお互いに結果に影響を与えないこと。
        耐久性 Durability トランザクションの完了後、障害などによってその内容が変化しないこと。

      2. 並行処理の問題

        3.  データベースは常に複数のトランザクションが発生することが想定される。
        これらのトランザクションが並行処理される場合、後述されるような問題が発生することが考えられる。

        • ロストアップデート

          •  二つのトランザクションがデータを読み込み、更新をかける際に相手の更新内容を取り込めないため、
          更新が喪失してしまう現象。

          ※例
          あるデータで任意の数を加算していく処理をトランザクションで実行する。

          トランザクション
          開始
          読み込み：変数←値
          処理：変数 ＋ 20
          書き込み：値＝変数
          コミット（終了）

          ※※２つのトランザクションが発生し、順次処理された場合。

          トランザクションＡ
          開始
          読み込み：変数←100
          処理：100 ＋ 20
          書き込み：値＝120
          コミット（終了）

          トランザクションＢ
          開始
          読み込み：変数←120
          処理：120 ＋ 20
          書き込み：値＝140
          コミット（終了）

          ※※２つのトランザクションが発生し、並列処理された場合。

          トランザクションＡ
          開始
          読み込み：変数←100
          処理：100 ＋ 20
          書き込み：値＝120
          コミット（終了）
          トランザクションＢ
          開始
          読み込み：変数←100
          処理：100 ＋ 20
          書き込み：値＝120
          コミット（終了）

          …並行処理の場合、トランザクションＡの処理が終了する前にトランザクションＢが実行され、
          　結果、トランザクションＡの更新は喪失してしまう。

        • 整合性制約の侵害

          •  参照整合性制約を無視して他のテーブルのカラムと一致させるカラムを変更してしまうこと。
          同じタプルの別のテーブルと関数従属するカラムを別々のトランザクションで並列処理すると発生しうる。

          ※例
          商品の配送において担当者と配送時間の変更が同時に発生する。

          配送担当
          担当者 シフト
          鈴木 午前
          鈴木 夜間
          佐藤 午前
          佐藤 午後

          配送
          商品 配送希望時間帯 担当者
          本 午前 佐藤

          トランザクションＡ
          配送テーブルの担当者を佐藤から鈴木に変更
          トランザクションＢ
          配送テーブルの配送希望時間帯を午前から午後に変更

          配送
          商品 配送希望時間帯 担当者
          本 午後 鈴木

          …鈴木は午後のシフトがないため配送テーブルと配送担当テーブルに矛盾を生じる。
          　（整合性制約の侵害）

        • コミットの一貫性・隔離性の問題

          •  並行処理するトランザクションが、もう一方の部分的な更新を読み込んでしまうこと。
          トランザクションの隔離性が十分に担保されていない場合に発生する。
          トランザクションが長時間データを占有してしまうと、データ運用に支障をきたすため、
          やむを得ずACID特性の水準を下げる必要がある場合がある。
          このような場合に生じる問題で、後述する同時実行制御で問題の回避に当たる必要がある。

    2. 同時実行制御

      1. 排他制御

        2.  トランザクションにおいて、テーブルやレコードなどに対するアクセスにロックをかけ、
        並行処理のスケジュールを直列的にするものを排他制御と呼ぶ。

      2. ロック粒度とロックの種類

        3.  ロック粒度とはロックをかけるデータリソースをデータベース全体、テーブル、レコードなどの
        どの単位でロックをかけるかを指す。
        ロックの粒度が大きいとロックをかけたトランザクションがロックを開放するまで他のトランザクションは
        データリソースにアクセスできず、待ち時間が発生する。結果、スループット*やターンアラウンドタイム*は低下する。
        一方でロック粒度が小さいと待ち時間は少なくなるが、ロックの管理に必要な処理があるため
        DBMSの オーバーヘッド *は増大する。結果、スループットやターンアラウンドタイムは低下する。
        このためロック粒度はデータベースサーバの性能やどのデータリソースにアクセスするかで
        判断して決めていかなければならない。

        • 物理ロック

          •  ロックの種類の中でも、データベース全体やテーブルなどロック粒度の大きいロックをさす。
          ロック粒度で述べた問題のほか、実際の処理の中では完全にデータリソースをロックするまでにタイムラグが生じ、
          ロック対象のデータリソースに対するロック取得が間に合わないまま、他のトランザクションに更新される問題がある。

          • 専有ロック

            •  物理ロックの中でもデータリソースを完全に専有し、他のトランザクションに対して参照も更新も認めないもの。

          • 共有ロック

            •  更新を認めないが参照は認める物理ロック。共有ロックされたデータリソースは専有ロックできない。

        • 述語ロック

          •  SQLなどを利用することで特定のレコードを指定してロックをかけるもの。ロック粒度は小さくなる。

      3. ２相ロック

        4.  複数のデータリソースに対し、一斉にロックをかけて（第１相目）、データ操作後に一斉にロックを解く（第２相目）ロック方式。デッドロックが発生する可能性がある。 ２相ロック以外のロック方式としてデータリソースを順番にロックしていく規約方式がある。 デッドロックは発生しなくなるが、並列処理性が下がるため、あまり採用されない。

      4. デッドロック

        5.  並列処理下で複数のトランザクションがリソースをロック開放しながら互いに相手のロック解放を待っている状態のこと。
        回避する方法として、ロック時間に制限を設け、一定時間たつとエラーとみなしてロールバックするか、
        他のトランザクションがすでにリソースをロックしていた場合、ロールバックしてリトライするなどのやり方がある。

      5. 一貫性の度合い

        6.  トランザクションのACID特性と並列実効性を担保することは二律背反の関係にあり、
        ２相ロック方式でデットロックを完全に回避することは不可能。
        ACID特性の一つである一貫性を4段階のレベルに分類し、一貫性の度合いを調整することで
        ACID特性を維持しつつもデットロックの発生や待機時間を軽減する。

        • レベル0
          •  トランザクションは更新したデータリソースを直ちに開放する。
          更新するデータリソースに対しては専有ロックをかけ、参照するデータリソースにはロックをかけない。
          更新されたデータリソースはトランザクションの終了を待たずに他のトランザクションの更新を認めるため
          ダーティライト*が発生しうる。

        • レベル1
          •  トランザクションが終了した時点で更新データを開放する。
          更新するデータリソースに対しては専有ロックをかけ、参照するデータリソースにはロックをかけない。
          参照されているデータリソースは他のトランザクションにより更新されている可能性があるため
          ダーティリード*が発生しうる。

        • レベル2
          •  更新データはトランザクションが終了するまでロックするが、参照データはデータリソースを直ちに開放する。
          更新するデータリソースに対しては専有ロックをかけ、参照するデータリソースには共有ロックをかける。
          参照されているデータリソースは参照時に他のトランザクションに更新されていることはないが、
          トランザクション終了までには更新されていることがありうるため
          ノンリピータブルリード*が発生しうる。

        • レベル3
          •  更新データも参照データもトランザクション終了までロックする。
          更新するデータリソースに対しては専有ロックをかけ、参照するデータリソースには共有ロックをかける。
          トランザクションの終了までデータリソースが他のトランザクションに更新されることはない。

      6. 隔離性レベル

        7.  トランザクションの隔離性のレベルを設定することでACID特性を維持しつつもデットロックの発生や待機時間を軽減する。

        • READ UNCOMMITTED
          •  一貫性の度合いレベル1と同じ。

        • READ COMMITTED
          •  更新データはトランザクションが終了するまでロックするが、参照データはデータリソースを直ちに開放する。
          更新するデータリソースに対しては専有ロックをかけ、参照するデータリソースには述語ロックをかける。
          ノンリピータブルリードが発生しうる。
          （一貫性の度合いレベル2と違い参照データは行単位でロックされるため、ノンリピータブルリードの発生率は高まる。）

        • REPEATABLE READ
          •  更新データも参照データもトランザクション終了までロックする。
          更新するデータリソースに対しては専有ロックをかけ、参照するデータリソースには述語ロックをかける。
          参照されているデータリソースは参照時に他のトランザクションに更新・削除されていることはないが、
          述語ロックのため、トランザクション終了前でも追加されていることはありうる。このため、
          ファントムリード*が発生しうる。

        • SERIALIZBLE
          •  一貫性の度合いレベル3と同じ。

    3. 障害

      1. 障害回復のための機能
        • ログ
          •  データベース操作を記録したジャーナルファイル。データベースを物理的に書き換える前のデータベースバッファが用いられる。このため、データベースがコミットされるよりも先にログは更新されている。

        • チェックポイント
          •  あらかじめ定められたタイミングでチェックポイントを設定することにより、障害回復時にどの時点までリカバリするかの目安とする。

        • バックアップコピー
          •  データベースのデータリソースの内容をコピーした全体バックアップと、ログが満杯になるたびに別途保存した差分バックアップ（アーカイブログ）がある。全体バックアップはバックアップの取得にはシステムに負荷がかかるが、回復時にはあまり負荷がかからない。これに対し差分バックアップはバックアップの取得時にはシステムの負荷はかからないが、回復時には負荷がかかる。

      2. 障害の種類と回復
        • トランザクション障害
          •  トランザクションがアボートすること。デッドロックやタイムアウト、その他のプログラムエラーなどで生じる障害。
          トランザクションを呼び出したプログラムでDBMSに対しロールバック（後退復帰）*を要求することで回復を図る。
          回復後は障害の原因を取り除いた上でリトライする。

        • システム障害
          •  オペレーティングシステムやネットワークなどの障害によりシステムが停止すること。あらかじめシステムを二重化（冗長化）しておき、主系から従系への切り替え処理を実施する。主系の復帰後は従系と主系で同期をとり、従系が稼動していた間の差分を回復する。

        • ハードウェア障害
          •  DBMSの実装されたコンピュータやハードディスクがクラッシュすること。あらかじめバックアップコピーを採取しておき、これを用いてシステムを回復する。バックアップ採取時と障害発生時の差分に関してはDBMSのロールフォワード（前進復帰）*を用いて回復を図る。

        • ヒューマン障害
          •  誤操作によるデータリソースの喪失など。ハードウェア障害と同じくバックアップデータを用いて対応する。

        • セキュリティ障害
          •  意図的な情報漏えい、SQLインジェクションなどによる盗聴、改ざん、成りすましなど。
          データの暗号化などで対応する。

    4. セキュリティ


      5.  DBMSにはロール(権限)の制御機能が備わっており、アクセスするユーザーによりデータリソースの参照、更新、削除などの制限を設けることができる。

    5. インテグリティ管理

      1. 一意性制約
        2.  テーブル内においてタプルが一意のものとして認識されるための制約条件。

      2. 参照制約
        3.  他のテーブルに主キーの一致するタプルが存在することを保証するための制約条件。

      3. 検査制約
        4.  テーブル定義時に前提となる探索条件を設けて、テーブル内のタプルがこれと一致することを担保するための制約条件。

    6. ストアドプロシージャ

      7.  DBMSにおけるリモートプロシージャコール*の実装。
      これを利用することにより、DBMSのクライアントはデータ操作をプログラムしなくてもあらかじめコーディングされたストアドプロシージャを実行することでデータ操作が可能になる。 ストアドプロシージャを利用することの利点には以下のようなものがあげられる。

      • 複数のSQLを一つのプログラムで実行する場合DBMSとのI/Oは複数回となるが、ストアドはDBMSサーバで実行されるため通信にかかるオーバヘッドが軽減される。

      • 同じデータ操作を各プログラムごとにコーディングする必要がなくなるため、開発コストを低減する。

      • データ操作処理を直接クライアントにさせないことにより、障害リスクを低減する。

       ストアドプロシージャは上記のリモートプロシージャコールのほかに、ストアドトリガを用いてあらかじめ定められたタイミングや条件で、実行されろことも可能である。

    7. データディクショナリ

      8.  システムカタログとも呼ばれる、３層スキーマアーキテクチャの実装。
      データ定義情報（メタデータ）を保持し、これによりテーブル名、カラム名などの名前解決や各リソースの定義情報を格納する。