【より良い】データモデリング【モデルを】at DB【より良い】データモデリング【モデルを】 - 暇つぶし2ch■コピペモード□スレを通常表示□オプションモード□このスレッドのURL■項目テキスト502:NAME IS NULL 08/12/23 20:52:33 GasTPqXo 保守 503:NAME IS NULL 08/12/28 05:07:16 状態が欲しい場合も無く無いと思うけどなあ。 導入事例ってあんまり当てにならないのか。まあそもそも営業資料だしね。 導入されても、実際十分に活用されてるかどうかや、現在も使われてるかどうかはわからないしなあ。 504:NAME IS NULL 09/01/17 01:16:45 jMspYNZv 町場の工務店用データベース作成のためこんな感じのER図を作成してみたのですが もし問題があれば指摘していただけるとありがたいです。 http://niyaniya.info/pic/img/2186.jpg 業務の基本的な流れは 見積作成⇒請負契約⇒ 工事 です。オリジナルはもうすこしマスタテーブルが 増えて複雑なのですが、基本はこんな感じです。 よろしくお願いします。 505:NAME IS NULL 09/01/17 23:29:03 >>504 普段、IDEF1Xでしか読み書きしてないから、リレーションシップの 意味が正しく理解できてるかわかんないのと、業務要件が不明だから、 自分の所見でコメント。 (1)「見積明細」の主キーは”見積ID”では?。 「見積明細」は「見積」のサブタイプということだと思うけど、 意味があって分けてるのかな? (2)「請負契約明細」についても(1)と同様。 (3)「請負金額入金」「請負金額請求」は、「入金」「請求」として 独立エンティティにするか悩むところ。 入金単位や請求単位が請負契約単位なのかな? (1契約で入金は複数回とかないのかな) (4)何故「仕入契約」「下請契約」は"業者ID"が主キーに なってるのに、「請求契約」の方には”顧客ID”が主キーに なってないの? この違いの意味は? 両方とも<契約>という同じような意味のエンティティと 考えれば、その属性も同じような主キー構成で いいと思うけど。 ※属性なしで、エンティティ名だけでリレーションシップを 考えた方がわかりやすいですよ。 次ページ最新レス表示レスジャンプ類似スレ一覧スレッドの検索話題のニュースおまかせリストオプションしおりを挟むスレッドに書込スレッドの一覧暇つぶし2ch