【より良い】データモデリング【モデルを】
>>486
レスありがとうございました。
これでスッキリしましたので先に進めそうです！！
http://iqlveq.cn cheap mp3 downloads http://itdvmb.cn mp3 player downloads MySQL4.1、5.0でも DBDesignerは使えますか？
>>384 に同じ現象が書かれているのですが・・・
バージョンアップされてないからなぁ＾＾；
住所録のデータベースのモデルです。
取引先の会社とその担当者、お客様とその家族、
と、全部で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テーブルで済まないの？
これだと、多重構造が可変でも耐えられるでしょ？
また必要とあれば語るだろう。
あなたはどうなのか。 _
|O＼
| ＼ ｷﾘｷﾘ
∧|∧ ＼ ｷﾘｷﾘ
ｸﾞｸﾞｩ>（；⌒ヽ ＼
∪ | (~)
∪∪ γ´⌒｀ヽ
） ） {i:i:i:i:i:i:i:i:}
（ （ ( ´･ω･)、
(O ⌒ )O
⊂＿)∪ ※本投稿の拡散歓迎です。
違法派遣（偽装請負・多重派遣・偽装出向・事前面接等）についての刑事罰
【告訴権者＝業務委託、準委任、共同受注、業務請負契約および特定派遣（契約・正規）、一般派遣、正規社員】
①職業安定法第４４条の労働者供給事業の禁止規定に違反（1年以下の懲役または20万円以下の罰金）
■偽装請負・多重派遣・偽装出向・多重出向
■事前面接（顔合わせ・面談・職場見学等）と履歴書・職務経歴書・スキルシート等提出による労働者の特定(※）
（音声録音で立証可能）
②労働基準法第６条（中間搾取の禁止） (1年以下の懲役又は50万円以下の罰金)
■多重派遣・多重出向
※違法派遣（派遣労働者の特定）→派遣法で認められた派遣労働者ではない→労働者供給事業→職業安定法44条違反というの
が前提となる法解釈となります。派遣法における罰則が軽微なのは法律の不備や労働者軽視などが原因ではありません。
違法派遣は全て職業安定法44条で裁くことが可能なため、刑罰の重複を避けるために派遣法には軽微な罰則（主に裁量行政による）しかないのです。
使用者に有利な民事訴訟や労働関係諸局への通報等の対極にあるのが書面（告訴状）による刑事告訴（※告訴先は検察の直告班）です。
労働関係諸局への通報・斡旋による軽微な「適正化」や監督・指導に対して、法律に定められた刑事罰を問うことになり、
違法派遣業者にとって有罪は考えられる限り最大の処罰となります。同時に刑事罰を受けた
担当者が取引先に与える悪印象を考慮すれば、通常会社側は告訴が受理された時点で告訴取り下げに
動くのが妥当でしょう。懲役、前科がつく刑罰が下される可能性から、告訴取り下げの和解金は高額となることが多いのです。
告訴の流れとしては、
刑事告訴⇒告訴受理⇒告訴取下げ要請⇒取下げ和解金入金⇒告訴取下げ
となります。告訴の懲役刑適応は犯罪者個人に対してのみですので、告訴する対象は
派遣先・派遣元 社長
派遣先・派遣元 担当者・責任者・管理役員・取締役
派遣先・派遣元 人事管理担当者・人事管理役員・取締役
が妥当です。刑事告訴取り下げの和解金額は犯罪者個人と交渉するとよいでしょう。（告訴状は人数分提出する必要あり） お知らせ
市原警察署の生活安全課の帰化人創価警官の指導の元、
入学式から2週間ほど、在日の創価学会員を主体とした自称防犯パトロールが、
2週間ほど行われることになりました
生活安全課の指導であることと、パトロールであることは、
絶対に公言してはいけないとの指導も、帰化人創価警官より出ています
期間中は2人組の在日の創価学会員が、頻繁に創価批判者の自宅周辺を、
うろつき回ると思われます
日本人の方は、充分に注意してください 設計のほうが(データモデリングよりも)広い用語だろな
つまり、すべてのデータモデリングは設計の一種だけど、
逆は必ずしも真にはならない
データモデリングはDB設計の中でも上流工程の作業を指し「概念設計」とも呼ばれる
具体的には、現実世界の事物をコンピュータの内部表現に近い
エンティティとリレーションの集合で定義する作業になる
そして、これによって完成したモデルを利用するミドルウェアやフレームワークに
合わせて具体化する作業が「実装設計」になる
実装設計が終えれば(詳細設計もしくは)コード設計が待っている 業務系ってクラスモデリングよりもデータモデリングが主流なんでしょうか？
単に興味本位で聞いただけです。 >>530
業務システムはデータ中心主義だからね。 パリテロはやっぱりヤラセ！
クライシス・アクターさんがスターダムに！ 早くも偽旗作戦の証拠映像が挙がりました！
ボストンテロとパリ襲撃事件テロ両方に居合わせた世界一不運な女性ですｗ
◆BOOM! Exposed Crisis Actor from Sandy Hook and Boston Bombing found at Paris False Terrorist Attack
https://twitter.com/hotaru123a/status/665888328193937408
ＩＳＩＳに襲撃されたパリのバタクラン劇場のオーナーは２０１５年９月１１日に劇場を売却済み。
https://twitter.com/tokai amada/status/665992523878301696 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
A8RNOMREE3 
