データモデル
これからはしばらくデータベースの話をまとめていきます．
データモデル
データベースには色んなデータが格納され，データ間で依存関係を持つものも存在します．
どんなデータが格納されているとか，このデータ間にはこんな関係がある，というのを図式化して整理したものをデータモデルといいます．
データモデルには，概念データモデルと論理データモデルがあります．
DBMS(DataBase Management System)の型を無視してデータ関係を表現するのが概念データモデル，DBMSの型を無視してデータ関係を表現するのが論理データモデルらしいです．(何言ってるかわからない)
概念データモデル
エンティティ(entity)と，エンティティ同士のリレーションシップ(relationship)によってデータやデータ集合の構造を表すモデルがE-Rモデルで，概念データモデルの一つです．
・エンティティ
データの項目を属性と呼び，属性の集合をエンティティと呼びます．
例えば，学籍番号，学生氏名，講義コード，講義名，講義区分，という5つの項目があるとすると，それぞれを属性といいます．
そして，{学籍番号，学生氏名}をまとめて「学生」，{講義コード，講義名，講義区分}をまとめて「講義」という情報として扱うとします．
新しくまとまりとして名前をつけたこの「学生」や「講義」がエンティティです．
・リレーションシップ
エンティティとして上に書いたような学生，講義があるとします．
そして学生と講義の間に，学生が講義を「履修する」という関係があったとき，この「履修する」というのがリレーションシップです．
リレーションシップは一つとは限らず，例えば学生と講義の間の「単位を取得した」とかもリレーションシップになりそうです．
さらに，各属性に具体的な値を持たせたものをインスタンスといいます．
例えば上の学生と講義のエンティティにおいて，(0001, アリス)や(1000, ボブ)は学生エンティティのインスタンスです．
同様に，(07, 英語基礎, 一般教養)や(85, データベース論, 専門科目)は講義エンティティのインスタンスです．
E-R図
E-Rモデルを図として表したのがE-R図です．
最近ではバックマン線図やUMLクラス図が使われているみたいです．
(UML：Unified Modeling Language)
この2つは後述します．
さらにエンティティ間のリレーションシップに関してカーディナリティという概念があります．
カーディナリティは多重度とも言われ，その名の通りリレーションシップにおける対応が多重になっているかどうかです．
先ほどの学生と講義のエンティティにおいて，1人の学生は普通は多数の講義を履修しますし，1つの講義は普通多数の学生から履修されます．
よって「履修する」というリレーションシップの多重度は多対多です．
次に，教員エンティティ{教員番号，教員氏名}と講義エンティティのリレーションシップ「担当する」を考えます．
1つの講義は1人の教員によって担当されるとします．
このとき，1人の教員は複数の講義を担当することはあるかもしれませんが，1つの講義は1人の教員に担当されます．
よって「担当する」の多重度は1対多です．
・バックマン線図
1対多という多重度において，「1」を直線，「多」を矢印で表します．(下図参照)
シンプルで図はごちゃごちゃしませんが，ぱっと見で意味がわかりにくいという特徴があります．
学生，講義，教員のエンティティ間のリレーションシップと多重度をバックマン線図で整理してみます．
・UMLクラス図
バックマン線図に比べて，「多」をより厳密に表現していて，多重度の最小値と最大値を明確に図中に示します．
例えば，最小で3，最大で5のときは「3...5」と書きます．
最小が1で，上限はないような場合は「1...*」と書きます．
学生，講義，教員のエンティティ間のリレーションシップと多重度をUMLクラス図で整理してみます．
この例では以下のことが読み取れます．
・1人の学生は5個以上20個以下の講義を履修している
・1つの講義は1人以上の学生が履修している
（1人の教員は0個以上の講義を担当している）
・1つの講義につき担当教員は1人である
3つ目はそれはそうってかんじなのでカッコにしておきました．
論理データモデル
論理データモデルには大きく階層型，ネットワーク型，関係型の3種類があります．
E-R図ではエンティティというものが出てきましたが，論理データモデルにおいてエンティティに対応するのはレコードとよびます．
階層型データモデル
レコード間のリレーションシップを親子関係で表すのが階層型の特徴です．
子レコードは親レコードを1つしか持てず，複数の親を持たせたいときはそれぞれの親に別の子としてレコードを追加する必要があります．
下の例では，子Bを親1と親3に2回登録しています．
子Eを飛ばしたのはミスではなくわざとです．(ほんまか??)
ネットワーク型データモデル
階層型の拡張で，子レコードは複数の親レコードを持つことができます．
上の階層型のモデルをネットワーク型で表すと下図のようになります．
赤線で示したように，1つの子レコードは複数の親レコードを持つことができます．
関係型データモデル
属性名とそれぞれの属性の値の組であるタプルの組み合わせとして表形式で関係を表したのが関係型データモデルで，最も広く利用されています．
下図のように表されます．
3層スキーマ
まずはスキーマの説明から．
データベースというからには，属性やそれらをまとめるレコードを定義する必要がありますし，データ達をどのようにディスク上に格納するかも決めなければいけません．
このようなデータベースの設計の仕方を記述したものをスキーマといいます．
データベースの規模が大きくなるにつれスキーマも複雑になるので，一部に変更があったときに他にも影響がどんどん出て修正する作業がとても大変になってしまいます．
そこでスキーマを独立性の高い3種類に分割することで，データベースを変更しても他への影響が最小限になるように工夫をしました．
これをデータ独立性などどいい，スキーマに上のようなデータ独立性を持たせたものが3層スキーマです．
3層スキーマでは，データベースを扱う立場によってスキーマを分割しています．
その立場とは，データ管理者，データベース管理者，利用者，の3種類です．
それぞれの立場におけるスキーマを，概念スキーマ，内部スキーマ，外部スキーマといいます．
順に説明していきます．
概念スキーマ
データ管理者(DA：Data Administrator)によって管理されます．
エンティティやリレーションなどの情報を持ち，データベースの全体像を定義するスキーマです．
内部スキーマ
データベース管理者(DBA： DataBase Administrator)によって管理されます．
効率よくデータを検索するためにデータベース中のデータをどのように格納するかなどを定義しています．
内部スキーマでのデータの独立性を物理的データ独立性といいます．
外部スキーマ
データベースにおいて，プログラムが必要とする情報のみを定義したものです．
例えば，元のデータベースに属性などの追加があった場合でも，その外部スキーマに影響がなければ外部スキーマは影響されません．
それぞれのユーザはデータベース自体から独立しており，これを論理的データ独立性といいます．
データモデルのまとめはこんなかんじです．
思ったよりボリュームが大きくなってしまった...
3層スキーマはわりと理解が浅いので日を改めて記事を更新するかもしれません．
次はデータベースの正規化の話です．
参考：アイテックIT人材教育研究部(2020)「2021応用情報・高度共通 午前試験対策書」
