ようやっとデータベース関連です。
DBMSは（DataBase Management System）の略でデータベースを利用したいアプリケーションのためにデータベース機能を提供するミドルウェアです。
応用ソフトウェア
ミドルウェア
基本ソフトウェア
データベースは、アプリケーションのデータを保存・蓄積するための一つの手段です。大量のデータを蓄積しておいて、そこから必要な情報を抜き出したり、更新したりするということが柔軟に行えるため、複数の利用者が大量のデータを共同利用する用途で強みを発揮します。
データベースにはいくつか種類があり、代表的なものが次の3つです。
- 関係型
- 階層型
- ネットワーク型
中でも関係型と呼ばれるデータベースが現在の主流です。
関係データベースは表、行、列で出来ている。
こちら全体は表と呼び、縦が列、横は行
データベースはデータ１件が1つの行として記録されるイメージで、追加も削除も基本的に行単位で行います。
この行が複数集まることで表の形が出来上がります。
行
行
行
データが行単位で積み重なっていくため表になります。
表、行、列には別の呼び名もあります。
| 説明 | |
|---|---|
| 表（テーブル） | 複数のデータを収容する場所のこと |
| 行（レコード、組、タプル） | 1件分のデータを表す |
| 列（フィールド、属性） | データを構成する各項目を表す |
なんで「関係」データベースという名前なのかというと、データの内容次第で複数の表を関連付けして扱うことができるからとなります。関係をリレーションシップといい、RDB:Relational Database(リレーショナルデータベース)とも呼ばれます。
表を分ける「正規化」という考え方
関係データベースは、蓄積されているデータに矛盾や重複が発生しないように、表を最適化するのがお約束です。
そうならないように表を分割したりします。
これを正規化と呼びます。
下記の表でジョンさんと万次郎さんが営業部に変更になった際に書き換える必要があります。今後も様々な部署が追加される可能性もあります。
その時に表を新しく作ってしまいます。
| 社員番号 | 名前 | 部署ID | 住所 |
|---|---|---|---|
| 2000000 | 太郎 | 1 | 埼玉 |
| 2000001 | 田中 | 2 | 北海道 |
| 2000002 | ジョン | 1 | 北極 |
| 2000003 | 万次郎 | 1 | イタリア |
| 部署ID | 部署名前 |
|---|---|
| 1 | 営業部 |
| 2 | ワガママ部 |
| 3 | 部部部 |
| 4 | 場ブー |
正規化したことで部署名が変更されたとしても部署表の名前を変更すれば完了なので、修正漏れも少なくすみます（この正規化が適切なのかどうかは置いておいて）
関係演算とビュー表
関係演算というのは、表の中から特定の行や列を取り出したり、表と表をくっつけて新しい表を作り出したりする演算のことです。「選択」「射影」「結合」などがあります。
選択
選択は、行を取り出す演算です。この演算を使うことで、表の中から特定の条件に合致する行だけを取り出すことができます。
| 社員番号 | 名前 | 部署ID | 住所 |
|---|---|---|---|
| 2000000 | 太郎 | 1 | 埼玉 |
| 2000001 | 田中 | 2 | 北海道 |
| 2000002 | ジョン | 1 | 北極 |
| 2000003 | 万次郎 | 1 | イタリア |
部署1のレコードを取り出す
| 社員番号 | 名前 | 部署ID | 住所 |
|---|---|---|---|
| 2000000 | 太郎 | 1 | 埼玉 |
| 2000002 | ジョン | 1 | 北極 |
| 2000003 | 万次郎 | 1 | イタリア |
射影
射影は列を取り出す演算です。この演算を使うことで、表の中から特定の条件に合致する列だけを取り出すことができます。
選択は、行を取り出す演算です。この演算を使うことで、表の中から特定の条件に合致する行だけを取り出すことができます。
| 社員番号 | 名前 | 部署ID | 住所 |
|---|---|---|---|
| 2000000 | 太郎 | 1 | 埼玉 |
| 2000001 | 田中 | 2 | 北海道 |
| 2000002 | ジョン | 1 | 北極 |
| 2000003 | 万次郎 | 1 | イタリア |
部署1のレコードを取り出す
| 社員番号 | 名前 |
|---|---|
| 2000000 | 太郎 |
| 2000002 | ジョン |
| 2000003 | 万次郎 |
結合
結合は表と表をくっつける演算です。表の中にある共通の列を介して2つの表をつなぎ合わせます。
| 社員番号 | 名前 | 部署ID | 住所 |
|---|---|---|---|
| 2000000 | 太郎 | 1 | 埼玉 |
| 2000001 | 田中 | 2 | 北海道 |
| 2000002 | ジョン | 1 | 北極 |
| 2000003 | 万次郎 | 1 | イタリア |
| 部署ID | 部署名前 |
|---|---|
| 1 | 営業部 |
| 2 | ワガママ部 |
| 3 | 部部部 |
| 4 | 場ブー |
合体！
| 社員番号 | 名前 | 部署ID | 部署名 | 住所 |
|---|---|---|---|---|
| 2000000 | 太郎 | 1 | 営業部 | 埼玉 |
| 2000001 | 田中 | 2 | ワガママ部 | 北海道 |
| 2000002 | ジョン | 1 | 営業部 | 北極 |
| 2000003 | 万次郎 | 1 | 営業部 | イタリア |
上記のように仮想的に作る一時的な表のことをビュー表と言います。
スキーマ
スキーマの意味は概要、要旨といった意味を持つ言葉で、データベースの構造や仕様を定義するものです。
標準的に使用されているANSI/X3/SPARC(Standards Planning And Requirements Committee)規格では3層スキーマ構造をとっています。
これは外部スキーマ、概念スキーマ、内部スキーマという３層に定義を分けることで、データの独立性を高めています。
プログラム
|
|
外部スキーマ
|
|
概念スキーマ
|
|
内部スキーマ
|
|
磁気ディスク
外部スキーマ
| 部署ID | 部署名前 |
|---|---|
| 1 | 営業部 |
| 2 | ワガママ部 |
| 3 | 部部部 |
| 4 | 場ブー |
ビュー表などがこれにあたります。利用者の必要とするデータの見方を表現します。
プログラムに加えた変更は外部スキーマまでしか影響しません。
概念スキーマ
- エンティティ間の“1対多”、“多対多”などの関連を明示するためのE-Rモデルの作成
- エンティティ内やエンティティ間の整合性を保つための一意制約や参照制約の設定
- データの冗長性を排除し、更新の一貫性と効率性を保持するための正規化
などのデータの論理的関係を表すのが概念スキーマです。
内部スキーマ
- SQL問合せ応答時間の向上を目的としたインデックスの定義など
データの物理的関係を表現します。
まとめ
DB周りは超重要なので、しっかりやります。