【より良い】データモデリング【モデルを】 (542ﾚｽ)
上下前次1-新
489: kAXUAXtktXfWiAc [toucheme@toucheme.com] 2007/11/23(金)10:57 ID:??? AAS
外部ﾘﾝｸ:iqlveq.cncheapmp3downloads
490: XRXQZTpLvYJra [dialog@golaid.info] 2007/11/23(金)12:14 ID:??? AAS
外部ﾘﾝｸ:itdvmb.cnmp3playerdownloads
491: qgNOgKJitye [ImADisco@ImADisco.org] 2007/11/23(金)21:16 ID:??? AAS
外部ﾘﾝｸ[html]:kgnsye.cn Imax california
外部ﾘﾝｸ[html]:kgnsye.cn California dept of corporation htm
外部ﾘﾝｸ[html]:kgnsye.cn Single family homes carlsbad california
外部ﾘﾝｸ[html]:kgnsye.cn Archangel tattoo design
外部ﾘﾝｸ[html]:kgnsye.cn Blue book pricings for atv
492: vnlCkSByPPMG [nightmp3@bdzwbn.cn] 2007/11/25(日)00:46 ID:??? AAS
外部ﾘﾝｸ:bfsnbw.cn free memory
493: 2008/02/10(日)12:22 ID:??? AAS
MySQL4.1、5.0でも DBDesignerは使えますか？
>>384 に同じ現象が書かれているのですが・・・
バージョンアップされてないからなぁ＾＾；
494: 2008/05/23(金)04:29 ID:P38jVWZR(1) AAS
A C
495: VQiYlHzPZa [ehohon@shhnjv.com] 2008/06/01(日)13:42 ID:??? AAS
n1ywUN <a href="外部ﾘﾝｸ:vdgsdgcxvewl.com">vdgsdgcxvewl</a [url=外部ﾘﾝｸ:ltldczvyogvo.com]ltldczvyogvo[/url], [link=外部ﾘﾝｸ:dznjgohehaza.com]dznjgohehaza[/link], 外部ﾘﾝｸ:whxrulsmcetw.com
496: 2008/07/07(月)17:23 ID:??? AAS
住所録のデータベースのモデルです。
取引先の会社とその担当者、お客様とその家族、
と、全部で4つのテーブルを作成しました。
それぞれのテーブルには、名前や電話や住所などの
列を並べました。
そこで疑問になったのが。
取引先の住所と担当者の住所は、共通する事もある（し違う事もある）。
家族の住所と個人の住所は、共通する事もある（し違う事もある）。
と、考えると。
住所部分のみでテーブルを作成して、4つのテーブルから
省1
497: 2008/07/07(月)22:08 ID:??? AAS
そうね。それなら取引先が複数住所もってるケースにも対応できるね
498: 2008/07/07(月)22:38 ID:??? AAS
取引先が複数住所を持ってるケースは考えていませんでしたが。
確かにおっしゃる通りで、良さそうですね。
また、営業所が移転した場合や家族が引っ越しした時に、
同じ住所テーブルを示していれば、個人の住所も一括で
修正されますね。ありがとうございました。
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、表示順）を主キーにする
上下前次1-新書関写板覧索設栞歴
あと 34 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.010s