【より良い】データモデリング【モデルを】
>>407
じゃあ、ナウでヤングなモデリングを教えてくだされ。 Ｔ字形って、認知番号重視なのは解るけど、
わざわざ主キーを非明示にする理由がわからん。
データモデリングはどのような書籍で勉強しましたか？ >>411
えー。
ＤＢ屋以外の関係者との会話に使えないような記法はどうかと思うけど。 Ｔ字形の新しい本を読んで思ったのは．．．
あの理論編の哲学議論がまさに「言語ゲーム」。 ヲウムと同じだよね。
悟り開いて宙に浮く様になれば尊師の教えが分かるよって感じ。
傍から見てるとDQNにしか見えない罠。 そうはいかんよ。
従来のＥＲ手法でエンティティとリレーションを同時並列的に検討するのは、
純粋な「実体主義」も、純粋な「関係主義」も、現実的には極端すぎるから両方を同等に扱いましょう、
ていうのが背景にあると思う。（明示的にではないにしろ）
それを“実体主義のほうが本質的で、だからエンティティーを重視するんだ！”って主張するんだったら
そのへんをちゃんと論理的に、かつ皆が納得できるように説明してくれないと．．．
あの理論編は、ぜんぜん「理論」になってなくて、いろんな哲学のオイシイ結論を寄せ集めただけに見える。
だってボク、クリプキ好きなんだもん、とか言われても困っちゃう。 実践編、かなり有用と思うよ
でも、たしかに理論書としては、ちゃんと筋道たてて説明してない感じがする。
論理の飛躍がある、というより、断片を継接ぎした結果みたいな。
モデリングって学問としてあるわけじゃないのかな・・
奥が深いし、博士号取得した哲学者や数学者がもっと研究してほしい 計算量の上界値、下界値ってどういうことなんですか？
上界値＝計算量が最大と思われる値？ それより大きいことはありえないと保証できる値
てか板ちがい >>423
レスありがとうございます。
では、これはどこの板行けばいいんですかね？プログラム板ですか？ Visioって作ったモデルからCreate文生成したり,DBに直接テーブル作成したりできるん？ 新しい職場で、設計がやたら縦持ちになってるんですが、縦持ちってポピュラーな方法なんですか？
扱いにくくってしょうがないんですが。 >>425
VisioのProfessional版を使っていて、できそうだったのでちょっとやってみたら
「Enterprise Editionを使え( ﾟДﾟ)ｺﾞﾙｧ！」と言ってきました｡インスコしてないので試せないが､
Enterprise版を使えばできると思われ。MSDNにはついてきていると思う｡
Create分まで作りたいんなら、VisioよりDBDesigner4を勧めたい 仕様書作る時にはvisioのほうが便利。
実装と文書化の二度手間のほうが苦痛。 仕様書ってどういうレベルのもの言ってんだ？
DBDesignerでもER図やDB定義書くらい作れるぞ 客と下請けに提出する清書レベルだよ。
手書き程度ならチラシの裏に落書きで十分だし。 レスくれた方ありがとうございました。Visio for Enterprise Architects
というバージョンで出来ました。
ところで、教えていただきたいことがあるのですが、3種類のコードが組み合わさって
出来ているコードがあるのですが
AAABBCC
コードA VARCHAR(3)
コードB VARCHAR(2)
コードC VARCHAR(2)
こんな感じです。AとBとCは親－子－孫の関係にあるのですが
この親－子－孫を表せるようにモデリングするにはどうしたらよいでしょうか・・・・ >>434
親＝PK:|AAA|
子＝PK:|AAA|1-n|BB|
孫＝PK:|AAA|1-n|BB|1-n|CC|
かな？
んで。気になるのは。各コードは固定長でなく可変長なんですか？？ >>435
あ、固定長です。
>親＝PK:|AAA|
>子＝PK:|AAA|1-n|BB|
>孫＝PK:|AAA|1-n|BB|1-n|CC|
これは、まさしくこんな関係です。 あるリソースエンティティ同士の関係を表すのに
交差エンティティを作成するという例はよく見かけるのですが、
イベントエンティティ同士の関係についても交差エンティティを作成するという
事はあるのでしょうか？
たとえばある複数の勘定科目から出金して、出金した額を別の種類の複数の
科目へ入金するといった作業があるとして、出金エンティティと入金エンティティ
との関係はどう表したらよいのでしょうか。 >>437
交差エンティティって呼ぶのかどうかは知らないけど、
そんなようなものは必要に応じて当然作るよ。
○親テーブル
PK1 PK2
入金No.010 出金No.101
入金No.011 出金No.102
○子テーブル-入金
PK1 PK2
入金No.010 勘定科目A 1,000
入金No.010 勘定科目B 2,000
入金No.011 勘定科目C 200
○子テーブル-出金
PK1 PK2
出金No.101 勘定科目Y 2,500
出金No.101 勘定科目Z 500
出金No.102 勘定科目A 200
DB作る前に簿記の勉強したほうがいいね。
帳票をそのままDBにすればおk。 つまらない質問で申し訳ないのですが、
顧客IDなどのコードの作成方法は
決まっているのでしょうか。
社員番号なら入社年月日＋連番
などでいいと思うのですが、
何か指針はあるのでしょうか。 連番も何桁取るとか有るよ。２桁じゃ１００人入ったら終わり。
総務や人事と打ち合わせて決めたほうがいいよ。
全社的に統一しないと意味がない。
顧客コードなら営業とかと打ち合わせて決めるべき。
営業上、顧客の元に自社の顧客番号が付いたものが送られるし、「ああ、うちって１００社目なんだな」って推測されちゃうような顧客IDは恥ずかしい。 設計するのに使ってるツールとか教えて！
XEADとかJude、ObjectBrowserERあたりがよさげなんですが！！
今試そうと思ってるのがOracle JDeveloper10g！！！ >>445 さんへ
XEADは、どこら辺が駄目だと思いますか？ ナチュラルキーとサロゲートキーって使い分けどうしてますか？
顧客マスタとか商品マスタみたいなのはナチュラルキー、
受注TRとか売上TRはサロゲートキー、
仕様変更が多そうならサロゲートキー多め、
ERモデリングツール使うならナチュラルキー、
ORマッピング使うならサロゲートキー、
こなかじ？ 佐藤 正美氏が提唱する「Ｔ字形ＥＲ」ってどうなんでしょ。会社の上司が
信者（？）で何が何でも導入したいみたいで。。。本を読んでみたけど
文章表現は下手（だと思った）だし理論にしても判り辛いような。。。
数千人規模の会社の基幹業務構築のモデリングには大丈夫なのかな～？
と思ってます（例えば数年後には理論自体廃れてるとか・・・）。 >>449
いいところはresource概念とevent概念云々のところぐらいか
あとはちょっと・・・。identifierの扱いがアレなんで、あの理論をそのまま適用するのは
実際的ではないと思う データモデリングなんて勘でやるのが一番いい。
主キーと関連だけしっかり抑えとけば大概上手くいく。
大事なのは、間違ったモデリングなんてないと知っておくこと 勘でやる時点でだめだめな悪寒。
いろんなモデリングのシミュレーションソフトとかあれば設計時に検証しやすくて便利なのにな。 >>449
基幹ではないが、大手での採用例はあり。
和光市の某自動車メーカとか、麹町の某信販会社とか。
ただ、Ｔ字型を使ったプロジェクトで試行錯誤した経験者がいない状態で
本読んだだけでいきなり実地の大規模システムに適用しようとすると
多大な困難が待ち受けていそうな悪寒が… ＴＭ（Ｔ字形ＥＲ手法）は、CoddのRDBMに始まって、正規化だけでは解決しない問題を検討している間に、
業務系のシステムでは「コード体系」を使って分析するのが便利って便法を思いついたりしながら発展して
きましたが、根っこの部分ではオブジェクト指向におけるドメインモデリングと繋がっています。
なので、#453 の方が言われる様に、本を読んだだけで見よう見真似で始めるのは、少し辛いでしょう。
できれば、本人から習うことが可能なので、それが一番だと思います。
http://www.sdi-net.co.jp/ に行ってみましょう。 ↑
ＨＰ見てみたけど、本当大丈夫なの？かなり素人っぽいＨＰで
すが。コンサルとかやってるんんだったらもうちょっとマシな
ＨＰにした方がいいような。。。
それに実績も書いてないし。>>453 の和光や麹町の会社ではどれだけ
ＴＭにより実績がでたのかな？
コンサルやるなら会社（？）の規模も知りたいなー 麹町では使ってはいるが「お絵かきソフト」程度の使われ方。
「Ｖｉｓｉｏの方が書きやすいじゃん」ってノリだから「ＴＭを
導入してビジネスの強み・弱み・・・」なんて程遠い状態。 >>455
WebPages見てそういう感想抱いたのなら、ＴＭとは出会わなかったことにした方が多分幸せになれる。
いや、煽りや皮肉ではなく、本音ベースの話。
感覚的な「合う」「合わない」っていうのは結構重要な要素かと。 ＨＰ見たけど「1,000,000 ステッフ゜ 規模の システム であれば、10数名で、6 ヶ月以内に導入する。」
ってのは凄いなー。
事例とかあるといいけどね。 優秀なエンジニアが集まればとか、そのための費用を出せるならとか前提条件いっぱいだろ？
まあ優秀なエンジニア集めれば、別に何でも短納期でできそうな悪寒。
そういう論点のすり替えをして一儲けするのがコンサルと言えばそうだけど。 >>458
ステップってコード量だよねぇ？
でコンサルが開発するわけじゃないだろうし、有効なメトリクスなのかね？
コンサルとしてはそういうところ大事だと思うんだが。 画面数とかテーブル数とかユースケース数とかでないとピンと来ない 皆様始めまして。
DBDesigner4の使い勝手が良かったので日本語化してみました（需要アルカナ・・・）
http://dbdesigner.iimp.jp/
使ってみてご意見いただければと存じ上げます。
Delphiはあまり使ったことがないので安定度が下がっているかもしれません。。
あと、、まだWindows版しかコンパイルしていないです・・・。
Linuxはあまり慣れていないもので。。すみません。。。 >447
主キーベースのERDを作成する段階では、ナチュラルキーでモデリングし始め、
全属性ERDを作成する段階で、最終的にサロゲートキーに再設計してる。
（最初はナチュラルキーの方がわかりやすいので・・・）
全部サロゲートキーにしてる理由は、
（１）安定性の確保
：将来のシステム改善などでの主キー属性の設計変更を、極力抑える。
（候補キー自体が安定していることが前提なのに、変わることあるから・・・）
（２）データへのアクセスコストを抑えたい
：ナチュラルキーだと３つ以上のコンポジットとなってしまう場合がある（特に連関エンティティ）
（３）ポリシーの統一
：全エンティティを同じポリシーで設計するため全部サロゲートキー
なんて言い訳でサロゲートキーにしてる。 >>463
>候補キー自体が安定していることが前提なのに、変わることあるから・・・
間違えた。
候補キー -> 主キー FFの武器を管理したいと思っています。
次回のバージョンアップで他のシリーズも同一のテーブルで管理できるようにしたいです。
現在
武器 (武器ID, 攻撃力, 入手場所)
案1
武器テーブルにシリーズNoを追加して、シリーズNo＋武器IDを主キーにする。
シリーズNo | 武器ID
FF1 | 001
FF1 | 002
FF2 | 001
FF3 | 001
...
案2
武器テーブルにシリーズNoを追加して、武器IDは主キーのまま通し番号とする
武器ID | シリーズNo
001 | FF1
002 | FF1
003 | FF2
004 | FF3
案1だと枝番の作成がめんどうなのですが、きれいにナンバリングされる。
案2だとキーの作成は簡単だが、データの入力順を間違えると気持ち悪いナンバリングになってしまう。
どのような場合にどちらがいいか教えてください。 >466
複合キー列への外部キー設定は列が増えてしまって、
子表が増えるほど面倒になるから案2がいいなぁ。どうせ
武器IDなんてもとより意味のあるものじゃないんだし。
もういっそ武器IDは乱数を採番するようにしちゃえば気にならないよ。 1の方がデータ移行は楽そうだな。
最近の流行は2か。アプリケーションフレームワーク的に２のようになってないとあかんものがあるな。
武器リストだと表示順ってのも気にしたいだろうから、
１のテーブルにさらにid列を一つ追加して、
武器IDは表示順的な意味を持たせるのもありかも MySQLのDBDesignerに相当するpostgresqlのツールってありますか？
それとも、postgresqlをodbcで接続して、DBDesignerを使っても、幸せになれますか？ このスレでも何回か見かけるが、簿記の知識がSEにも要求される場合がある。
独学で簿記を勉強しようとすると、書籍を購入して勉強となりがちだが、
項目が羅列してあり説明は最小限のような簿記の書籍ではなかなか理解は進まない(俺だけか)。
簿記の書籍は不親切であり、そのために資格学校が存続できてる気がする。
資格学校に通わなくても資格学校の通信教育等もあるし、それもそんなに高くはない。
さらに講義形式の勉強で一番手軽なのは、資格学校が出版しているDVDビデオの教材がある。
例えば、以下のような教材がある。
合格テキスト講義DVD日商簿記3級 商業簿記 Ver.4.0(10,500円)
DVD6枚組 TAC出版
俺は本屋で買ったが、amazonにもある。講師は違うが2級もある。
これと対になってる書籍(テキスト)も別に売ってるが、なくても特に困らない。
DVDの講義なので、好きなときに何回でも見れる。
これを見てしまうと、いかに市販の書籍で学ぶことが能率が悪いかということがよく分かる。
おそらく簿記の勉強は書籍ではなくて人の話を聞いて学ぶのが一番よいのでは
ないかと思う。「要はこういうこと」みたいな言葉やくどいぐらいの説明は
なかなか書籍には載りにくい。このDVDのテキストも同じ欠点がある。
例えば減価償却累計額について簿記上の具体例を含めて詳しい説明を書籍で
探そうとすると結構大変だと思う。また、講師がしゃべってくれるわけで漢字の
読み方も問題なくなる。この3級の講師は大変よいと思う。きっちりとよく話してくれている。
スレ違いすまん。
まぁ、SEが片手間に勉強するのにむいた教材は確かに少ないかもしれんけど、
たかが3級レベルで分かりやすいも分かりにくいも無いと思うんだが・・・ まったくその通り。10日でわかるとかそういうので十分、
実際は1週間足らず勉強してケアレスミスで落として
90点代後半取れた。 初心者です。
物理データモデルの「内部スキーマ」とは、具体的にRDBMSで
いうところの、どのようなオブジェクトなのでしょうか？
どなたか御教授ねがいます。 >>473
ANSI/SPARC ３層スキーマのことなら、
概念スキーマ：テーブル
外部スキーマ：VIEW
内部スキーマ：物理ファイル定義（oracleだとセグメントかな） >>475さん
ありがとうございます。
ANSI/SPARC ３層スキーマに関してですが、SQL Server 2000
について「内部スキーマ」なるものが、どのようなオブジェクトを
指すのかご存知なら教えていただけますか？
宜しくお願いします。 >>476
内部スキーマについて、oracleだとセグメントって書いたけど、
データベース上の特定のオブジェクトや構造を指している
というよりも、索引からセグメントからデータファイルまでの
物理構造のことを指してる。
SQL Serverは詳しくないのだけど、同じようにセグメント
（oracleでは表領域に相当）からデータベースデバイス？までの
物理構造のことを指しているのではないかな。 次のケースの一般的なデータモデルをご教授ください。
長文で申し訳ありませんが宜しくお願いします。
<前提条件>
製造業向けの部品加工を想定(在庫関連の処理は無し）
製品･部品･工程･実績の４つのエンティティがあるとして、、、
製品 … 製品というよりは製造指示Noのようなもの
部品 … 製品を構成する部品です。(※一般的なBOMのような親品目,子品目を再帰で保持するような複雑な構造ではない)
工程 … 部品を加工するための加工工程手順です。(手順1:旋盤, 手順2:マシニング...)
実績 … 加工工程に対する実績(労務費、労務時間)
４つのエンティティの関連は次のような階層構造を考えています。
(※この考え方がおかしい場合はご指摘ください)
製品 → 部品 → 工程 → 実績
(1:n) (1:n) (1:n)
部品には材料や購入品といった部品区分があり、データ属性が異なるため、
部品をスーパータイプ、材料･購入品をサブタイプで持たせようと思っています。
製品 → ＋部品(部品id(PK), 部品区分...) → 工程 → 実績
｜
＋材料(部品id(PK), 仕入先cd(FK), 寸法...)
＋購入品(部品id(PK), 仕入先cd(FK), 購入品品番(FK)...)
*** 質問１***
各エンティティの主キー(PK)をどのように設けるのが一般的なのでしょうか？
上記のようなデータ構造の場合の一般的な主キーの設け方をご教授ください。
今考えているのが①と②の方法です。
①各エンティティに単独の主キー(PK)を設けて、親への参照キー(FK)をそれぞれ持たせる。
製品: 製品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), 部品id(FK), 工程cd, 工程手順No, 標準時間, 数量...
実績: 実績id(PK), 製品id(FK), 部品id(FK), 工程id(FK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...
②各エンティティの主キー(PK)を複合キーで持たせる。
製品: {製品id}(PK), 製造指示No, 型番...
部品: {製品id, 部品id}(PK), 部品区分, 部品cd, 部品数...
材料: {製品id, 部品id}(PK), 仕入先cd(FK), 寸法...
購入品: {製品id, 部品id}(PK), 仕入先cd(FK), 購入品品番(FK)...
工程: {製品id, 部品id, 工程id}(PK), 工程cd, 工程手順No, 標準時間, 数量...
実績: {製品id, 部品id, 工程id, 実績id}(PK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...
そもそも考え方がおかしい場合はご指摘ください。
続きです。
*** 質問２***
次の原価をリアルタイムで把握したい場合には原価データをどのように保持するのが一般的なのでしょうか？
(※ここでは外注費は無いもとする)
1.製品別原価(製品別の材料費計＋購入品費計＋労務費計)
2.部品別原価(部品別の材料費計＋購入品費計＋労務費計)
3.工程別原価(工程別の労務費計)
考えているのは次のとおりです。
①製品エンティティに"材料費計", "購入品費計", "労務費計"のデータ項目を持たせる。
②部品のスーパータイプエンティティに"材料費計", "購入品費計", "労務費計" のデータ項目を持たせる。
③工程エンティティに"労務費計"のデータ項目を持たせる。
各計データの更新はトリガーやストアドにて行う
そもそも考え方がおかしい場合はご指摘ください。
以上、宜しくお願いします。
質問１
正規化をきちんとするなら、①の材料と購入品には製品idは入らないはず。
俺なら他のテーブルとの一貫性を保つために
材料: 材料id(PK), 部品id(FK), 仕入先cd(FK), 寸法...
購入品: 購入品id(PK), 部品id(FK), 仕入先cd(FK), 購入品品番(FK)...
とする。でも、部品idにユニーク制約をつけなきゃいけないのでそこを手間と感じるかどうか。
①か②かはどっちでもいいけど、最近は①が主流。
処理側のフレームワークと言うかプログラムロジックに便利な方を選択。
質問２
集計用のテーブルを別に作るべき。
完全なリアルタイムにせずに、例えば１０分ごとに集計バッチをまわすとか、
Oracleならマテビューを使うとかする >>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), 労務費計...
以上、質問ばかりで申し訳ございませんが
宜しくお願いします。 >>481
OKと思われ。
>>482
OKと思われ。まぁ、こっちは単独主キー無くてもいいかも知れんが >>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、表示順）を主キーにする 
