データベース入門です。データベースも参照のこと。
「徹底攻略 応用情報技術者教科書 平成30年度」と「平成18年度 イメージ&クレバー方式でよくわかる栢木先生の基本情報技術者教室 (情報処理技術者試験)」と「真図解 基本情報技術者 2006年春―初歩から学べて合格できる」と放送大学「情報学へのとびら ('16)」を参考にしています。
スキーマとは、データベースの仕様のこと。
そのデータベースがどのような設計（データ列と行、構造、関連性）で構築されているかを「スキーマ」と呼ぶ。
3層スキーマ構造では、「外部スキーマ」「概念スキーマ」「内部スキーマ」の3層のスキーマが存在する。
| スキーマ | 説明 |
|---|---|
| 外部スキーマ | ユーザーがプログラムを通じてアクセスするためのスキーマ |
| 内部スキーマ | データベース管理システムの中で、物理的に保管されるデータベースのスキーマ |
| 概念スキーマ | 外部スキーマと内部スキーマの間にあって、 データベース管理者が設計するデータモデル（概念）としてのスキーマ |
（「真図解 基本情報技術者 2006年春―初歩から学べて合格できる」を参考に執筆しました。）
主キーとは、IDのように行を一位に特定できるカラムのことで、一意制約（同じ値を許容しない）やオートインクリメント（自動的に加算）ができる。
外部キーは、テーブルを結合するために別のテーブルの主キーを含めたカラムのこと。参照制約によって外部キーと主キーの間で不一致が起きないようにすることができる。
主キーと外部キーを使うことで、表と表を自由に結合できる。これを「リレーション」と呼ぶ。
（「平成18年度 イメージ&クレバー方式でよくわかる栢木先生の基本情報技術者教室 (情報処理技術者試験)」と放送大学「情報学へのとびら ('16)」を参考に執筆しました。）
表から新しい表を作り出す操作を関係演算と呼ぶ。
| 演算 | 説明 |
|---|---|
| 射影 | 列を取り出すこと |
| 選択 | 行を取り出すこと |
| 結合 | 表を結合すること |
リレーションも参照のこと。
（「平成18年度 イメージ&クレバー方式でよくわかる栢木先生の基本情報技術者教室 (情報処理技術者試験)」を参考に執筆しました。）
テーブルを変更する際に制約をかけることができる。
| 制約 | 説明 |
|---|---|
| 参照制約 | 外部キーの参照整合性が保持される |
| 一意性制約 | 同じカラムに同じ値を複数設定することを許さない |
| 非ナル制約 | NULL値の設定を許さない |
| 主キー制約 | 一意性制約と非ナル制約を組み合わせたもの 主キーに設定される |
| ドメイン制約 | データの値それぞれに制約をかける |
| 検査制約 | ドメイン制約のうち、データ範囲などを制限する |
（「徹底攻略 応用情報技術者教科書 平成30年度」を参考に執筆しました。）
「何かしらの値に対して何かしらの値が決まる」という関数のような従属性を関数従属と呼ぶ。
候補キーとは、「すべての属性を一意に特定する属性あるいは属性の組で最小のもの」。
候補キーは組や行、タプルなどを識別することのできるキーであり、たとえば(ID, 名前, 性別, 住所, 電話番号, 職業, 給料)などがあればIDと住所と電話番号が候補キー。
非キー属性はキーとはならない属性のこと。
後日注記：属性の組で最小のもの、という意味がどういうことかというと、たとえば市町村を表す(ID, 市町村名, 都道府県名, 人口, 面積)のようなタプルがあったとして、IDでも市町村を特定できるが、市町村名と都道府県名の組み合わせでも市町村を特定できる（市町村名だけでは若干の重複がある）。このため、候補キーはIDあるいは{市町村名, 都道府県名}となる。
（「徹底攻略 応用情報技術者教科書 平成30年度」を参考に執筆しました。）
データベースは、データの重複や矛盾を排除するために「正規化」を行って、「正しい規則のもとにテーブルを保持する」ことができる。
非正規形は、何も正規化されていない表のこと。これを、繰り返し項目の排除（第1正規形）、主キーの一部にしか関数従属しないようなテーブルを分割する（第2正規形）、主キーのほかに主従関係がある項目のテーブルを分割する（第3正規形）ことができる。
しかしながら、実際の正規化を行うには、難しい概念を理解する必要があり、このように生易しいものではない。
基本的に、以下のような考え方に基づいてテーブルを分割し、テーブルから冗長な重複項目を排除する。
| 正規形 | 説明 |
|---|---|
| 非正規形 | 何も正規化されていない状態 |
| 第1正規形 | ドメインがシンプルであることが条件。 データベースの1つの場所の中に、データが1つだけ入っているようにする。 |
| 第2正規形 | 完全関数従属していることが条件。 すべての候補キーにすべての非キー属性が関数従属しているようにする（完全関数従属）。 |
| 第3正規形 | 推移的関数従属していないことが条件。 推移的関数従属とはAからB、BからC、Cから…といったように推移的に関数従属されること。 主キーのほかに主従関係がある項目を分割する。 |
詳細を理解したい方は「徹底攻略 応用情報技術者教科書 平成30年度」に記述されている。
後日注記：基本的に、何度もそのまま同じ項目が繰り返されているのを非正規形、繰り返し項目だけを別のテーブルにしたものを第1正規形、特定のどれかの候補キーにしか関数従属していない属性をテーブルを分割して別のテーブルにし、関数従属が部分的に繰り返されないようにしたものを第2正規形、何かの項目が別の何かの項目に主従関係を持って関数従属している部分をすべて個別のテーブルにしたものを第3正規形だと思えばいい。
（「平成18年度 イメージ&クレバー方式でよくわかる栢木先生の基本情報技術者教室 (情報処理技術者試験)」と「徹底攻略 応用情報技術者教科書 平成30年度」と「真図解 基本情報技術者 2006年春―初歩から学べて合格できる」を参考に執筆しました。）
2023.01.23編集
（「真図解 基本情報技術者 2006年春―初歩から学べて合格できる」を参考に執筆しました。）
第1正規形では、繰り返し項目を排除する。
| 番号 | 日付 | 店コード | 店名 |
|---|---|---|---|
| 42 | 8/14 | SHIBUYA01 | 渋谷店 |
| 番号 | 料理名 | 価格 | 数 |
|---|---|---|---|
| 42 | とんこつラーメン | 700円 | 2 |
第2正規形では、部分的な従属関係を排除する。
| 番号 | 日付 | 店コード | 店名 |
|---|---|---|---|
| 42 | 8/14 | SHIBUYA01 | 渋谷店 |
| 番号 | 料理名 | 数 |
|---|---|---|
| 42 | とんこつラーメン | 2 |
| 料理名 | 価格 |
|---|---|
| とんこつラーメン | 700円 |
第3正規形では、推移的な従属関係を排除する。
| 番号 | 日付 | 店コード |
|---|---|---|
| 42 | 8/14 | SHIBUYA01 |
| 店コード | 店名 |
|---|---|
| SHIBUYA01 | 渋谷店 |
| 番号 | 料理名 | 数 |
|---|---|---|
| 42 | とんこつラーメン | 2 |
| 料理名 | 価格 |
|---|---|
| とんこつラーメン | 700円 |
2023.08.14
2024.05.26編集
E-R図 （Entity-Relationship Diagram）は、エンティティ（実体）とリレーションシップ（関連）の関係性を表現した図。
リレーションシップにおける対応関係（カーディナリティ）には以下の4種類がある。
| リレーションシップ | 説明 |
|---|---|
| 1対1 | 何かに対して何か |
| 1対多 | 何かに対してたくさん |
| 多対1 | たくさんに対して何か |
| 多対多 | たくさんに対してたくさん |
1対多のリレーションシップでは、「1」の側における主キーと、「多」の側における外部キーが一致・適合する。
E-R図をUMLのクラス図にして表すこともある。オブジェクト指向モデリングも参照のこと。
後日注記：たとえば2ちゃんねるのようにひとつのスレッドにたくさんのレスがついたり、ブログのコメント欄のように記事にたくさんのコメントがついたりする場合、1対多のリレーションがある。このような場合、SQLでは分離したテーブルを外部キーで関連付けてJOINで結合するが、Railsではhas_many（たくさんの子供を持つ）やbelongs_to（ひとつに属する）を用いてテーブル間のリレーションを表すことができる。Ruby on Railsも参照のこと。
後日注記：E-R図の表記にはさまざまな形態のものがあるが、一例として、実体を四角形、関連をひし形、属性を楕円形で表現し、それぞれの間を実線で結び、1対多の関係なら1 : n、多対多の関係ならm : nのように表記する。
（「徹底攻略 応用情報技術者教科書 平成30年度」と放送大学「情報学へのとびら ('16)」を参考に執筆しました。）
2023.03.26編集
インデックスは、データを高速に検索することのできる「索引」。
インデックスがあると、大量にあるデータの検索速度は速くなる。その代わり、データが変更されるたびにインデックスも更新されるため、データの更新頻度が高い時には更新速度が遅くなる。
インデックスのデータ構造として、Bツリー、B*ツリー（Bツリーの派生形）、ビットマップが用いられることが多い。
データベースインデックスも参照のこと。
（「平成18年度 イメージ&クレバー方式でよくわかる栢木先生の基本情報技術者教室 (情報処理技術者試験)」と「徹底攻略 応用情報技術者教科書 平成30年度」を参考に執筆しました。）
データベースの世界では、データベースのひとつにまとまった複数の処理を示すために、トランザクションという用語を多用する。
トランザクションは、ひとつの流れで、途中で終わらずに最後まで完了（コミット）するか、あるいはそのトランザクションが処理される前に戻す（ロールバック）のどちらかでなければならないような不可分の処理のことを言う。
たとえば、誰かの口座から別の人の口座に振り込みを行うような場合、この一連の流れが途中で終わってしまってはいけない。片方だけ処理され（誰かの残高が減る）、片方だけが処理されない（別の人の残高が増えない）となっては絶対にいけない。
（「徹底攻略 応用情報技術者教科書 平成30年度」を参考に執筆しました。）
トランザクションには、ACID特性という、守らなければならない原則がある。それは、
| 特性 | 説明 |
|---|---|
| 原子性 | 必ず、コミットあるいはロールバックのどちらかの状態になる |
| 一貫性 | コミットが行われる前と、コミットが行われた後で、整合性が保たれる |
| 独立性 | データをなんらかのトランザクションが処理している際に、別のトランザクションでそのデータを処理しない |
| 耐久性 | コミットが完了したデータベースは、障害時にも復旧できる |
（「徹底攻略 応用情報技術者教科書 平成30年度」を参考に執筆しました。）
データベースでは、同じデータに複数のプログラムが同時にアクセスすることがある。この時、排他制御（ロック）をかけないとデータが破損してしまう。
共有ロックは、参照だけを許す代わり、変更は許さないロック。あるトランザクションがデータを参照している状況で、別のトランザクションによってそのデータが変更されないためにかける。
専有ロックは、変更だけではなく参照も許さないロック。あるトランザクションがデータを変更している状況で、別のトランザクションによって異なる時点でのそのデータが参照されないためにかける。
ロックをかける際、頻繁にかけたり外したりを繰り返すのではなく、かけるべき時はずっとかけ続け、外すべき時はずっと外し続けることでデータの矛盾が起きづらくなる。これを「2相ロック」と呼ぶ。
並列処理も参照のこと。
（「徹底攻略 応用情報技術者教科書 平成30年度」を参考に執筆しました。）
データベースのバックアップには、「全体バックアップ」と「差分バックアップ」の二種類がある。
全体バックアップでは、データベースやファイル全体のバックアップを行う。定期的に、毎日・毎週・毎月に一度のような単位で行う。
差分バックアップでは、データベースの変更が逐次的に記述された「ジャーナルファイル」（ログファイルとも呼ばれる）を用いて、差分を含めた最新の状態を復元する。
データベースが破損したりデータが失われた時、データベースを復旧するためには、まず全体バックアップの状態の時点に復旧し、ジャーナルファイルを用いて差分バックアップを復旧させる。この方法を「ロールフォワード」と呼ぶ。
また、データベースのコミット時にシステムが異常終了するなどした場合は、それ以前の状態（コミット前の状態）に復元する。これを「ロールバック」と呼ぶ。
（「平成18年度 イメージ&クレバー方式でよくわかる栢木先生の基本情報技術者教室 (情報処理技術者試験)」を参考に執筆しました。）
データベースでは、セキュリティも重要。利用者認証や暗号化のほか、アカウントにユーザーだけではなくロール（役割）を設定し、ロールごとにアクセスを制御することができる。
セキュリティも参照のこと。
（「徹底攻略 応用情報技術者教科書 平成30年度」を参考に執筆しました。）
分散データベースは、さまざまな場所に分散したデータベースをひとつのデータベースとして扱うことのできるデータベースのこと。
ネットワーク上のさまざまな場所にデータベースが点在・分散し、ひとつのデータベース管理システムがこれらのデータベースを管理し、全体がひとつのデータベースであるかのようにアクセスすることができる。
ひとつに障害が起きてもそれ以外に影響を与えないため、耐障害性の向上になる。また、それぞれのデータベースに負荷も分散し、アクセス速度も向上が期待できる。
2023.05.12
僕も全然詳しくありませんが、データベースはクラスタ化して、大規模化します。
すなわち、CPUがひとつだけの小さなサーバーでデータベースを使うということは、大規模でスケーラブルなシステムによってはない場合があります。
Oracle DBであっても、MySQLのようなOSSデータベースであっても、クラスタやデータセンターで使われる場合を想定して、大規模なシステムで運用するための方法を学ばなければいけません。
また、僕が思うのは、ネットワークやインターネットがデータベースにおいて重要だということです。
僕も全然分かりませんが、MySQLのようなデータベースサーバーを使う場合であっても、ネットワーク上のさまざまな場所にある多くのサーバーと連携して動く、ということが、クラスタやネットワーク環境では重要になるでしょう。
クラスタのデータベースにおいて重要なのは、並列処理による高速化・ハイパフォーマンスと、冗長性の構築です。特に、冗長性の構築においては、サーバーがダウンした場合別のサーバーが代わりを務めるフェイルオーバ、データベースの複製を作るレプリケーション、ネットワーク上のマシンに負荷分散を行うロードバランサー、仮想マシンのリソースを適切にジョブに割り当てるワークロード管理・ジョブ管理などが重要になります。
クラスタ・分散・高信頼システムも参照のこと。
2023.09.27
データベースについては以下の書籍が参考になります。上記の内容は以下の書籍を参考に執筆しました。