アクセス 各テーブルでのフィールドの持ち方と、参照整合性リレーションのつなぎ方

お世話になります。

アクセスでテーブルを作っています。
後で参照整合性のリレーションで結ぶ予定のフィールドなんですが、
同じフィールドを、複数のテーブルに持つ必要があるか悩んでいます。
意味わかりにくくてすみません。

例えば、「○○事業部の、○○部署の、○○社員」という識別をする場合、
◆「事業部」テーブルのフィールド：「事業部コード」
◆「部署」テーブルのフィールド：「部署コード」「事業部コード」
◆「社員」テーブルのフィールド：「社員コード」「部署コード」　＊「事業部コード」
を作ります。

★この場合、「社員」テーブルの　＊「事業部コード」フィールドは必要か否かと、その理由（影響など）を知りたいのです！

「事業部」テーブルと「部署」テーブルの「事業部コード」、
「部署」テーブルと「社員」テーブルの「部署コード」は、
それぞれリレーションシップ（参照整合性）で結ぶ予定です。

★「事業部」テーブルと「社員」テーブルの「事業部コード」も、リレーションで結ぶ必要があるのでしょうか？

よろしくお願いします。

No.1 ベストアンサー 回答者： kurodai2 回答日時： 2007/08/17 16:59

>★この場合、「社員」テーブルの　＊「事業部コード」フィールドは必要か否かと、その理由（影響など）を知りたいのです！

不要です。
社員テーブルの部署コードで、部署マスタを参照すれば事業部コードは
取得できます。

設ける事の弊害
部署マスタの事業部コードに変更があった場合、部署マスタのみならず
社員テーブルの、事業部コードまで変更する必要が出てきます。

>★「事業部」テーブルと「社員」テーブルの「事業部コード」も、リレーションで結ぶ必要があるのでしょうか？

社員マスタには、事業部コードは不要なので、問題とならないです。

この回答へのお礼

早速のご回答ありがとうございます！

そうですね！確かに、kurodai2さんのおっしゃる設ける事の弊害は、本当にそのとおりですね。
気付きませんでした。
ずっと気になっていたのでスッキリしました！

今から「事業部コード」にあたるフィールドを削除します。
またよろしくお願いします。

お礼日時：2007/08/17 17:34

No.3 回答者： noname#140971 回答日時： 2007/08/17 18:34

余りにも愚かな回答と思われても何ですで２点ほど補足しておきます。

１、設計は、データ量で変わるもんです。
２、設計は、スタッフへの配慮でも変わるもんです。

事業部の数が３０程度ですと、単純区分名参照方式が適しているでしょう、
が、その数が１５０ともなると、

ＩＤ
部署_ID
コード
名称

というテーブル設計も視野に入ってくるのは当然。

さて、この場合、当然に、社員テーブルの[部署_ID]は無用となってきます。
しかし、これも＜スタッフへの配慮＞で最終決定する必要があると思います。

[部署_ID]を追放した場合、ＳＥＬＥＣＴ文で部署.名称を参照できるコードをスタッフが書けるか否か？
ここで、皆が苦労するようだったら、たとえ邪道と言われようとも残すべきでしょうね。

先の回答は、退社時間１分前の駆け込み回答で舌足らずでした。
チクッと、「設計もデータ量、スタッフレベルで決まる」という視点から補足しておきます。

この回答へのお礼

ご回答ありがとうございました。
お返事遅くなりまして申し訳ありません。

内容が専門的でちょっと分からなくて考えてしまいました。
きちんと理解できずにすみません。
なんとなくのレベルで申し訳ないですが、このような考え方もあるのだなと思いました。
すみません、全然理解できていないかもしれないです・・・

お礼日時：2007/08/20 10:30

No.2 回答者： noname#140971 回答日時： 2007/08/17 17:24

一介の服飾デザイナでプログラマではありませんので専門的な回答ではありません。

そういうことで参考程度にされて下さい。

(１)　部署コード、事業部コード、社員コード＝プライマリキーという発想はいかがかと思います。
(2)　リレーション・シップを張るべきか否かは、必要に応じて適宜に判断されてもよいと思います。

<社員>

ID____________1,2,・・・,N
コード_______101
部署_ID_____1
事業部_ID__1

<部署>

ID____________1,2,・・・,N
コード_______101
名称_________総務部,営業部

<事業部>

ID____________1,2,・・・,N
コード_______101
名称_________第一事業部、第二事業部

確かに、社員コードや部署コードが存在するので、それをプライマリキーにという発想も理解できます。
が、プライマリキーは、現実を映す鏡ではなく単なるデータベースの内部処理上で必要なもの。
こういう類の列は、現実を全く反映しない純粋なシステム列でいいのじゃないですかね。
この場合、参照整合性も、部署コード、事業部コードではなく[ID]で参照しているので問題ではないです。

さて、社員.部署_ID、社員.事業部_ID　が、単なる社員の大区分、中区分であればリレーションシップは不要。
そういう場合は、大区分や中区分の区分名を単にテーブルからルックアップしているに過ぎないとも言えます。
ですから、その限りでは、リレーション・シップも別段に必要不可欠ではないです。

と、私は、このように思います。