【より良い】データモデリング【モデルを】 (542ﾚｽ)
上下前次1-新
506(4): 2009/01/18(日)03:01 ID:rdZV1j35(1) AAS
>>505
レスありがとうです！
ありがたい指摘なのですが理解する語彙が足りずアドバイスを生かしきれないのが
残念ですが・・・
(1)で言われた「見積明細」テーブルは、本来「見積」テーブルと一体の繰り返し要素を別テーブルに分離した
もので主キーは設定していません。 １つの見積に対して複数の見積項目があるので２つのテーブルに分離しました。
販売業者における販売テーブルと販売明細テーブルのような関係です。
(2)の「請負契約」と「請負契約明細」も同様の関係です。
(3)の「請負金額入金」「請負金額請求」は確かに一つのテーブルに統合できそうです。
盲点でした・・ありがとうございます。
省5
507(3): 2009/01/18(日)04:03 ID:??? AAS
明細テーブルにも主キーはつけるべきだよ。
この場合は表示順を主キーにすりゃいいんじゃないかな。
> (3)の「請負金額入金」「請負金額請求」は確かに一つのテーブルに統合できそうです。
統合すると請求1回に対して入金複数回のケースとか対応できなくなるよ。
あなたんとこの業務的には問題ないのかも知れんけど、
柔軟性保つために分けておいたほうがベター
主キー入ってないテーブルがあること以外は、大体OKそうに見えるね。
>>505は見当はずれだから気にしないほうがいい
508: 2009/01/18(日)04:09 ID:??? AAS
> この場合は表示順を主キーにすりゃいいんじゃないかな。
ごめん、親テーブルの主キー＋表示順というつもりだった。
たとえば見積明細では（見積ID、表示順）を主キーにする
509(1): 2009/01/18(日)04:25 ID:??? AAS
>>506
505です。今日は何故か眠れないのでレス
ちょっと説明がまずかったみたいなので、まず用語から。
※文中の用語はググってね。
エンティティ＝テーブル
属性＝列項目
主キー＝（簡単に言うと）一意に行を特定できる列項目
（１）の、「１つの見積に対して複数の見積項目がある」という
のは、「見積」１行に対して「見積明細」複数行という意味であれば、
「見積明細」テーブルの主キーは、”見積ID”と、明細を識別する”明細ID"
省11
510: 2009/01/18(日)04:28 ID:??? AAS
>>507
どこが見当違いか、指摘してもらえるとうれしいね
511: 2009/01/18(日)04:43 ID:??? AAS
>>507
もしかして、（１）でサブタイプって書いたことを見当違いって
言ってるのかな？
エンティティ名だけ見ると、第２正規形を意識したと思えたけど、
もしかして主キーが同じで、あえて分けたのかと深読みしただけ
なんだけどね。
（３）は509で書いた通り。
（４）は、業務要件わからないから、所見てことで、
主眼を「請負契約」と同様に<<契約>>に置いてもいいかなと思ったのさ。
よろしく。
512(1): 2009/01/18(日)12:41 ID:??? AAS
あのさ、「明細」ってかいてあんのにピンと来ないようじゃお話にならないと思うよ。
513: 506 2009/01/18(日)20:01 ID:??? AAS
>>507
＞明細テーブルにも主キーはつけるべきだよ。
この場合は表示順を主キーにすりゃいいんじゃないかな
なるほど！ これは勉強になりました。 キーはテーブルの結合しか用途がないもの
だと思っていたのでそういう使い方が出来るのは初めて知りました。
＞主キー入ってないテーブルがあること以外は、大体OKそうに見えるね。
>>505は見当はずれだから気にしないほうがいい
いえいえ皆さんのアドバイスは大変勉強になります。
514: 506 2009/01/18(日)20:11 ID:??? AAS
>>509
＞「見積明細」テーブルの主キーは、”見積ID”と、明細を識別する”明細ID"
みたいなのが必要。（用語的には第２正規形）
たしかにおっしゃるとおりです。 明細テーブルの各行を識別するキーも必要ですね・・・。
ここらへんはまったくノーマークでしたのでありがたい指摘です。 その意味で
見積明細にも見積IDを主キーに設定すべきと仰っていたのですね。 私の間違いでした・・・
＞データモデルを考えるときに、業務の実態を、リソース（資源：名詞）と
イベント（出来事：動詞）に分けて、テーブルとして考えるのだけど、
この辺はいまの自分にはちょっと高度です もうちとレベルアップしてからアドバイスを
生かさせていただきます^^;
515: 2009/01/18(日)23:18 ID:??? AAS
高度ってあんた・・・
516: 2009/01/19(月)01:35 ID:??? AAS
>>512
まぁ、そう言いなさんな。所見で深読みしたけどさ。
最初の図（モデル）から想像したのは、子エンティティの
外部キーについて、親エンティティからのキー移行だけを間違えて
記述したものと深読みしたということ。
（よって、排他的サブタイプと見たわけ）
業界／業務要件が不明なので、モデルから判断するだけ、つまり、
名称（用語）でエンティティを安易に想像してはダメってことも
あるからね。（話をよく聞かないうちに決めつけちゃダメさ）
ちなみにウチの所でも、第２正規化の結果を「XX」「XX明細」と
省2
517: 506 2009/01/19(月)20:38 ID:??? AAS
みなさんのご指摘を参考に最終的に↓のように仕上げてみました。これでなんとか
やってみようと思います。 どうもありがとうございましたです！
画像ﾘﾝｸ[jpg]:niyaniya.info
518: 2009/02/01(日)03:55 ID:??? AAS
業務知識が無いと、まともな設計が出来ない見本だな。
運用で不具合出まくるだろうなあｗｗｗ
519(2): 2009/06/04(木)09:25 ID:w6Hljn46(1) AAS
五階層まで登録できる工事の見積システムのデータモデリングをしてるのですが
↓こんなかんじでどうでしょう^^;
外部ﾘﾝｸ:imepita.jp
項目A→項目B→項目C→項目D→項目E と具体的になっていく感じです
例） 電気→3LDK標準電気工事→玄関→外部玄関等→照明器具 DWP-3524DS
項目Aによって必要な階層がことなるので動的に階層を変更できればいいのですが、、
520: 2009/06/07(日)19:19 ID:??? AAS
>519
階層構造を柔軟にとか考えると、
所要量展開、再帰、LLC、
部品展開、原価計算、
といったところをある程度考慮して取り入れながら
設計するのかなと思う。
これらでぐぐってみてもよいかと。
521: 2009/06/09(火)23:40 ID:jbiexGaF(1) AAS
>>519
その前に親子関係は1対多なんだよね？
何もテーブルを幾つも作らなくても、
子情報が主キーでそこに親情報が従属するような
再帰的な1テーブルで済まないの？
これだと、多重構造が可変でも耐えられるでしょ？
522: 2011/02/08(火)23:20 ID:??? AAS
目指してる 未来が違う ｂｙシャープ
Twitterﾘﾝｸ:saramura6
523: 忍法帖【Lv=40,xxxPT】(1+0：8) 【24.9m】 電脳プリオン ◆3YKmpu7JR7Ic 2013/01/25(金)23:43 ID:??? AAS
もう語らないのか
524: 2013/03/02(土)18:51 ID:??? AAS
また必要とあれば語るだろう。
あなたはどうなのか。
525: 2013/03/15(金)16:29 ID:2duRrtZr(1) AAS
AA省
上下前次1-新書関写板覧索設栞歴
あと 17 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.007s