【より良い】データモデリング【モデルを】 (543ﾚｽ)
上下前次1-新
148: 04/07/09 00:09 ID:??? AAS
途中で送信してしまった.
>146
T字形だよ.良くまちがえられるけど.
DBの知識にしたがった方式.
知っているのと知らないでは格段に違うのは確かだけど、そのまま信じきるのもどうかと思う.
DATARUNと併せて知っておいた方がいい方法論.
最近はアジャイルデータベースとかオブジェクト指向方面からの方法論もいろいろあるようだ.
149: 04/07/23 10:53 ID:??? AAS
AA省
150: 04/09/10 21:46 ID:??? AAS
>>98
新作マダー？
151(1): 04/09/20 19:27 ID:6Fl/7m0x(1) AAS
visio2003なんですが、データベースのER図で
ただの矢印でなくリレーションの種類によって
蛸足とか丸印とか付いてるのを見かけます。
あれはどうやったら出せるのでしょうか？
152(1): 04/09/22 12:16 ID:??? AAS
2000しか知らないけど、線のプロパティで始点と終点の形状を弄れば出てくるぞ。
153: 04/09/24 16:52 ID:AXzql5sY(1) AAS
たとえば顧客マスタで、顧客には最大５人まで担当者がいる場合に、
顧客コード・顧客名・担当１・担当２・・・担当５
とするか、
顧客コード・顧客名
担当コード・顧客コード・担当
というふうに２テーブルに分けるか、どうしたものだろう。
担当者の最大値が決まっている場合には繰り返し項目にならないと
思うので（違ってたら指摘して！）、正規化違反にはならないと
思うのだが、作ろうとしてるテーブルの列数が40位になりそう
なので、分けたほうがいいのかしらんと迷ってます。
154(2): 04/09/24 17:40 ID:??? AAS
迷うならとりあえず正規化しとけ。
プログラミング局面では、最大値が決まっていようがいまいが正規化されてるほうが楽な事が多いよ。
担当者が3人以上いる顧客を抽出・・・ってな要件が出たとき、横に長いテーブルだとﾏﾝﾄﾞｸｻ
あくまで例えだけど。
155: 151 04/09/25 00:26 ID:??? AAS
>>152
ありがトン!
156(3): 04/09/25 01:29 ID:axxmUZh0(1) AAS
>>154
でも担当者を横一列に並べようとする時に
正規化するとめんどくさいですね。
明細がぶらさがるとかじゃなくて
5人って決まってる場合は
そういう出力の仕方の方が多くないかな。
でも>>154の要件もあるかも知れないし
出力する局面でどっちにするか判断するって
ところじゃないでしょか。
157(1): 04/09/26 00:57 ID:??? AAS
>>156
出力する局面で正規化するしないを判断するなんて論外。
・担当者別顧客リストなんて間違いなく要件の中にあるはずだが、どうやって実現する?
・とある担当が辞めた場合どうする?
全ての顧客マスタの担当項目1-5を検索して、該当する顧客レコードを更新。
更新箇所以降の担当項目の前詰め処理。
↑5人横に並べるのとどっちが面倒くさいよ?
素直に正規化しておくべき。
>>154
> 最大値が決まっている場合には繰り返し項目にならない
省3
158: 156 04/09/26 10:22 ID:Etehnh4k(1) AAS
レスくれた人さんきゅ。
繰り返し項目の正しい定義ってなんだろうね。
俺っちは、最大値が決まってる場合、担当1・担当２・・・というふうに
2次元の表にできるから、繰り返し項目にはならないのかと思ってた。
159: 156 04/09/27 10:26 ID:p0HsFnJ6(1) AAS
>>157
うーんそうか、流石に5人ともなると前詰とか考えなきゃいかんわけか。
実は俺がやったシステムは担当者は2名だったんで
正規化してませんでした（設計は別の人）。
2名だと正・副のニュアンスもあるからあえて正規化しなかったって
話かも知れなかったですね。うーん。
160: 04/10/08 07:13 ID:??? AAS
担当1・担当2のようになるなら繰り返し。
最大値が決まってるというのは幻想で、実は今だけってのが現実
161(1): 04/10/08 07:15 ID:??? AAS
最大値を制限するのはプログラム側でなくDBのトリガや制約等の機能を利用し
て制限するのが普通
162: 04/10/08 07:16 ID:??? AAS
とにかくやつらにプログラムさせるな、が基本
163(2): 04/10/08 07:52 ID:??? AAS
>>161
ユーザーにやさしくエラーを返してあげるためにプログラム側での工夫も必要？
164: 04/10/08 10:05 ID:h796f5Km(1) AAS
>>163
それはこっちでちょっと話題になったな
↓
制約っていらなくね？
2chｽﾚ:db
悩みどころだね。
165(2): 04/10/09 01:08 ID:??? AAS
>163
制約エラーが発生すればエラーメッセージを出すようにはプログラムする
普通のエラー処理のある言語なら問題なく可能
制約でのエラーの方がプログラムをほぼしなくて済むので良い
とにかくやつらと、そしてわたしにプログラムさせるな、が基本である事にかわりない
プログラムは組めば組むほどバグが増加する物、それはだれが作成してもだ
166(2): 04/10/09 14:07 ID:WoYiUuS/(1) AAS
>>165
C/Sの業務アプリなんかだとそう理想どおりいかないんですわ。
例えば、必須項目の入力チェックをする時に、
エラー表示を閉じたら自動的に
未入力の入力欄にフォーカスを移動して欲しいって
要望があった場合、アプリ側でチェックせんといけない、
NOT NULL制約のエラーだけに頼れないんですよ。
とはいえ、制約はそれをみればドキュメントが貧弱だったとしても
設計した人の意図が浮き上がりやすいので捨てがたい。
で、制約・アプリ両方盛り込むと二重管理になる。
省1
167: 04/10/09 16:04 ID:??? AAS
アプリ側でのバリデーションなんてWebだろうが業務アプリだろうが当然すると思うけど
DB側の制約(CHECKとかNOT NULLとか)は制約内容とDB設計者の好みに寄る希ガス
漏れはビジネスルール的なものであればアプリ側でかけさせて
それ以外はなるべくDB側でかけさせるようにしてるかなあ
まあ、NOT NULLなんかは二重管理になりがちだけど
上下前次1-新書関写板覧索設栞歴
あと 376 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.018s