リレーションシップについて

Question

データベースを使ってシステムを作っているのですが、データベースを扱うことがあまり無いので日々勉強しながら作っています。
で、データベースの本を見るとよくリレーションシップを作成し、などとかかれています。このリレーションシップを作成すると、何か良いことがあるのでしょうか？
今まで作ってきたもの、参考にしたもにはリレーションシップを作成せずに、ビューなどを作ってデータを利用していました。このやり方で十分システムを作れているんですが、リレーションシップを作成すると、良いことがあれば組み込もうと思っています。

gadd3 · Accepted Answer

僕はAccessしか使ったことないのですが、Accessの場合だとリレーションシップはリレーションシップウィンドウで設定します。ここで設定したリレーションは、参照整合性（参照制約？）、連鎖更新、連鎖削除が設定できます。大してクエリ上では内部結合や各外部結合の設定まではできますが、参照整合性（参照制約？）、連鎖更新、連鎖削除ができません。

リレーションシップウィンドウでリレーションシップを設定し、例えば連鎖削除機能をONにすると、あるテーブルのレコードを削除したときに、それに関連するテーブルのレコードも自動削除できます。
（SQLServerだとダイアグラムになるのでしょうか？ADPの場合かな？済みませんよく知らなくて。）

クエリ（ビューみたいなもの）上のリレーションだけだとこれができないので、あってはいけないレコードがいまだに残っていたり、無いといけないレコードが無かったりと、内部的に矛盾した（ゴミ情報だらけの）データベースになってしまう場合があります。
（特にAccessのことを全く知らない一般ユーザーにもレコード操作させるとき）

もっとも、手動でVBA等で連鎖削除や連鎖更新の相当するプログラムコードを書けば良いのですが（でもめんどくさい）。リレーションシップウィンドウでリレーションを設定すると、要するにこの連鎖更新や連鎖削除などのコードを書かなくてすむので重宝しています。

ただし安易に削除、更新ができないように、普段は参照整合性だけにチェックを入れておいて、それ以外ははずしておき、必要なときだけ連鎖削除・連鎖更新をONにしています。作業が終わったらまたすぐにOFFに戻します。

以上のようなことがありますので、リレーションをしかるべきところできちんと設定しておかないと怖くて運用できません。


SQLServerをお使いとのことですが、Accessのクエリに相当する（と思うんですが）「ビュー」上でも参照制約や連鎖更新、連鎖削除の設定ができるのなら良いのですが、ビューでそういう機能を持たせるととんでもないことになりそうなので多分設定できないようになっているとは思うのですが…。
「ビュー」上でも参照制約や連鎖更新、連鎖削除の設定ができるのなら僕の話は無視してよいと思います（＾＾）。

11n_kacie · Answer

お世話様です。＃５です。
詳しいことは＃６さんがご説明されておりますので、補足程度に。

リレーショナルDBのリレーションは、やはりしかるべき箇所にて設定すべきだと思います。
Accessなら、おっしゃる通り「ツール→リレーションシップ」です。
ここで設定しておけばクエリ上でも同様のリレーションが適用されますし、
全テーブルのリレーションが図で見られるのでDBの構造が把握しやすいと思います。

クエリ等のみにて設定した場合、そのクエリを実行させたときに、
あたかもそのリレーションがあるかのように振舞うだけで（極端な言い方かもしれませんが）、
あくまでDB的には別個のテーブルということになります。
動作上不具合が無かったとしても、システム的には少し居心地の悪い感じがします。

11n_kacie · Answer

私の場合、データベースを設計する際にはまずテーブル同士のリレーションから考えます。
全くのゼロから作る場合でも、伝票からボトムアップを行う場合でも、
まずリレーションの考えに基づいてDB化対象の構造を分析します。

ですので、私個人の認識では
「リレーションシップを作成すると良いことがある」
というよりも、
「リレーショナルDBとその他のDB（カード型）では別物」
くらいの認識です。極端かもしれませんが。

当然、リレーショナルDBにはそれ独特のメリットもあります。
それについてはすでに皆様が説明されておられる通りですので割愛させていただきます。

cse_ri2 · Answer

データベースを作成する際、複数のテーブルをリレーション
するメリットは、データの変更をする際にその変更箇所が
少なくて済むからでしょう。


例えば、同一の顧客名が複数あるデータがあったとして、
顧客名を変更する作業が発生したとします。

この時に一つのテーブル（またはビュー）でデータを管理
している場合、該当する顧客名のデータを全件変更しなく
てはいけません。

しかし顧客マスタを別にもっていてメインのテーブルとリレーション
を貼っている場合、顧客名の変更は一箇所で済みます。

データが数千件レベルでしたら、複数レコードの変更も対して
負担がかかりませんが、データが数十万件～数千万件とも
なると、その変更時の負荷はバカにできません。


もっともデータをリレーションした時のデメリットというのも
存在します。
検索時に必ず各マスタとつき合わせをしなくてはいけない
ため、マスタ構造が深くなればなるほど、データの結合に
時間がかかってしまいます。

データウェアハウスのＤＢを構築する場合、意図的にリレーション
を作成せず一つの巨大なテーブルから検索を行うことで、
レスポンスを向上させる設計をすることもあります。

tsukasa-12r · Answer

ちなみに、データベースっていうのは何ですか？
Microsoft SQL Server ですか？
Access ですか？
Oracle ですか？
それとも、それ以外ですか？

ymmasayan · Answer

リレーションシップというのは関係付けですよね。
データベースには同じデータは原則として１箇所にしか持たないという鉄則があります。
そこで、例えば従業員表に何もかも持つのではなくて、本当に基本的なものだけを持ち、
家族表や賃金表や趣味表、資格表などを別々に作ります。
すると表（の行）と表（の行）の間にリレーションシップが必要になります。
また所属の例をとると、所属部署コードと所属部署名があります。
従業員表には所属部署コードだけを持ち、所属部署表で所属部署コードと所属部署名の
対応を持ちます。
このときも従業員表から所属部署表へのリレーションシップが必要になります。

簡単にまとめると、データのダブりをなくするために表を細切れにする。
（正規化といいます）。
すると表と表のつながりはリレーションシップでつながないといけないということです。

ares · Answer

一つのテーブルに保存するにはあまりにデータ量が多いような場合は、いくつもテーブルを分けて管理する方が便利です。そのテーブル間をつなぐのがリレーションシップですね。
　例えば顧客名簿としましょう。
　顧客会社名・住所・注文品・数量と言ったデータを今まで１つのテーブルで管理してたものを
　＊顧客のデータ（住所や会社名）は１テーブル
　＊顧客の注文履歴は１テーブル
　＊商品は１テーブルとわけて、それぞれを関連づけ（リレーションシップ構築）していれば、
商品名が変わった等の場合、商品を管理しているテーブルの商品名を変更するだけで、連動するデータも自動的に変わるわけです。

　単純な管理は１テーブルで良いですが、複雑ないろいろな情報が混じり合ったデータ管理は、リレーションを組む方が便利です。

リレーションシップについて

僕はAccessしか使ったことないのですが、Accessの場合だとリレーションシップはリレーションシップウィンドウで設定します。

お世話様です。

私の場合、データベースを設計する際にはまずテーブル同士のリレーションから考えます。

この回答への補足

データベースを作成する際、複数のテーブルをリレーション

この回答への補足

ちなみに、データベースっていうのは何ですか？

この回答への補足

リレーションシップというのは関係付けですよね。

この回答への補足

一つのテーブルに保存するにはあまりにデータ量が多いような場合は、いくつもテーブルを分けて管理する方が便利です。

この回答への補足

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング

　一つのテーブルに保存するにはあまりにデータ量が多いような場合は、いくつもテーブルを分けて管理する方が便利です。