2024年11月
 12
3456789
10111213141516
17181920212223
24252627282930

検索・リンク

ERモデル

データベースの設計

リレーショナル・データベースでは、データは表形式であればなんでも良い訳ではない。

例えば、学生の成績データが以下のような1つのテーブルで構成されるデータだった場合、

ID name grade subject teacher
20101 青山 1 データベース 斉藤
20101 青山 1 ソフトウェア工学 村田
20002 鈴木 2 データベース 斉藤
20002 鈴木 2 コンパイラ 西
30203 山田 3 情報メディア 小松
× × × 情報ネットワーク 森田
  • 修正不整合: 授業担当が 斉藤高久 のように変更になったら、複数のテーブルを修正しなければならない。大量のレコード修正は、時間がかかるし、その途中にシステムダウンしたらデータの整合性に問題が発生するかも。
  • 挿入不整合: 新しい科目 情報ネットワーク を追加したいけど、受講学生が決まらないとデータを挿入できない。
  • 削除不整合: 山田 が受講を取りやめたら、科目 情報メディア も消えてしまう。

これらを考慮すると、以下のような3つの表で設計するべきである。

■学生(実体)

ID name grade
20101 青山 1
20002 鈴木 2
30203 山田 3
■受講(関係)

ID (FK) SubID (FK)
20101 1001
20101 1002
20002 1001
20002 1003
30203 1004

30203を消しても情報メディア
の科目のデータは残る
FK=外部キー

■科目(実体)

SubID Subject teacher
1001 データベース 斉藤
1002 ソフトウェア工学 村田
1003 コンパイラ 西
1004 情報メディア 小松
1005 情報ネットワーク 森田

斉藤高久に変更したら
複数のレコードを要修正。

情報ネットワークを追加しても問題なし

データベースの設計では、(1)概念設計、(2)論理設計、(3)物理設計が行われる。

  • 概念設計:概念スキーマの決定(実体・関係モデルを使う)。上記の受講データベースの設計例
  • 論理設計:論理スキーマの決定。関係データベースで実装?ほかのデータベース?
  • 物理設計:物理スキーマの決定。データの格納方法や管理方法を決める。

実体関連モデル(ERモデル)

データベース設計では、実体関連モデル(ERモデル:Entity-Relation model)が使われる。 実体とは、モデル化しようとする対象で独立した存在となれるもの。 実体が持つ色々な特性は属性と呼ばれる。 属性の取りうる値の集合を定義域、同一種類の実体の集まりを実体集合と呼ぶ。 関連とは、実体同士の相互関係をモデル化したもの

実体関連図(ER図)では、実体を長方形、関連をひし形、属性を楕円で表現する。 属性で、キーとなるものには下線をつけて表す。

ER図で調べると、実際にはもっと細かい規定で表現が行われている。 参考:IDEF1X表記とIE表記