【より良い】データモデリング【モデルを】

【より良い】データモデリング【モデルを】 (537ﾚｽ)
上下前次1-新
抽出解除ﾚｽ栞

26(4): 名無しさん＠お腹いっぱい。 [saga] 03/07/23 12:53 ID:??? AAS
独学でDB設計を勉強するのに、お勧めの書籍などありますか？
また、練習方法とかあったら教えてください。

50(4): 名無しさん＠お腹いっぱい。 03/09/16 13:27 ID:nh/rX7Cl(1) AAS
1足500円だけど色々組み合わせで3足なら1000円とかの靴下とかって
どういう風に単品在庫＆売上管理してのでしょうか？

単純に店員が人力でディスカウントという名の売上レコードを挿入するだけだと
ミスは多そうだし、粗利率や回転率なんかも後々で必要になるとややこしい話になりそうなので
以下のようなこと考えてるのですが、王道みたいなのがあれば教えて下さい。

＊売上明細テーブル＊
品番　名　基本単価　値引　値引後単価　個数　金額　値引コード
1 靴下A　500円 157円 343円 x 2ヶ = 686円　A　
2 靴下B　500円 157円 343円 x 2ヶ = 686円　A
3 靴下C　500円 157円 343円 x 3ヶ = 1029円　A
省16

69(11): 03/12/10 21:34 ID:6/7ibqHE(1) AAS
T字型ERで教えていただきたいのですが、
会社で社員が部門に所属しているのを表すとき、
社員（社員コード、氏名）　部門（部門コード、部門名）　所属（社員コード、所属部門コード）
のようになるようなんですが、T字型でないERの場合は
社員（社員コード、氏名、所属部門コード）　部門（部門コード、部門名）
となると思うのです。
T字型ERでは所属というのを設ける理由はなにでしょうか？

79(4): 04/01/01 20:26 ID:??? AAS
>>69-78
そのモデルだと所属が変わったときにその事実がどこにも残らないだろ。

モデリング対象の会社に社員の所属変更があるのなら、
配属イベント（配属コード、社員コード、部門コード、配属日）を置く。
そこから所属（＝指定日付における所属状態）がすべて再現できる。

84(3): 04/01/02 15:13 ID:??? AAS
>実際、一人の社員が複数の部署に所属し得るという事実を表現するのには
>>>69のモデルで十分だし、それは所属変更がありうるとしても変わらない。

うーん、やっぱり設計と業務分析の区別がついてないね？
>>69のは、テーブル設計（設計の成果物）としては有りだが、
モデル（業務分析の成果物）としてはおかしいんだよ。
ここはモデリングのスレだろ。

108(4): 04/02/13 17:07 ID:??? AAS
>>106
長年の疑問だが、商品マスタの単価の扱いは、どうするのがベストなのだろう。

COBOLの時代なら、同一レコードに単価項目を２つ（新旧）持ち、適用年月日
で判断するというのが一般的だったけど。

厳密に正規化すれば、単価は、商品マスタとは別に、
商品単価マスタ｛商品コード、適用年月日、単価｝を作ることになるけど、
この場合、適用年月日の判断が入るため、SQL一発で単価を取得できない。
そこで、ストアド・ファンクション使ったりするのだけど、内部的には結局カーソル
処理を行うことになる。

一方、旧来のCOBOL的なレイアウトだと、OracleならDecode関数で、一発取得
省3

112(5): 04/02/14 09:17 ID:CE18kft9(1) AAS
>111

:問い合わせ年月日時点の単価を求めたい場合

select A.商品名, B.単価
from 商品マスタ A
join 商品単価マスタ B on ( B.商品コード = A.商品コード )
where A.商品コード = :問い合わせ商品コード
and B.適用年月日 <= :問い合わせ年月日
and not exists (
select * from 商品単価マスタ
where 商品コード = A.商品コード
省3

137(4): 04/06/29 00:24 ID:4yFnbnwy(1) AAS
総勘定元帳のテーブル作ってみたら凄い横長になっちまったんですが、どうしたもんでしょう・・・

部門コード、勘定科目コード、繰越残高貸借区分、繰越残高、当年借方第１月金額〜当年借方第１２月金額、
前年第１月実績金額〜前年第１２月実績金額

・・・とまあ基本がこんなんで、これにさらに配賦と予算（当年・前年で各月ごと）を入れると
物凄い長さになるんですが、こういうものなんでしょうか？

やはりカラムに年や月を作ってレコード分けてしまうべきなんでしょうか？
どなたか有効な意見をいただけると幸いです

146(3): 04/07/08 22:31 ID:??? AAS
Ｔ字型ＥＲってどうですか？

156(3): 04/09/25 01:29 ID:axxmUZh0(1) AAS
>>154
でも担当者を横一列に並べようとする時に
正規化するとめんどくさいですね。

明細がぶらさがるとかじゃなくて
5人って決まってる場合は
そういう出力の仕方の方が多くないかな。

でも>>154の要件もあるかも知れないし
出力する局面でどっちにするか判断するって
ところじゃないでしょか。

175(3): 04/10/18 16:18 ID:??? AAS
先生
名前・メールアドレス・パスワード・他色々

生徒
名前・メールアドレス・パスワード・担当先生・他色々(先生と全く同じパラメータ)

という構成の場合どういう設計にすべきですか？

(1)
先生
先生id(主キー),名前,メールアドレス・パスワード,他色々

生徒
生徒id(主キー),名前,メールアドレス・パスワード,先生id(外部キー:先生->先生id),他色々
省15

219(3): 05/01/28 03:58 ID:??? AAS
[発注見出]と[発注明細]があって、それに対応する[支払予定]があります。
[支払予定]は、見出単位で決定する場合と、明細単位で決定する場合の
２通りあるんですが、この場合のテーブル設計はどうすればよいだろう？

[発注見出] 発注NO、支払予定NO
[発注明細] 発注NO、行番、支払予定NO
[支払予定] 支払予定NO

こんな感じでいんだろうか？
なんかすっきりしないんだけど・・・・・・もう、まる一日以上なやんでます .... orz

268(3): 2005/04/17(日)01:09 ID:R6dX5cU6(1) AAS
いや、ユーザー情報テーブルとは別に投票結果テーブルを作りますので、
主キーは前者だけに設定するつもりです。

こんな感じ

ユーザー情報テーブル
ID（主キー）メルアドパスワード他
001 a@a.a pass1
002 b@b.b pass2

投票結果テーブル
ID 設問ID 回答NO
001 01 9
省5

293(3): 2005/06/06(月)14:46 ID:??? AAS
>>292
俺の学校では違ったなぁ・・・

小・中学校では出席番号は生年月日の早い順。
高校での出席番号は五十音順だった。

ただ、転校生やらが入ってきた場合はその都度、出席番号が変わっていた。
つまり、再度、生年月日やら五十音で並べ替えられる。

316(3): 2005/06/12(日)11:13 ID:??? AAS
WEB+DB PRESS特別総集編みました。
関係箇所がVol.11とVol.21に出てました。
どちらも著者は羽生彰洋さん。

少し説明すると、この中では、
意味無し連番->アイデンティファイア=ID=識別子=FKで使用JOIN用
認識容易番号->ビジネス上のコード体系=アクセスパス
としており、一見さんに対する顧客コードのつけ方や、
商品開発で開発の最初でコードが決まりにくい場合の例などで、
意味無し連番と認識容易番号を分けて考えて両方採用する
ことが大事である、と。詳しくは本文を。T字形の影響も
省5

344(3): 2005/09/04(日)04:09 ID:hkkDWCwF(1) AAS
>>335
これはRDBMS(ER図)の限界として、とてもよく出てくる典型的な問題ではないかな？
商品をオブジェクトとして保存できるのであれば、
商品基礎クラスを継承した３つの商品クラスを別途用意してしまえばいい。

でも、RDB使ってるなら当然そんなことは出来ないので、解決策としては
（１）１つの商品テーブルを作って、そこに全部の項目を用意する
（２）３つの商品テーブルを別に作る
のどちらかを採用することになる。

これらはどっちが正しいということは無くて、状況に応じて使い分ける。
テーブルを分けると後で検索にjoinを多用しないといけなくなるので、
省1

387(4): 2006/03/10(金)08:45 ID:pPH8uClm(1) AAS
最近？でも無いのかも知れないけど、IDとCDの使い分けを
推奨する読み物を見掛ける事があるのですが実際の所どう思います？

●定義
ID:ユーザが意識しないシステム上での識別子
CD:ユーザが意識する識別子

この定義までは、同意です。

この後、CDを使う場合は、IDを主キーとし、
CDには、ユニークインデックスを張るという解説がよくみるパターンです。

この通りに進めると確かにCDは変更できるのですが、
モデルが複雑になりアプリの開発工数が確実に増えます。
省5

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は見当はずれだから気にしないほうがいい

上下前次1-新書関写板覧索設栞歴

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 2.255s*