【より良い】データモデリング【モデルを】
MySQLは4.1から認証方式が変わってるから、そのせいではないかい? OLD_PASSWORD関数つかってみれ 例: UPDATE mysql.user SET Password = OLD_PASSWORD('hogehoge') WHERE User = 'foo'; FLUSH PRIVILEGES; >>383 ありがとうございます! 教えて頂いた通りやってみたところ、エラーは消えて無事接続できました! ・・・が、モデルが開けません・・・orz DBDesigner4はMySQL4.1以降には対応していないって事でしょうか。 フリーでかなり良さそうなツールだったので残念。 でもお陰で勉強になりました。 本当にありがとうございました! ふーん、リバースなんて機能あったんだ。 でも、もともと不安定なツールだからね>DBDesigner4 MySQLに対応してるモデリングツールで 論理・物理名を切り替え、同時表示できるのありますか? 最近?でも無いのかも知れないけど、IDとCDの使い分けを 推奨する読み物を見掛ける事があるのですが実際の所どう思います? ●定義 ID:ユーザが意識しないシステム上での識別子 CD:ユーザが意識する識別子 この定義までは、同意です。 この後、CDを使う場合は、IDを主キーとし、 CDには、ユニークインデックスを張るという解説がよくみるパターンです。 この通りに進めると確かにCDは変更できるのですが、 モデルが複雑になりアプリの開発工数が確実に増えます。 (昔CDを変更する要件があって同じ実装をしたが 履歴系情報との整合性問題を理解して貰うとか、 CD変更用アプリを別途作るとか面倒ダタヨ) その辺のバランスが、私の経験だとヤリスギと感じるのですが、 どう思いますかね? (1) joinするときに便利(複合主キーの場合) (2) 変更履歴を管理しやすい(コード変更時は直接変更ではなく古いコードに削除フラグを立てる、という感じ) (3) 最近のアプリケーションフレームワークにシステムidを前提にしたものが増えてきている(Hibernate,RoRなど) 仕様変更とか柔軟になるし 要求側には出来る限り押し通す モデリングする段階ではCDを主キーとして、IDは実装段階で 主キーにするのでは。 >>388 >(1) joinするときに便利(複合主キーの場合) 4階層目のテーブルなどで、主キーの項目数が、やむえず増えた場合に 代替となるIDを振る事には、同意です。 気になっているのは、1:1でCDとIDを作成する事が、どうなのかなぁと。。 例えば、↓こんなテーブル 取引先テーブル 取引先ID(主キー) 取引先CD(ユニーク制約) 取引先名(単なる属性項目) >(2) 変更履歴を管理しやすい(コード変更時は直接変更ではなく古いコードに削除フラグを 立てる、という感じ) 削除フラグを使用するという事は、CDにはユニーク制約を 張らないという事ですね。 変更履歴を、作りやすいという点は、分かりました。 この方法で気になる事は、 ・CD値の重複チェックをアプリ側で徹底する必要がある。 ・変更のたびにレコードが増えて行くのは、 いたすらに負荷(JOIN等)を増やす事になるのでは? ・CD値の変更を行った場合には、レコードが追加され 新しいIDが振られると思うのですが、 子テーブルとの紐付けはどうなるのでしょうか? >(3) 最近のアプリケーションフレームワークにシステムidを前提にしたものが増えてきてい る(Hibernate,RoRなど) な〜るほど、それには従った方がよさそうですね。 >>389 >仕様変更とか柔軟になるし要求側には出来る限り押し通す う〜ん、本当にそこまでやるメリットがあるのか 私の経験上わからないのですよねぇ。 ちなみに開発してきたのは、中小規模で数人で分析〜リリースし 半年位の規模で、受注だとか会計だとかのシステム。 >>390 >モデリングする段階ではCDを主キーとして、IDは実装段階で >主キーにするのでは。 そのようですね。 最初に見たのは、WEB+DB Press Vol.21「データベース設計の基礎知識」で 最近見たのは、Developers Summit2006の↓「楽々ERDレッスンLive」 ttp://www.seshop.com/event/dev/2006/data/download/9-E/9-E-3.pdf IDとCDを分ける、最大のメリットはCD値の柔軟な変更だと 思っているのですが、変更できないといっている原因は、 参照整合性制約が理由ですかねぇ? だとしたらCD値を主キーとして、参照整合性制約にON UPDATE CASCADEを 付加する方が、シンプルで柔軟性も確保でき負荷軽減という点でもメリットが 大きいと思うんですよねぇ・・・ ちなみに、ON UPDATE CASCADEのサポート状態を、ざっと調べてみた所、 使用可:SQLServer2000 , Access97 , MySQL4.0.8 ,pgsqlでも使えるっぽい。 使用不可:Oracle(Oracleで使えんのは問題か。。?) 自分は主キーは更新しないって前提で組むな。 主キーに整合性とってないデータも有ったりだし。 別に外部キー更新したい訳じゃないし。 履歴をどうするかなあと考えていたが、削除フラグねえ。仕様としては前回履歴のみ? 無限履歴とか、ラスト5回履歴とか、便利では有るが、ディスク容量喰うよなあ。 年度毎あたりでダンプして履歴リセットって仕様にすると、継続サポートコスト発生で開発側はウマーかな? >自分は主キーは更新しないって前提で組むな。 私も基本は、主キーは変更しないという考えです。 というか、CDだろうがIDだろうが、一度付けた識別子を、 変更するな、という旧い?考えなのです。 ただ、会社として扱うデータ量、種類が増えてきた為に コード体系を、変更したいといった要望が発生するのは 分かるので、コードを変更する上で効率的なモデリングは、 どんなのかなぁと考えている所です。 まぁ、そんな状況になった場合は、CDだけじゃなくシステム 全面見直しな上、会社として儲かっている可能性が高い訳で、 アプリの修正工数なんて、ちょちょいと出てくるはずなんで すけどねぇ。。。Ψ(`▽´)Ψケケケ その辺のバランス、CDの洗い替えが多発するという状況が 思いつかないのも、疑問に思う一つの理由です。 >主キーに整合性とってないデータも有ったりだし。 整合性が取れない可能性のあるテーブル(参照整合性制約を 張らないテーブル)で、私がよく作るのは、 ・トランザクション系テーブル ・履歴系テーブル ・外部からの連携情報テーブル ・汎用的に様々なCDを入れる為の属性 な〜るほど、こう考えるとCD一本でモデリングした場合の トランザクションが問題で、CD変更時に生きている トランザクションが存在すると面倒ですねぇ。 みなさんありがとう、納得しました。 IDとCDを分ける事によりシステムの寿命が延びるが、 工数と負荷の面でのデメリットがあるという考えで 使い分るとします。 CD体系の変更が発生する可能性の高いシステムが前提の場合、 トランザクション系システムならば、IDとCDを分けて、 データウェアハウスや、寿命よりも処理速度にシビアなシステム ならば、分けないといった感じですかね。 工数も少なくCDの変更ないだろう、といった場合は、 やっつけ仕事で、次回に回収すると。。Ψ(`▽´)Ψケケケ 他には、IDとCDを分けた場合、履歴系はデータを登録しすぐに削除し また同じCDで登録した時に関連が切れるという点をユーザーに理解 してもらう必要があると。(たいした問題ではない。) T字型書けるツールってない?visioじゃないみたいだし・・ >>397 T字型は表記法と正規化における規則であって、正規化そのものじゃないと思うけど。 ER 図なら Visio や ER Studio などで十分。 69の言ってことがよく分からん。 > 会社で社員が部門に所属しているのを表すとき、 > 社員(社員コード、氏名) 部門(部門コード、部門名) 所属(社員コード、所属部門コード) > のようになるようなんですが、T字型でないERの場合は 社員(社員コード、氏名、所属部門コード) 部門(部門コード、部門名) > となると思うのです。 これは、表記法がT字型であろうとなかろうと、結果は一緒になる罠。 理由は70、71が言ってるとおり。 >>397 DynamicDraw(ttp://www.molips.com/jp/) に ttp://groups.yahoo.co.jp/group/molips/files/ のテンプレートを入れて使う。 EXCELとかWORDは矢印線の先端スタイルが限られているから いまいち使えないね。「ファイルが開けないよ〜」って人には WORD or EXCELにクリップボード経由でメタファイル形式で貼り 付けて渡せばいいし。 (再編集はできないけど。) ER図のサンプルが沢山見られるサイトとかってありますか? 勉強用にいろいろ見てみたいのですが・・・。 最近、モデリングの勉強はじめました。 下記以外にお勧めの書籍ありましたら、お教え願えませんでしょうか。 ■ 読んだ 「実践的データモデリング入門」 真野 正 「業務別データベース設計のためのデータモデリング入門」 渡辺 幸三 「データベース設計論 −T字形ER」 佐藤 正美 「名人椿正明が教えるデータモデリングの技」 椿正明 ■ 読むつもり 「データ中心システムの概念データモデル」 椿正明 「生産管理・原価管理システムのためのデータモデリング」 渡辺 幸三 「T字形ER」は新しいのを読んだので、ほか2冊は読まなくて良いかなと 思ってるんですがどうでしょう? (店頭で見つからないので、内容確認できないんです) たくさん読めばよいというものでもないと思うが・・・ モデラーが10人いれば10通りのモデリングがあるって聞いたので。 実際、著者により主張が違うところがあるので自分で比較検討してみたいんです。 >>402 さんみたいに、サンプルを沢山見てみたい、てのもあります。 T字型ってモデルの属人性を排除するんじゃなかったけ? そういう問題ではないだろう。 いろいろ勉強すればT字型ってダサいなぁと気付いたりするわけよ >>407 じゃあ、ナウでヤングなモデリングを教えてくだされ。 T字形って、認知番号重視なのは解るけど、 わざわざ主キーを非明示にする理由がわからん。 データモデリングはどのような書籍で勉強しましたか? >>411 えー。 DB屋以外の関係者との会話に使えないような記法はどうかと思うけど。 T字形の新しい本を読んで思ったのは... あの理論編の哲学議論がまさに「言語ゲーム」。 ヲウムと同じだよね。 悟り開いて宙に浮く様になれば尊師の教えが分かるよって感じ。 傍から見てるとDQNにしか見えない罠。 そうはいかんよ。 従来のER手法でエンティティとリレーションを同時並列的に検討するのは、 純粋な「実体主義」も、純粋な「関係主義」も、現実的には極端すぎるから両方を同等に扱いましょう、 ていうのが背景にあると思う。(明示的にではないにしろ) それを“実体主義のほうが本質的で、だからエンティティーを重視するんだ!”って主張するんだったら そのへんをちゃんと論理的に、かつ皆が納得できるように説明してくれないと... あの理論編は、ぜんぜん「理論」になってなくて、いろんな哲学のオイシイ結論を寄せ集めただけに見える。 だってボク、クリプキ好きなんだもん、とか言われても困っちゃう。 実践編、かなり有用と思うよ でも、たしかに理論書としては、ちゃんと筋道たてて説明してない感じがする。 論理の飛躍がある、というより、断片を継接ぎした結果みたいな。 モデリングって学問としてあるわけじゃないのかな・・ 奥が深いし、博士号取得した哲学者や数学者がもっと研究してほしい 計算量の上界値、下界値ってどういうことなんですか? 上界値=計算量が最大と思われる値? それより大きいことはありえないと保証できる値 てか板ちがい >>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などのコードの作成方法は 決まっているのでしょうか。 社員番号なら入社年月日+連番 などでいいと思うのですが、 何か指針はあるのでしょうか。 連番も何桁取るとか有るよ。2桁じゃ100人入ったら終わり。 総務や人事と打ち合わせて決めたほうがいいよ。 全社的に統一しないと意味がない。 顧客コードなら営業とかと打ち合わせて決めるべき。 営業上、顧客の元に自社の顧客番号が付いたものが送られるし、「ああ、うちって100社目なんだな」って推測されちゃうような顧客IDは恥ずかしい。 設計するのに使ってるツールとか教えて! XEADとかJude、ObjectBrowserERあたりがよさげなんですが!! 今試そうと思ってるのがOracle JDeveloper10g!!! >>445 さんへ XEADは、どこら辺が駄目だと思いますか? ナチュラルキーとサロゲートキーって使い分けどうしてますか? 顧客マスタとか商品マスタみたいなのはナチュラルキー、 受注TRとか売上TRはサロゲートキー、 仕様変更が多そうならサロゲートキー多め、 ERモデリングツール使うならナチュラルキー、 ORマッピング使うならサロゲートキー、 こなかじ? 佐藤 正美氏が提唱する「T字形ER」ってどうなんでしょ。会社の上司が 信者(?)で何が何でも導入したいみたいで。。。本を読んでみたけど 文章表現は下手(だと思った)だし理論にしても判り辛いような。。。 数千人規模の会社の基幹業務構築のモデリングには大丈夫なのかな〜? と思ってます(例えば数年後には理論自体廃れてるとか・・・)。 >>449 いいところはresource概念とevent概念云々のところぐらいか あとはちょっと・・・。identifierの扱いがアレなんで、あの理論をそのまま適用するのは 実際的ではないと思う データモデリングなんて勘でやるのが一番いい。 主キーと関連だけしっかり抑えとけば大概上手くいく。 大事なのは、間違ったモデリングなんてないと知っておくこと 勘でやる時点でだめだめな悪寒。 いろんなモデリングのシミュレーションソフトとかあれば設計時に検証しやすくて便利なのにな。 >>449 基幹ではないが、大手での採用例はあり。 和光市の某自動車メーカとか、麹町の某信販会社とか。 ただ、T字型を使ったプロジェクトで試行錯誤した経験者がいない状態で 本読んだだけでいきなり実地の大規模システムに適用しようとすると 多大な困難が待ち受けていそうな悪寒が… TM(T字形ER手法)は、CoddのRDBMに始まって、正規化だけでは解決しない問題を検討している間に、 業務系のシステムでは「コード体系」を使って分析するのが便利って便法を思いついたりしながら発展して きましたが、根っこの部分ではオブジェクト指向におけるドメインモデリングと繋がっています。 なので、#453 の方が言われる様に、本を読んだだけで見よう見真似で始めるのは、少し辛いでしょう。 できれば、本人から習うことが可能なので、それが一番だと思います。 http://www.sdi-net.co.jp/ に行ってみましょう。 ↑ HP見てみたけど、本当大丈夫なの?かなり素人っぽいHPで すが。コンサルとかやってるんんだったらもうちょっとマシな HPにした方がいいような。。。 それに実績も書いてないし。>>453 の和光や麹町の会社ではどれだけ TMにより実績がでたのかな? コンサルやるなら会社(?)の規模も知りたいなー 麹町では使ってはいるが「お絵かきソフト」程度の使われ方。 「Visioの方が書きやすいじゃん」ってノリだから「TMを 導入してビジネスの強み・弱み・・・」なんて程遠い状態。 >>455 WebPages見てそういう感想抱いたのなら、TMとは出会わなかったことにした方が多分幸せになれる。 いや、煽りや皮肉ではなく、本音ベースの話。 感覚的な「合う」「合わない」っていうのは結構重要な要素かと。 HP見たけど「1,000,000 ステッフ゜ 規模の システム であれば、10数名で、6 ヶ月以内に導入する。」 ってのは凄いなー。 事例とかあるといいけどね。 優秀なエンジニアが集まればとか、そのための費用を出せるならとか前提条件いっぱいだろ? まあ優秀なエンジニア集めれば、別に何でも短納期でできそうな悪寒。 そういう論点のすり替えをして一儲けするのがコンサルと言えばそうだけど。 >>458 ステップってコード量だよねぇ? でコンサルが開発するわけじゃないだろうし、有効なメトリクスなのかね? コンサルとしてはそういうところ大事だと思うんだが。 画面数とかテーブル数とかユースケース数とかでないとピンと来ない 皆様始めまして。 DBDesigner4の使い勝手が良かったので日本語化してみました(需要アルカナ・・・) http://dbdesigner.iimp.jp/ 使ってみてご意見いただければと存じ上げます。 Delphiはあまり使ったことがないので安定度が下がっているかもしれません。。 あと、、まだWindows版しかコンパイルしていないです・・・。 Linuxはあまり慣れていないもので。。すみません。。。 >447 主キーベースのERDを作成する段階では、ナチュラルキーでモデリングし始め、 全属性ERDを作成する段階で、最終的にサロゲートキーに再設計してる。 (最初はナチュラルキーの方がわかりやすいので・・・) 全部サロゲートキーにしてる理由は、 (1)安定性の確保 :将来のシステム改善などでの主キー属性の設計変更を、極力抑える。 (候補キー自体が安定していることが前提なのに、変わることあるから・・・) (2)データへのアクセスコストを抑えたい :ナチュラルキーだと3つ以上のコンポジットとなってしまう場合がある(特に連関エンティティ) (3)ポリシーの統一 :全エンティティを同じポリシーで設計するため全部サロゲートキー なんて言い訳でサロゲートキーにしてる。 >>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か。アプリケーションフレームワーク的に2のようになってないとあかんものがあるな。 武器リストだと表示順ってのも気にしたいだろうから、 1のテーブルにさらに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 3層スキーマのことなら、 概念スキーマ:テーブル 外部スキーマ:VIEW 内部スキーマ:物理ファイル定義(oracleだとセグメントかな) >>475 さん ありがとうございます。 ANSI/SPARC 3層スキーマに関してですが、SQL Server 2000 について「内部スキーマ」なるものが、どのようなオブジェクトを 指すのかご存知なら教えていただけますか? 宜しくお願いします。 >>476 内部スキーマについて、oracleだとセグメントって書いたけど、 データベース上の特定のオブジェクトや構造を指している というよりも、索引からセグメントからデータファイルまでの 物理構造のことを指してる。 SQL Serverは詳しくないのだけど、同じようにセグメント (oracleでは表領域に相当)からデータベースデバイス?までの 物理構造のことを指しているのではないかな。 次のケースの一般的なデータモデルをご教授ください。 長文で申し訳ありませんが宜しくお願いします。 <前提条件> 製造業向けの部品加工を想定(在庫関連の処理は無し) 製品・部品・工程・実績の4つのエンティティがあるとして、、、 製品 … 製品というよりは製造指示Noのようなもの 部品 … 製品を構成する部品です。(※一般的なBOMのような親品目,子品目を再帰で保持するような複雑な構造ではない) 工程 … 部品を加工するための加工工程手順です。(手順1:旋盤, 手順2:マシニング...) 実績 … 加工工程に対する実績(労務費、労務時間) 4つのエンティティの関連は次のような階層構造を考えています。 (※この考え方がおかしい場合はご指摘ください) 製品 → 部品 → 工程 → 実績 (1:n) (1:n) (1:n) 部品には材料や購入品といった部品区分があり、データ属性が異なるため、 部品をスーパータイプ、材料・購入品をサブタイプで持たせようと思っています。 製品 → +部品(部品id(PK), 部品区分...) → 工程 → 実績 | +材料(部品id(PK), 仕入先cd(FK), 寸法...) +購入品(部品id(PK), 仕入先cd(FK), 購入品品番(FK)...) *** 質問1*** 各エンティティの主キー(PK)をどのように設けるのが一般的なのでしょうか? 上記のようなデータ構造の場合の一般的な主キーの設け方をご教授ください。 今考えているのが@とAの方法です。 @各エンティティに単独の主キー(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, 着手日, 労務費, 労務時間... A各エンティティの主キー(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, 着手日, 労務費, 労務時間... そもそも考え方がおかしい場合はご指摘ください。 続きです。 *** 質問2*** 次の原価をリアルタイムで把握したい場合には原価データをどのように保持するのが一般的なのでしょうか? (※ここでは外注費は無いもとする) 1.製品別原価(製品別の材料費計+購入品費計+労務費計) 2.部品別原価(部品別の材料費計+購入品費計+労務費計) 3.工程別原価(工程別の労務費計) 考えているのは次のとおりです。 @製品エンティティに"材料費計", "購入品費計", "労務費計"のデータ項目を持たせる。 A部品のスーパータイプエンティティに"材料費計", "購入品費計", "労務費計" のデータ項目を持たせる。 B工程エンティティに"労務費計"のデータ項目を持たせる。 各計データの更新はトリガーやストアドにて行う そもそも考え方がおかしい場合はご指摘ください。 以上、宜しくお願いします。 質問1 正規化をきちんとするなら、@の材料と購入品には製品idは入らないはず。 俺なら他のテーブルとの一貫性を保つために 材料: 材料id(PK), 部品id(FK), 仕入先cd(FK), 寸法... 購入品: 購入品id(PK), 部品id(FK), 仕入先cd(FK), 購入品品番(FK)... とする。でも、部品idにユニーク制約をつけなきゃいけないのでそこを手間と感じるかどうか。 @かAかはどっちでもいいけど、最近は@が主流。 処理側のフレームワークと言うかプログラムロジックに便利な方を選択。 質問2 集計用のテーブルを別に作るべき。 完全なリアルタイムにせずに、例えば10分ごとに集計バッチをまわすとか、 Oracleならマテビューを使うとかする >>480 遅くなりまして申し訳ございません。 レスありがとうございました。 質問1について なるほど、確かにデータ編集時に、複合主キーより単独主キーでアクセスした方が SQL文も簡単に記述でき、何かと便利が良さそうですね。 教えて頂いた方法で実装しようと思うのですが、 @の方法(各エンティティに単独の主キー(PK)を設けて、親への参照キー(FK)をそれぞれ持たせる)で きちんとした正規化を行う場合、工程の製品id(FK) と 実績の製品id(FK), 部品id(FK)も要らなくなり、 次のようになるはず?(1階層上の親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 遅くなりまして申し訳ございません。 レスありがとうございました。 質問2について やはり集計用の別テーブルを設けた方がいいのですね。 今回のケースで集計テーブルを用いるとすれば、次のような感じでよろしいですか? 集計元テーブルと集計先テーブルは(1:1の関係)になる。 また本来は集計テーブルに主キーの項目として集計日を含むと思うのですが、 今回は集計日が要らないので外します。 製品: 製品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), 労務費計... 以上、質問ばかりで申し訳ございませんが 宜しくお願いします。 read.cgi ver 07.5.0 2024/04/24 Walang Kapalit ★ | Donguri System Team 5ちゃんねる