５回にわたり、アプリケーションからSQLを使ってデータベースを制御する方法を紹介してきました。単一のテーブルからレコード群を抜き出したり、それらを削除したり変更したり、あるいは新しいレコードを追加したりする手順は、パターンを覚えれば非常に簡単です。
難しいのは、あるテーブルと別のテーブルとを、１つの共通するフィールドによって関連付ける“リレーション”の処理です。そしてそれがリレーショナル・データベースを扱う醍醐味でもあります。
テーブルを関連付けるには、既に紹介したようにWHEREやJOINを使って２つのテーブル間に共通するフィールドを示せばよいのですが、複雑な構造をSQLで記述する場合、テーブル同士の関係を正しく把握しておかないと、一体どちらがどちらを参照しているのか分からなくなることもあるでしょう。
そういったとき、データベースの側で予めテーブル同士の参照関係を定義しておくと、アプリケーション側での作業は格段に楽になります。また、複数のアプリケーションから共通した関連付けを利用できるため、仕様の統一も図れます。
サンプル・データベースとサンプル・アプリケーションの扱いについて
第９回以降、新しいサンプル・データベースを使っているのでご注意ください。新しいサンプル・データベースの登録方法については、第９回の記事から「新しいサンプルデータベースの準備」の項をお読みください。
なお、今回紹介するビューを作成するとサンプル・データベースの内容が書き換えられます。新たなオブジェクト（ビュー）が増えるだけでテーブルの内容が書き換えられることはないため、特にデータベースをバックアップしておく必要はありません。
|
|
- 目次 -
|
| ■ |
ビューとダイアグラム |
|
|
| ■ |
ビュー |
|
| ・ |
商品の在庫数を一覧表示する |
| ・ |
在庫一覧をビューにする |
| ・ |
ビューのデザイン |
| ・ |
アプリケーションから利用する |
| ・ |
ビューの結果をさらに絞り込む |
| ・ |
クエリファイル |
|
| ■ |
ダイアグラム |
|
| ・ |
結合方向 |
| ・ |
参照整合性制約 |
| ・ |
（a）レコードが存在しない矛盾 |
| ・ |
（b）IDフィールドの変更による矛盾 |
| ・ |
矛盾を自動的に回避する |
|
| ■ |
リレーションシップの設定 |
|
| ・ |
ダイアグラムとリレーションシップ |
| ・ |
参照整合性制約の設定 |
| ・ |
連鎖削除・連鎖更新は必須ではない |
|
| ■ |
定着時期の問題 |
|
| ・ |
過去が変わる矛盾 |
| ・ |
できるだけ頻繁に定着する |
|
| ■ |
あとがき |
|
