【より良い】データモデリング【モデルを】 (542ﾚｽ)
上下前次1-新
68: いなむらきよし 03/12/09 13:42 ID:90H4pzxx(1) AAS
キケー！
69(11): 03/12/10 21:34 ID:6/7ibqHE(1) AAS
T字型ERで教えていただきたいのですが、
会社で社員が部門に所属しているのを表すとき、
社員（社員コード、氏名） 部門（部門コード、部門名） 所属（社員コード、所属部門コード）
のようになるようなんですが、T字型でないERの場合は
社員（社員コード、氏名、所属部門コード） 部門（部門コード、部門名）
となると思うのです。
T字型ERでは所属というのを設ける理由はなにでしょうか？
70(1): 03/12/10 23:27 ID:fNZKjiUj(1) AAS
>>69
社員が一人が複数の部署に配属される場合以外は
あまり必要がないような気がしますね。
71(2): 03/12/10 23:51 ID:??? AAS
>>69
社員と部門の間に依存関係が存在するかどうかの違い。
部門に所属しない社員が許容されるならば、必然的に上の形になる。
所属部門コードにNULLを許して下の形の社員テーブルとする場合は、
概念スキーマ上の社員と所属を結合したものと考える。
あとは>>70の言う通り、所属の主キーを何にするかによっても
表現するものが変わる。
72: 69 03/12/12 08:56 ID:??? AAS
ありがとうございます。
データの状況や考え方次第ということですね。
73(1): 03/12/12 17:06 ID:yh7D7A4g(1) AAS
>>71
うーん、納得できないなあ。
部門に所属しない社員がいるとしても、社員が最大ひとつの部門にしか
所属できないとしたら、概念レベルでも「所属」は必然的ではないと思うな。
概念レベルでそういうエンティティを設けてそのまま実装したら、
ひとりの社員が複数の部門に所属しないための余計なコードを書かなきゃ
いけなくなるからね。
74(1): 03/12/13 17:11 ID:??? AAS
>>73
>概念レベルでそういうエンティティを設けてそのまま実装したら、
>ひとりの社員が複数の部門に所属しないための余計なコードを書かなきゃ
>いけなくなるからね。
なんで？制約で表現できると思うのだが。
75: 03/12/15 09:38 ID:8oMPv+z7(1/2) AAS
>>74
「所属」にどんな制約を組み込めば、
複数の部門に所属する社員が登録されるのを
避けれるんだろう。
76(1): 03/12/15 19:35 ID:??? AAS
>>76
社員キーをユニークにするんじゃだめなんか？
77(1): 03/12/15 20:01 ID:8oMPv+z7(2/2) AAS
あれ？Ｔ字型では「所属」のユニークキーは
社員コード＋所属部門コード
になるんではないのかな。
もしユニークキーが社員コードだけだと
すると、「所属」ってのは「社員」とキー
がいっしょってことになるな。
所属部門コードがＮＵＬＬではありえないなら
「所属」って意味ないような気がするんだが。
78: 03/12/16 23:03 ID:??? AAS
>>77
>もしユニークキーが社員コードだけだと
>すると、「所属」ってのは「社員」とキー
>がいっしょってことになるな。
>所属部門コードがＮＵＬＬではありえないなら
>「所属」って意味ないような気がするんだが。
「社員」「部門」はエンティティ、「所属」は「社員」と「部門」間の
リレーションシップを表現している。
意味がないと思うなら、>>71の言う通り、論理設計の段階で
結合してしまえば良い。
79(4): 04/01/01 20:26 ID:??? AAS
>>69-78
そのモデルだと所属が変わったときにその事実がどこにも残らないだろ。
モデリング対象の会社に社員の所属変更があるのなら、
配属イベント（配属コード、社員コード、部門コード、配属日）を置く。
そこから所属（＝指定日付における所属状態）がすべて再現できる。
80(1): [age] 04/01/02 00:33 ID:??? AAS
>>79
そりゃ要件しだいだな。
履歴が必要ならそういう設計もするだろうが、必要ないなら
徒にトランザクション性能を下げるだけだし。
結局のところ、業務分析した結果にそれが現れるかどうかだろう。
81: 04/01/02 00:34 ID:mdzOBQVK(1) AAS
AA省
82(1): 04/01/02 08:01 ID:??? AAS
>>80は業務分析と設計の区別がついていないのか？
「業務分析」の結果に配属履歴が現れるかどうかは、「業務」によって決まる。
だから「モデリング対象の会社に社員の所属変更があるのなら」と言ってる。
業務は個別アプリケーションの都合で変わりはしないからな。
分析結果に履歴形式が現れた場合に、実際に履歴テーブルとして実装するかどうかは
設計段階で決めることで、トランザクション性能云々はこのときに考えること。
>>69-78はそういうことを踏まえずに、
配属イベントをすっとばして所属の話だけをしてるから、
それはおかしいっつってんの。
83: 04/01/02 09:56 ID:??? AAS
>>82
>「業務分析」の結果に配属履歴が現れるかどうかは、「業務」によって決まる。
これは問題ないが、
>だから「モデリング対象の会社に社員の所属変更があるのなら」と言ってる。
ここがおかしい。所属変更があるということとその履歴が必要というのは
要件としてイコールじゃないから。
だから>>79が最初に言っている
省4
84(3): 04/01/02 15:13 ID:??? AAS
>実際、一人の社員が複数の部署に所属し得るという事実を表現するのには
>>>69のモデルで十分だし、それは所属変更がありうるとしても変わらない。
うーん、やっぱり設計と業務分析の区別がついてないね？
>>69のは、テーブル設計（設計の成果物）としては有りだが、
モデル（業務分析の成果物）としてはおかしいんだよ。
ここはモデリングのスレだろ。
85(1): 04/01/03 01:01 ID:??? AAS
>>>69のは、テーブル設計（設計の成果物）としては有りだが、
>モデル（業務分析の成果物）としてはおかしいんだよ。
おーい、>>69が業務分析だと言っている香具師がどっかにいたか？
もしかして「モデリング」＝「業務分析」とか？
つか、>>84にとっては「業務分析」と「テーブル設計」の間って
ないのかよ？
>ここはモデリングのスレだろ。
そう。データモデリングのな。
86: 04/01/03 05:06 ID:??? AAS
>おーい、>>69が業務分析だと言っている香具師がどっかにいたか？
T字ERを>>69自身が持ち出しているんだから、分析の文脈で捉えるのが自然だろ。
>もしかして「モデリング」＝「業務分析」とか？
>
>つか、>>84にとっては「業務分析」と「テーブル設計」の間って
>ないのかよ？
？？？ なんでこう話がかみ合わないかな…。
もしかして>>85はT字ERを知らないんじゃない？
87: 04/01/04 02:19 ID:??? AAS
なんか、「業務分析」と分析フェーズ全体をごっちゃにしてないか？
T字型ERは業務分析だけで使うもんじゃないだろうに。
まぁそれは言葉の問題だとしても、分析フェーズのoutputってのは
要求分析を経てシステム境界等が明確に定義されているべきもの
なんで、要件と無関係に>>79のような断言はできるはずがない。
純粋に業務分析の話ならば、社員の所属変更というごく一般的な
プロセスについてなんらかの言及ができてもおかしくはないと思うが、
誰も最初から>>69がそういう意味での業務分析のことだと思って
いないし、>>69自身そのつもりじゃないだろう。
もともと業務分析じゃないものを「業務分析としておかしい」と言われ
省10
上下前次1-新書関写板覧索設栞歴
あと 455 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.014s