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

>>480
遅くなりまして申し訳ございません。
レスありがとうございました。

質問１について
なるほど、確かにデータ編集時に、複合主キーより単独主キーでアクセスした方が
SQL文も簡単に記述でき、何かと便利が良さそうですね。

教えて頂いた方法で実装しようと思うのですが、
�@の方法(各エンティティに単独の主キー(PK)を設けて、親への参照キー(FK)をそれぞれ持たせる)で
きちんとした正規化を行う場合、工程の製品id(FK) と 実績の製品id(FK), 部品id(FK)も要らなくなり、
次のようになるはず？(１階層上の親id のみ 持たせる)
この理解で問題ないでしょうか？

製品: 製品id(PK), 製造指示No, 型番...
部品: 部品id(PK), 製品id(FK), 部品区分, 部品cd, 部品数...
材料: 材料id(PK), 部品id(FK), 仕入先cd(FK), 寸法...
購入品: 購入品id(PK), 部品id(FK), 仕入先cd(FK), 購入品品番(FK)...
工程: 工程id(PK), 部品id(FK), 工程cd, 工程手順No, 標準時間, 数量...
実績: 実績id(PK), 工程id(FK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...

もしくは、材料id, 購入品id は持たず、次のようにする。

製品: 製品id(PK), 製造指示No, 型番...
部品: 部品id(PK), 製品id(FK), 部品区分, 部品cd, 部品数...
材料: 部品id(PK), 仕入先cd(FK), 寸法...
購入品: 部品id(PK), 仕入先cd(FK), 購入品品番(FK)...
工程: 工程id(PK), 部品id(FK), 工程cd, 工程手順No, 標準時間, 数量...
実績: 実績id(PK), 工程id(FK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...

続きです。
>>480
遅くなりまして申し訳ございません。
レスありがとうございました。

質問２について
やはり集計用の別テーブルを設けた方がいいのですね。
今回のケースで集計テーブルを用いるとすれば、次のような感じでよろしいですか？
集計元テーブルと集計先テーブルは(１：１の関係）になる。
また本来は集計テーブルに主キーの項目として集計日を含むと思うのですが、
今回は集計日が要らないので外します。

製品: 製品id(PK)... → 製品別原価: 製品id(PK), 材料費計, 購入品費計, 労務費計...
部品: 部品id(PK)... → 部品別原価: 部品id(PK), 材料費計, 購入品費計, 労務費計...
工程: 工程id(PK)... → 工程別原価: 工程id(PK), 労務費計...

もしくは、集計テーブルにも単独主キーを設けて、次のようにする。

製品: 製品id(PK)... → 製品別原価: 製品別原価id(PK), 製品id(FK), 材料費計, 購入品費計, 労務費計...
部品: 部品id(PK)... → 部品別原価: 部品別原価id(PK), 部品id(FK), 材料費計, 購入品費計, 労務費計...
工程: 工程id(PK)... → 工程別原価: 工程別原価id(PK), 工程id(FK), 労務費計...


以上、質問ばかりで申し訳ございませんが
宜しくお願いします。

パソコンショップならここ！！
http://want-pc.com

6ehkeP <a href="http://dphojlgmqyum.com/">dphojlgmqyum</a>, [url=http://dciuxyoglilw.com/]dciuxyoglilw[/url], [link=http://jupungwigput.com/]jupungwigput[/link], http://tltjzxqojqqo.com/

aVR2l3 <a href="http://mxmpbpvmprfm.com/">mxmpbpvmprfm</a>, [url=http://yrgjgiqgeori.com/]yrgjgiqgeori[/url], [link=http://xppokryehkqp.com/]xppokryehkqp[/link], http://pnlqzfhrtylu.com/

>>481
OKと思われ。

>>482
OKと思われ。まぁ、こっちは単独主キー無くてもいいかも知れんが

>>486
レスありがとうございました。
これでスッキリしましたので先に進めそうです！！

http://ublog.union.edu/elpinner/88 buy zovirax

http://iqlveq.cn cheap mp3 downloads

http://itdvmb.cn mp3 player downloads

http://kgnsye.cn/imax-california.html Imax california
http://kgnsye.cn/california-dept-of-corporation-htm.html California dept of corporation htm
http://kgnsye.cn/single-family-homes-carlsbad-california.html Single family homes carlsbad california
http://kgnsye.cn/archangel-tattoo-design.html Archangel tattoo design
http://kgnsye.cn/blue-book-pricings-for-atv.html Blue book pricings for atv

http://bfsnbw.cn/mp34 free memory

MySQL4.1、5.0でも　DBDesignerは使えますか？

>>384 に同じ現象が書かれているのですが・・・
バージョンアップされてないからなぁ＾＾；

A C

n1ywUN <a href="http://vdgsdgcxvewl.com/">vdgsdgcxvewl</a>, [url=http://ltldczvyogvo.com/]ltldczvyogvo[/url], [link=http://dznjgohehaza.com/]dznjgohehaza[/link], http://whxrulsmcetw.com/

住所録のデータベースのモデルです。
取引先の会社とその担当者、お客様とその家族、
と、全部で4つのテーブルを作成しました。
それぞれのテーブルには、名前や電話や住所などの
列を並べました。

そこで疑問になったのが。
取引先の住所と担当者の住所は、共通する事もある（し違う事もある）。
家族の住所と個人の住所は、共通する事もある（し違う事もある）。
と、考えると。
住所部分のみでテーブルを作成して、4つのテーブルから
参照した方がいいのかな？とも思ったのですが、いかがでしょう？

そうね。それなら取引先が複数住所もってるケースにも対応できるね

取引先が複数住所を持ってるケースは考えていませんでしたが。
確かにおっしゃる通りで、良さそうですね。

また、営業所が移転した場合や家族が引っ越しした時に、
同じ住所テーブルを示していれば、個人の住所も一括で
修正されますね。ありがとうございました。

1レコードに開始/終了時刻を持って「状態」を記録するメリットって何？
開始/終了イベントテーブルにそれぞれ発生時刻を記録するほうがいいと思うんだけど

>>499
イベントテーブルにそれぞれ記録するほうがいいのは
たとえばどんな時でしょうか？

>>499
抽出したエンティティの意味的な違いに優劣はないから実用上のメリットで言うと、
所要時間を求めるようなクエリでjoinを節約できるとか。
逆に挿入/更新でコストはかかっているわけで、メリット/デメリットともに
事前集計表と似たようなもの。

保守

状態が欲しい場合も無く無いと思うけどなあ。


導入事例ってあんまり当てにならないのか。まあそもそも営業資料だしね。
導入されても、実際十分に活用されてるかどうかや、現在も使われてるかどうかはわからないしなあ。

町場の工務店用データベース作成のためこんな感じのＥＲ図を作成してみたのですが
もし問題があれば指摘していただけるとありがたいです。　
http://niyaniya.info/pic/img/2186.jpg

業務の基本的な流れは　見積作成⇒請負契約⇒ 工事 です。オリジナルはもうすこしマスタテーブルが
増えて複雑なのですが、基本はこんな感じです。　よろしくお願いします。　

>>504
普段、IDEF1Xでしか読み書きしてないから、リレーションシップの
意味が正しく理解できてるかわかんないのと、業務要件が不明だから、
自分の所見でコメント。
（１）「見積明細」の主キーは”見積ID”では？。
　　「見積明細」は「見積」のサブタイプということだと思うけど、
　　意味があって分けてるのかな？
（２）「請負契約明細」についても（１）と同様。
（３）「請負金額入金」「請負金額請求」は、「入金」「請求」として
　　独立エンティティにするか悩むところ。
　　入金単位や請求単位が請負契約単位なのかな？
　（１契約で入金は複数回とかないのかな）
（４）何故「仕入契約」「下請契約」は"業者ID"が主キーに
　　なってるのに、「請求契約」の方には”顧客ID”が主キーに
　　なってないの？　この違いの意味は？
　　両方とも<契約>という同じような意味のエンティティと
　　考えれば、その属性も同じような主キー構成で
　　いいと思うけど。

※属性なしで、エンティティ名だけでリレーションシップを
　考えた方がわかりやすいですよ。

>>505
レスありがとうです！

ありがたい指摘なのですが理解する語彙が足りずアドバイスを生かしきれないのが
残念ですが・・・

(1)で言われた「見積明細」テーブルは、本来「見積」テーブルと一体の繰り返し要素を別テーブルに分離した
もので主キーは設定していません。　１つの見積に対して複数の見積項目があるので２つのテーブルに分離しました。　
販売業者における販売テーブルと販売明細テーブルのような関係です。

(2)の「請負契約」と「請負契約明細」も同様の関係です。

(3)の「請負金額入金」「請負金額請求」は確かに一つのテーブルに統合できそうです。
盲点でした・・ありがとうございます。

問題は(4)でして、、、『なぜ「請負契約」の方には顧客IDが主キーになっていないのか』
との指摘ですが、　請負契約の場合、１つの契約に相手となる顧客は１つだけなのですが、下請契約や仕入契約は
１つの工事に相手となる業者は複数に及ぶことがあります。　その質の違いから差が生じたと思います。　

これがはじめてのデータモデリングで試行錯誤の結果ですのでもしかしたら基本的なところで誤理解をしてる可能性
ありですので・・・その程度のもんだとオモっていただけるとありがたいです。

明細テーブルにも主キーはつけるべきだよ。
この場合は表示順を主キーにすりゃいいんじゃないかな。

> (3)の「請負金額入金」「請負金額請求」は確かに一つのテーブルに統合できそうです。

統合すると請求1回に対して入金複数回のケースとか対応できなくなるよ。
あなたんとこの業務的には問題ないのかも知れんけど、
柔軟性保つために分けておいたほうがベター

主キー入ってないテーブルがあること以外は、大体OKそうに見えるね。
>>505は見当はずれだから気にしないほうがいい

> この場合は表示順を主キーにすりゃいいんじゃないかな。

ごめん、親テーブルの主キー＋表示順というつもりだった。
たとえば見積明細では（見積ID、表示順）を主キーにする

>>506
505です。今日は何故か眠れないのでレス
ちょっと説明がまずかったみたいなので、まず用語から。
※文中の用語はググってね。
エンティティ＝テーブル
属性＝列項目
主キー＝（簡単に言うと）一意に行を特定できる列項目

（１）の、「１つの見積に対して複数の見積項目がある」という
のは、「見積」１行に対して「見積明細」複数行という意味であれば、
「見積明細」テーブルの主キーは、”見積ID”と、明細を識別する”明細ID"
みたいなのが必要。（用語的には第２正規形）

（２）も同様。

（３）はそういう意味ではなくて、「契約」「請求」「入金」と、
それぞれ独立した（主キーを持つ）テーブルにしても良いのではという意味。
データモデルを考えるときに、業務の実態を、リソース（資源：名詞）と
イベント（出来事：動詞）に分けて、テーブルとして考えるのだけど、
例えば、
リソースは、「社員」「顧客」「業者」で、
イベントは、「見積」「契約」「請求」「入金」「工事」「支払」
なわけだ。

以上

>>507
どこが見当違いか、指摘してもらえるとうれしいね

>>507
もしかして、（１）でサブタイプって書いたことを見当違いって
言ってるのかな？
エンティティ名だけ見ると、第２正規形を意識したと思えたけど、
もしかして主キーが同じで、あえて分けたのかと深読みしただけ
なんだけどね。

（３）は509で書いた通り。
（４）は、業務要件わからないから、所見てことで、
主眼を「請負契約」と同様に<<契約>>に置いてもいいかなと思ったのさ。

よろしく。

あのさ、「明細」ってかいてあんのにピンと来ないようじゃお話にならないと思うよ。

>>507
＞明細テーブルにも主キーはつけるべきだよ。
この場合は表示順を主キーにすりゃいいんじゃないかな

なるほど！　これは勉強になりました。　キーはテーブルの結合しか用途がないもの
だと思っていたのでそういう使い方が出来るのは初めて知りました。

＞主キー入ってないテーブルがあること以外は、大体OKそうに見えるね。
>>505は見当はずれだから気にしないほうがいい

いえいえ皆さんのアドバイスは大変勉強になります。　

>>509
＞「見積明細」テーブルの主キーは、”見積ID”と、明細を識別する”明細ID"
みたいなのが必要。（用語的には第２正規形）

たしかにおっしゃるとおりです。　明細テーブルの各行を識別するキーも必要ですね・・・。
ここらへんはまったくノーマークでしたのでありがたい指摘です。　　その意味で
見積明細にも見積IDを主キーに設定すべきと仰っていたのですね。　私の間違いでした・・・

＞データモデルを考えるときに、業務の実態を、リソース（資源：名詞）と
イベント（出来事：動詞）に分けて、テーブルとして考えるのだけど、

この辺はいまの自分にはちょっと高度です　もうちとレベルアップしてからアドバイスを
生かさせていただきます^^;

高度ってあんた・・・

>>512
まぁ、そう言いなさんな。所見で深読みしたけどさ。
最初の図（モデル）から想像したのは、子エンティティの
外部キーについて、親エンティティからのキー移行だけを間違えて
記述したものと深読みしたということ。
（よって、排他的サブタイプと見たわけ）
業界／業務要件が不明なので、モデルから判断するだけ、つまり、
名称（用語）でエンティティを安易に想像してはダメってことも
あるからね。（話をよく聞かないうちに決めつけちゃダメさ）
ちなみにウチの所でも、第２正規化の結果を「XX」「XX明細」と
してるよ。

スレ汚しスマソ。

みなさんのご指摘を参考に最終的に↓のように仕上げてみました。これでなんとか
やってみようと思います。　どうもありがとうございましたです！
http://niyaniya.info/pic/img/2219.jpg

業務知識が無いと、まともな設計が出来ない見本だな。
運用で不具合出まくるだろうなあｗｗｗ

五階層まで登録できる工事の見積システムのデータモデリングをしてるのですが
↓こんなかんじでどうでしょう^^; 　

http://imepita.jp/20090604/333030
項目A→項目B→項目C→項目D→項目E　と具体的になっていく感じです

例）　電気→3LDK標準電気工事→玄関→外部玄関等→照明器具 DWP-3524DS

項目Aによって必要な階層がことなるので動的に階層を変更できればいいのですが、、

>519
階層構造を柔軟にとか考えると、
所要量展開、再帰、LLC、
部品展開、原価計算、
といったところをある程度考慮して取り入れながら
設計するのかなと思う。
これらでぐぐってみてもよいかと。

>>519
その前に親子関係は1対多なんだよね？
何もテーブルを幾つも作らなくても、
子情報が主キーでそこに親情報が従属するような
再帰的な1テーブルで済まないの？

これだと、多重構造が可変でも耐えられるでしょ？

目指してる 未来が違う　ｂｙシャープ
http://twitter.com/saramura6/statuses/6688087715352576　

もう語らないのか

また必要とあれば語るだろう。

あなたはどうなのか。

　　　　　 _
　　　　　 |O＼
　　　　　 |　　 ＼　ｷﾘｷﾘ
　　　　∧|∧ 　　＼　ｷﾘｷﾘ
ｸﾞｸﾞｩ>（；⌒ヽ　　　 ＼
　　　　∪　　|　　 　　(~)
　　　　　∪∪　　 γ´⌒｀ヽ
　　　　　）　）　　 　{i:i:i:i:i:i:i:i:}
　　　　 （　（　　　　(　´･ω･)、
　　　　　　　　　　　(O ⌒　)O
　　　　　　　　 　 　⊂＿)∪

※本投稿の拡散歓迎です。
違法派遣（偽装請負・多重派遣・偽装出向・事前面接等）についての刑事罰
【告訴権者＝業務委託、準委任、共同受注、業務請負契約および特定派遣（契約・正規）、一般派遣、正規社員】

�@職業安定法第４４条の労働者供給事業の禁止規定に違反（1年以下の懲役または20万円以下の罰金）
　■偽装請負・多重派遣・偽装出向・多重出向
　■事前面接（顔合わせ・面談・職場見学等）と履歴書・職務経歴書・スキルシート等提出による労働者の特定(※）
（音声録音で立証可能）
�A労働基準法第６条（中間搾取の禁止） (1年以下の懲役又は50万円以下の罰金)
　■多重派遣・多重出向

※違法派遣（派遣労働者の特定）→派遣法で認められた派遣労働者ではない→労働者供給事業→職業安定法44条違反というの
が前提となる法解釈となります。派遣法における罰則が軽微なのは法律の不備や労働者軽視などが原因ではありません。
違法派遣は全て職業安定法44条で裁くことが可能なため、刑罰の重複を避けるために派遣法には軽微な罰則（主に裁量行政による）しかないのです。

使用者に有利な民事訴訟や労働関係諸局への通報等の対極にあるのが書面（告訴状）による刑事告訴（※告訴先は検察の直告班）です。
労働関係諸局への通報・斡旋による軽微な「適正化」や監督・指導に対して、法律に定められた刑事罰を問うことになり、
違法派遣業者にとって有罪は考えられる限り最大の処罰となります。同時に刑事罰を受けた
担当者が取引先に与える悪印象を考慮すれば、通常会社側は告訴が受理された時点で告訴取り下げに
動くのが妥当でしょう。懲役、前科がつく刑罰が下される可能性から、告訴取り下げの和解金は高額となることが多いのです。

告訴の流れとしては、

刑事告訴⇒告訴受理⇒告訴取下げ要請⇒取下げ和解金入金⇒告訴取下げ

となります。告訴の懲役刑適応は犯罪者個人に対してのみですので、告訴する対象は

派遣先・派遣元 社長
派遣先・派遣元 担当者・責任者・管理役員・取締役
派遣先・派遣元 人事管理担当者・人事管理役員・取締役

が妥当です。刑事告訴取り下げの和解金額は犯罪者個人と交渉するとよいでしょう。（告訴状は人数分提出する必要あり）

お知らせ

市原警察署の生活安全課の帰化人創価警官の指導の元、
入学式から2週間ほど、在日の創価学会員を主体とした自称防犯パトロールが、
2週間ほど行われることになりました

生活安全課の指導であることと、パトロールであることは、
絶対に公言してはいけないとの指導も、帰化人創価警官より出ています

期間中は2人組の在日の創価学会員が、頻繁に創価批判者の自宅周辺を、
うろつき回ると思われます
日本人の方は、充分に注意してください

データモデリングと設計って違うの？

設計のほうが(データモデリングよりも)広い用語だろな
つまり、すべてのデータモデリングは設計の一種だけど、
逆は必ずしも真にはならない

データモデリングはDB設計の中でも上流工程の作業を指し「概念設計」とも呼ばれる
具体的には、現実世界の事物をコンピュータの内部表現に近い
エンティティとリレーションの集合で定義する作業になる
そして、これによって完成したモデルを利用するミドルウェアやフレームワークに
合わせて具体化する作業が「実装設計」になる
実装設計が終えれば(詳細設計もしくは)コード設計が待っている

　業務系ってクラスモデリングよりもデータモデリングが主流なんでしょうか？
単に興味本位で聞いただけです。