【より良い】データモデリング【モデルを】 (542ﾚｽ)
上下前次1-新
499(2): 2008/09/06(土)12:04 ID:??? AAS
1レコードに開始/終了時刻を持って「状態」を記録するメリットって何？
開始/終了イベントテーブルにそれぞれ発生時刻を記録するほうがいいと思うんだけど
500: 2008/09/08(月)00:51 ID:??? AAS
>>499
イベントテーブルにそれぞれ記録するほうがいいのは
たとえばどんな時でしょうか？
501: 2008/09/08(月)23:23 ID:??? AAS
>>499
抽出したエンティティの意味的な違いに優劣はないから実用上のメリットで言うと、
所要時間を求めるようなクエリでjoinを節約できるとか。
逆に挿入/更新でコストはかかっているわけで、メリット/デメリットともに
事前集計表と似たようなもの。
502: 2008/12/23(火)20:52 ID:GasTPqXo(1) AAS
保守
503: 2008/12/28(日)05:07 ID:??? AAS
状態が欲しい場合も無く無いと思うけどなあ。
導入事例ってあんまり当てにならないのか。まあそもそも営業資料だしね。
導入されても、実際十分に活用されてるかどうかや、現在も使われてるかどうかはわからないしなあ。
504(1): 2009/01/17(土)01:16 ID:jMspYNZv(1) AAS
町場の工務店用データベース作成のためこんな感じのＥＲ図を作成してみたのですが
もし問題があれば指摘していただけるとありがたいです。
画像ﾘﾝｸ[jpg]:niyaniya.info
業務の基本的な流れは 見積作成⇒請負契約⇒ 工事 です。オリジナルはもうすこしマスタテーブルが
増えて複雑なのですが、基本はこんな感じです。 よろしくお願いします。
505(3): 2009/01/17(土)23:29 ID:??? AAS
>>504
普段、IDEF1Xでしか読み書きしてないから、リレーションシップの
意味が正しく理解できてるかわかんないのと、業務要件が不明だから、
自分の所見でコメント。
（１）「見積明細」の主キーは”見積ID”では？。
「見積明細」は「見積」のサブタイプということだと思うけど、
意味があって分けてるのかな？
（２）「請負契約明細」についても（１）と同様。
（３）「請負金額入金」「請負金額請求」は、「入金」「請求」として
独立エンティティにするか悩むところ。
省10
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
業務知識が無いと、まともな設計が出来ない見本だな。
運用で不具合出まくるだろうなあｗｗｗ
上下前次1-新書関写板覧索設栞歴
あと 24 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.013s