- PR -

テーブルの構成（リレーション）について

1|2 次のページへ»
投稿者投稿内容
るぷ犬
常連さん
会議室デビュー日: 2004/11/10
投稿数: 46
投稿日時: 2007-01-16 09:24
るぷ犬です。
お世話になっております。



現在、テーブルの構成（リレーション）で悩んでいます。

３つのテーブルがあり（TBL_会社,TBL_部課,TBL_社員）があり、
それぞれ下記のようになっています。


○TBL_会社

会社ＩＤ PK
会社名
住所

など

○TBL_部課

部課ＩＤ PK
会社ＩＤ
部課名

など

○TBL_社員

社員ＩＤ PK
部課ＩＤ
氏名

など


自分たちでは

TBL_会社　< TBL_部課 < TBL_社員
　（親）　（子）（親）（子）

の関係でいこうと思っていたのですが、


TBL_会社 ─┬ TBL_部課
　　　　　 └ TBL_社員
　（親）　　　　（子）


の様にしたらいいのではないかとも言われました。
現時点であまり定義を変えたくはないのですが、
普通で考えた場合、どちらがどういう理由でよろしいのでしょうか？
もしくは、どちらでもいいのでしょうか？


長くなりましたが、どなたか、ご教授よろしくお願いします。


一郎
ぬし
会議室デビュー日: 2002/10/11
投稿数: 1081
投稿日時: 2007-01-16 10:16
どちらがいいかは、その"会社"や"部課"という言葉で表している概念がどのような関係になっているかによります。
部課は、ある一つの会社に属していますよね。

社員はどうですか？
一つの会社に属しているだけですか。それともどの部課に属しているという情報も必要ですか。
burton999
ぬし
会議室デビュー日: 2003/10/06
投稿数: 898
お住まい・勤務地: 東京
投稿日時: 2007-01-16 10:34
あと検討したほうがいいと思うのは。
・部課を階層構造で管理しなくてよいか？
・社員は１つの部課にしか所属しないのか？（兼務）

後工程になればあるほどリレーションを変更するのが難しくなりますから
現時点で要件を整理して適切なモデルを設計したほうがいいと思います。
るぷ犬
常連さん
会議室デビュー日: 2004/11/10
投稿数: 46
投稿日時: 2007-01-16 10:38
お返事ありがとうございます。



概念としましては、

会社テーブルには複数の会社が入り（複数レコード）、
その複数の会社のそれぞれの部課が部課テーブルに入ります。

部課テーブルについては、部課は同じ部署名（システム部など）がありますが、
それは会社ＩＤで、分別しようとしています。


また、社員テーブルにはどの会社の、どの部課の人間であるかという情報が必要です。
（通常、社員はひとつの会社、ひとつの部課にしか属していません）



社員テーブルに会社ＩＤが入っていない理由は下記のように、


社員ＩＤより、会社名、部課名、氏名を抽出したい場合、
３つのテーブルを結合すればデータは取得できると考えた為でした。


しかし、社員ＩＤより、会社名、氏名を抽出したい場合も
３つのテーブルを結合するようになり（ますよね？）、
（部課テーブルも結合しないといけない（はず））
というところで、


果たして、

Ａ：社員テーブルにも会社ＩＤを付ける
Ｂ：常に３つのテーブルを結合する


の、どちらかがいいのかという所で迷っています。



るぷ犬
常連さん
会議室デビュー日: 2004/11/10
投稿数: 46
投稿日時: 2007-01-16 10:55
burton999さん、お返事ありがとうございました。


＞・部課を階層構造で管理しなくてよいか？

ついては、むしろ、どういう理由で階層構造にするのでしょうか
（下手すると、ＲＤＢＳという考え方になるのかもしれませんが。。。）
現行システムは階層構造になっていました。
（周りに、そのあたりの理由が聞ける人間がいませんもので･･･）


＞・社員は１つの部課にしか所属しないのか？（兼務）

今のところ兼務というところは無いようです。
しかし、兼務するということが発生した場合、
ＤＢの構成も変わるものなのでしょうか？


本来であれば、そのあたりはすでに決まっていないと
いけない時期なのですが…。



よろしくお願いします。
burton999
ぬし
会議室デビュー日: 2003/10/06
投稿数: 898
お住まい・勤務地: 東京
投稿日時: 2007-01-16 11:07
階層にする理由は業務によって様々ですが、例をあげると
組織は 部門-課 の２階層になってた場合
所属する社員の売上などの合計を、部門単位と課単位で集計したい場合
部と課の関係が階層構造になってないと集計できません。。。とか

システムが完成してから兼務にも対応してくれと言われた場合、変更にコストがかかるので
一応、兼務もできるように設計したほうがいいかもしれません。
まぁちゃんと要件を聞いて100%兼務がないとのことならシンプルに設計したほうがいいですが。
ちなみに兼務を許可する場合、「部課」と「社員」の関係が多対多になるので
間に「所属」みたいな関連テーブルを追加します。
Tasuku
大ベテラン
会議室デビュー日: 2006/09/14
投稿数: 106
お住まい・勤務地: tokyo
投稿日時: 2007-01-16 11:53
引用:

Ａ：社員テーブルにも会社ＩＤを付ける
Ｂ：常に３つのテーブルを結合する


べき論（正規化）では B: ですよね。
ただ、検索パフォーマンスを優先したいといった別の要件があって、
A: が B: より優れているという実証ができているなら、A: もありだと思います。
（本来はそういう設計ポリシーを決めておくべきなんですが...）

あとは、オブジェクト間の関係に柔軟性を持たせたいなら、
burton999さんの仰るように、関連を保持するテーブルを
別出しにするというポリシーにしてしまっても良いと思います。
（こちらもパフォーマンスとの天秤ですけれども）
カーニー
ぬし
会議室デビュー日: 2003/09/04
投稿数: 358
お住まい・勤務地: 東京
投稿日時: 2007-01-16 13:06
アプリケーションは考慮せず、単なるデータモデルとして考えると、

コード:
TBL_会社　< TBL_部課 < TBL_社員
　（親）　（子）（親）（子）


これだと、部課が廃止(DELETE)されたら、そこに所属している社員は全員リストラ(DELETE)。
外資系モデル

部課があろうとなかろうと、社員は社員なのであれば、

コード:
TBL_会社 ─┬ TBL_部課 
　　　　　 └ TBL_社員
　（親）　　　　（子）


こっちになります。組織の階層構造や、兼務については他の皆さんがおっしゃる通り。

まあ、社員は何に従属するのかによってデータモデルは変わるので、一概には言えないですがね。
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）