実テーブルとビューテーブル

データベースでの表の構造は、テーブルの集合で表され、これは概念スキーマに相当する。

しかし、プログラマーの視点では、複数の表から構成されているといった所を気にせずプログラムを作れると便利。こういう使い勝手のよいテーブルは、外部スキーマに相当する。この外部スキーマを定義するものが、create view 命令である。

-- 優良業者しか見えないテーブル --
create view 優良業者 ( 業者番号, 優良度, 所在 )
  as select S.業者番号, S.優良度, S.所在
        from S where S.優良度 > 15 ;

-- 串刺し結果で参照できるテーブル --
create view 業者在庫 ( 業者名, 在庫量 )
  as select S.業者名, SG.在庫量
        from S, SG
        where S.業者番号 = SG.業者番号 ;

-- 外部スキーマで参照 --
select 業者在庫.業者名, 業者在庫.在庫量 from 業者在庫 ;

このように外部スキーマを設けることで、SQLをシンプルに記述できたり、外部プログラマが余計な内容を見れないようにしたりすることができる。ただし、データベースシステムによっては読み出しだけだったり、ビューテーブルを更新する時に更新異常が発生する場合がある。

データベースの設計

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

例えば、学生の成績データが以下のような構造であった場合、

 ID   | name   | grade | subject  | teacher
------+--------+-------+----------+---------
20101 | aoyama |   1   | database | saitoh
20101 | aoyama |   1   | software | murata
20002 | suzuki |   2   | database | saitoh
20002 | suzuki |   2   | compiler | nomura
30203 | yamada |   3   | media    | ogoshi

• 修正不整合: 授業担当が saitoh → sasaki のように変更になったら、複数のテーブルを修正しなければならない。
• 挿入不整合: 新しい科目 internet を追加したいけど、受講学生が決まらないとデータを挿入できない。
• 削除不整合: yamada が受講を取りやめたら、科目 media も消えてしまう。

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

学生                     受講            科目
 ID   | name   | grade   ID    | SubID   SubID | subject  | teacher
------+--------+-------  ------+-------  ------+----------+--------
20101 | aoyama |   1     20101 | 1001    1001  | database | saitoh → sasaki
20002 | suzuki |   2     20101 | 1002    1002  | software | murata
30203 | yamada |   3     20002 | 1001    1003  | compiler | nomura
                         20002 | 1003    1004  | media    | ogoshi
                  消す→ 30203 | 1004    1005  | internet | foobar → 追加

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

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