-PR-
解決済み

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

  • すぐに回答を!
  • 質問No.3262732
  • 閲覧数296
  • ありがとう数2
  • 気になる数0
  • 回答数3
  • コメント数0

お礼率 94% (18/19)

お世話になります。

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

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

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

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

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

よろしくお願いします。
通報する
  • 回答数3
  • 気になる
    質問をブックマークします。
    マイページでまとめて確認できます。

質問者が選んだベストアンサー

  • 回答No.1
レベル11

ベストアンサー率 38% (77/202)

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

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

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

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

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

お礼率 94% (18/19)

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

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

今から「事業部コード」にあたるフィールドを削除します。
またよろしくお願いします。
投稿日時 - 2007-08-17 17:34:37
関連するQ&A
-PR-
-PR-

その他の回答 (全2件)

  • 回答No.2

一介の服飾デザイナでプログラマではありませんので専門的な回答ではありません。 そういうことで参考程度にされて下さい。 (1) 部署コード、事業部コード、社員コード=プライマリキーという発想はいかがかと思います。 (2) リレーション・シップを張るべきか否かは、必要に応じて適宜に判断されてもよいと思います。 <社員> ID____________1,2,・・・,N コード ...続きを読む
一介の服飾デザイナでプログラマではありませんので専門的な回答ではありません。
そういうことで参考程度にされて下さい。

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

<社員>

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

<部署>

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

<事業部>

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

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

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

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


  • 回答No.3

余りにも愚かな回答と思われても何ですで2点ほど補足しておきます。 1、設計は、データ量で変わるもんです。 2、設計は、スタッフへの配慮でも変わるもんです。 事業部の数が30程度ですと、単純区分名参照方式が適しているでしょう、 が、その数が150ともなると、 ID 部署_ID コード 名称 というテーブル設計も視野に入ってくるのは当然。 さて、この場合、当然に、社員テ ...続きを読む
余りにも愚かな回答と思われても何ですで2点ほど補足しておきます。

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

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

ID
部署_ID
コード
名称

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

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

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

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

お礼率 94% (18/19)

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

内容が専門的でちょっと分からなくて考えてしまいました。
きちんと理解できずにすみません。
なんとなくのレベルで申し訳ないですが、このような考え方もあるのだなと思いました。
すみません、全然理解できていないかもしれないです・・・
投稿日時 - 2007-08-20 10:30:39
このQ&Aのテーマ
このQ&Aで解決しましたか?
関連するQ&A
-PR-
-PR-
このやり方知ってる!同じこと困ったことある。経験を教えて!
このQ&Aにはまだコメントがありません。
あなたの思ったこと、知っていることをここにコメントしてみましょう。

その他の関連するQ&A、テーマをキーワードで探す

キーワードでQ&A、テーマを検索する
-PR-
-PR-
-PR-

特集


新大学生・新社会人のパソコンの悩みを解決!

いま みんなが気になるQ&A

関連するQ&A

-PR-

ピックアップ

-PR-
ページ先頭へ