X



【より良い】データモデリング【モデルを】
0001名無しさん@お腹いっぱい。
垢版 |
03/07/07 01:41ID:mnMZZn0T
データベース構築の上流工程であるモデリングについて語らうスレッドです。
モデル作成に関する質問、質問に対する回答、
作ったモデルの自慢、自慢されたモデルの批評など、
モデリングに関すること全般を扱います。

ソフトの使い方に関する話題、物理的なモデルの話題はご遠慮ください。
EX.
 このソフトで○○の機能は〜 → ソフトウェア板へ
 ○○の組み立てが完成して、これから塗装〜 → 模型・プラモ板へ

モデリングツール
 ○SVG Cats
 製品情報 http://www.sage-p.com/svgcats.files/svgcats.htm
 DL http://www.vector.co.jp/soft/dl/win95/art/se251284.html
 SVG(ベクター画像をテキストで記述するデータフォーマット。要はXMLの一種)でモデル図を描画するツール

 ●ER/Studio
 製品情報 http://www.jsys-products.com/product/erstudio/
 トライアル版DL http://www.jsys-products.com/download/trial/erstudio/

 ●AllFusion ERwin Data Modeler
 製品情報 http://www.caj.co.jp/allfusion/erwin/data_modeler.htm
 トライアル版DL http://www.caj.co.jp/registration/allfusion/erwin_pm.htm
 
 ●Rational Rose
 製品情報 http://www.rational.co.jp/products/rose/
 評価版請求 http://ops.rational.co.jp/CatalogHassou/f_req.html

 ●Microsoft Visio Professional
 製品情報 http://www.microsoft.com/japan/Office/visio/evaluation/
 評価版配布請求 http://www.microsoft.com/japan/office/visio/evaluation/trial/

SVGビューア
 ○SVG Viewerプラグイン
 http://www.adobe.co.jp/svg/ ダウンロードページ
 SVG画像を閲覧するためのプラグイン
0383NAME IS NULL
垢版 |
2006/02/26(日) 15:27:07ID:???
MySQLは4.1から認証方式が変わってるから、そのせいではないかい?
OLD_PASSWORD関数つかってみれ
例:
UPDATE mysql.user SET Password = OLD_PASSWORD('hogehoge') WHERE User = 'foo';
FLUSH PRIVILEGES;
0384380
垢版 |
2006/02/26(日) 17:43:32ID:hHkdb9kS
>>383
ありがとうございます!
教えて頂いた通りやってみたところ、エラーは消えて無事接続できました!

・・・が、モデルが開けません・・・orz

DBDesigner4はMySQL4.1以降には対応していないって事でしょうか。
フリーでかなり良さそうなツールだったので残念。

でもお陰で勉強になりました。
本当にありがとうございました!
0385NAME IS NULL
垢版 |
2006/02/27(月) 01:44:31ID:???
ふーん、リバースなんて機能あったんだ。
でも、もともと不安定なツールだからね>DBDesigner4
0386NAME IS NULL
垢版 |
2006/03/04(土) 14:33:11ID:DNs0MEkq
MySQLに対応してるモデリングツールで
論理・物理名を切り替え、同時表示できるのありますか?
0387NAME IS NULL
垢版 |
2006/03/10(金) 08:45:13ID:pPH8uClm
最近?でも無いのかも知れないけど、IDとCDの使い分けを
推奨する読み物を見掛ける事があるのですが実際の所どう思います?

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

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

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

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

(昔CDを変更する要件があって同じ実装をしたが
履歴系情報との整合性問題を理解して貰うとか、
CD変更用アプリを別途作るとか面倒ダタヨ)

その辺のバランスが、私の経験だとヤリスギと感じるのですが、
どう思いますかね?
0388NAME IS NULL
垢版 |
2006/03/10(金) 09:55:44ID:???
(1) joinするときに便利(複合主キーの場合)
(2) 変更履歴を管理しやすい(コード変更時は直接変更ではなく古いコードに削除フラグを立てる、という感じ)
(3) 最近のアプリケーションフレームワークにシステムidを前提にしたものが増えてきている(Hibernate,RoRなど)
0389NAME IS NULL
垢版 |
2006/03/10(金) 12:49:21ID:???
仕様変更とか柔軟になるし
要求側には出来る限り押し通す
0390NAME IS NULL
垢版 |
2006/03/10(金) 12:57:26ID:???
モデリングする段階ではCDを主キーとして、IDは実装段階で
主キーにするのでは。
0391387
垢版 |
2006/03/12(日) 03:12:21ID:???
>>388
>(1) joinするときに便利(複合主キーの場合)
4階層目のテーブルなどで、主キーの項目数が、やむえず増えた場合に
代替となるIDを振る事には、同意です。
気になっているのは、1:1でCDとIDを作成する事が、どうなのかなぁと。。

例えば、↓こんなテーブル
取引先テーブル
取引先ID(主キー)
取引先CD(ユニーク制約)
取引先名(単なる属性項目)


>(2) 変更履歴を管理しやすい(コード変更時は直接変更ではなく古いコードに削除フラグを

立てる、という感じ)

削除フラグを使用するという事は、CDにはユニーク制約を
張らないという事ですね。
変更履歴を、作りやすいという点は、分かりました。

この方法で気になる事は、
・CD値の重複チェックをアプリ側で徹底する必要がある。
・変更のたびにレコードが増えて行くのは、
 いたすらに負荷(JOIN等)を増やす事になるのでは?
・CD値の変更を行った場合には、レコードが追加され
 新しいIDが振られると思うのですが、
 子テーブルとの紐付けはどうなるのでしょうか?


>(3) 最近のアプリケーションフレームワークにシステムidを前提にしたものが増えてきてい

る(Hibernate,RoRなど)
な〜るほど、それには従った方がよさそうですね。
0392387
垢版 |
2006/03/12(日) 03:14:03ID:???
>>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

0393387
垢版 |
2006/03/12(日) 03:15:25ID:???
IDとCDを分ける、最大のメリットはCD値の柔軟な変更だと
思っているのですが、変更できないといっている原因は、
参照整合性制約が理由ですかねぇ?

だとしたらCD値を主キーとして、参照整合性制約にON UPDATE CASCADEを
付加する方が、シンプルで柔軟性も確保でき負荷軽減という点でもメリットが
大きいと思うんですよねぇ・・・

ちなみに、ON UPDATE CASCADEのサポート状態を、ざっと調べてみた所、
使用可:SQLServer2000 , Access97 , MySQL4.0.8 ,pgsqlでも使えるっぽい。
使用不可:Oracle(Oracleで使えんのは問題か。。?)
0394NAME IS NULL
垢版 |
2006/03/13(月) 12:46:46ID:???
自分は主キーは更新しないって前提で組むな。
主キーに整合性とってないデータも有ったりだし。
別に外部キー更新したい訳じゃないし。
0395NAME IS NULL
垢版 |
2006/03/13(月) 20:08:01ID:???
履歴をどうするかなあと考えていたが、削除フラグねえ。仕様としては前回履歴のみ?
無限履歴とか、ラスト5回履歴とか、便利では有るが、ディスク容量喰うよなあ。
年度毎あたりでダンプして履歴リセットって仕様にすると、継続サポートコスト発生で開発側はウマーかな?
0396387
垢版 |
2006/03/13(月) 20:57:29ID:???
>自分は主キーは更新しないって前提で組むな。
私も基本は、主キーは変更しないという考えです。

というか、CDだろうがIDだろうが、一度付けた識別子を、
変更するな、という旧い?考えなのです。
ただ、会社として扱うデータ量、種類が増えてきた為に
コード体系を、変更したいといった要望が発生するのは
分かるので、コードを変更する上で効率的なモデリングは、
どんなのかなぁと考えている所です。

まぁ、そんな状況になった場合は、CDだけじゃなくシステム
全面見直しな上、会社として儲かっている可能性が高い訳で、
アプリの修正工数なんて、ちょちょいと出てくるはずなんで
すけどねぇ。。。Ψ(`▽´)Ψケケケ
その辺のバランス、CDの洗い替えが多発するという状況が
思いつかないのも、疑問に思う一つの理由です。


>主キーに整合性とってないデータも有ったりだし。
整合性が取れない可能性のあるテーブル(参照整合性制約を
張らないテーブル)で、私がよく作るのは、
・トランザクション系テーブル
・履歴系テーブル
・外部からの連携情報テーブル
・汎用的に様々なCDを入れる為の属性

な〜るほど、こう考えるとCD一本でモデリングした場合の
トランザクションが問題で、CD変更時に生きている
トランザクションが存在すると面倒ですねぇ。

みなさんありがとう、納得しました。

IDとCDを分ける事によりシステムの寿命が延びるが、
工数と負荷の面でのデメリットがあるという考えで
使い分るとします。

CD体系の変更が発生する可能性の高いシステムが前提の場合、
トランザクション系システムならば、IDとCDを分けて、
データウェアハウスや、寿命よりも処理速度にシビアなシステム
ならば、分けないといった感じですかね。

工数も少なくCDの変更ないだろう、といった場合は、
やっつけ仕事で、次回に回収すると。。Ψ(`▽´)Ψケケケ


他には、IDとCDを分けた場合、履歴系はデータを登録しすぐに削除し
また同じCDで登録した時に関連が切れるという点をユーザーに理解
してもらう必要があると。(たいした問題ではない。)
0397NAME IS NULL
垢版 |
2006/03/26(日) 12:56:39ID:???
T字型書けるツールってない?visioじゃないみたいだし・・
0399NAME IS NULL
垢版 |
2006/03/32(土) 00:02:21ID:???
>>397
T字型は表記法と正規化における規則であって、正規化そのものじゃないと思うけど。
ER 図なら Visio や ER Studio などで十分。

69の言ってことがよく分からん。

> 会社で社員が部門に所属しているのを表すとき、
> 社員(社員コード、氏名) 部門(部門コード、部門名) 所属(社員コード、所属部門コード)
> のようになるようなんですが、T字型でないERの場合は
社員(社員コード、氏名、所属部門コード) 部門(部門コード、部門名)
> となると思うのです。

これは、表記法がT字型であろうとなかろうと、結果は一緒になる罠。
理由は70、71が言ってるとおり。
0400NAME IS NULL
垢版 |
2006/03/32(土) 17:00:56ID:uNjChBox
>>397
DynamicDraw(ttp://www.molips.com/jp/)

ttp://groups.yahoo.co.jp/group/molips/files/
のテンプレートを入れて使う。

EXCELとかWORDは矢印線の先端スタイルが限られているから
いまいち使えないね。「ファイルが開けないよ〜」って人には
WORD or EXCELにクリップボード経由でメタファイル形式で貼り
付けて渡せばいいし。
(再編集はできないけど。)
0402NAME IS NULL
垢版 |
2006/04/05(水) 22:46:40ID:5UG0+3IT
ER図のサンプルが沢山見られるサイトとかってありますか?
勉強用にいろいろ見てみたいのですが・・・。
0403NAME IS NULL
垢版 |
2006/04/22(土) 05:31:29ID:pFb3dyuH
最近、モデリングの勉強はじめました。
下記以外にお勧めの書籍ありましたら、お教え願えませんでしょうか。

■ 読んだ
「実践的データモデリング入門」 真野 正
「業務別データベース設計のためのデータモデリング入門」 渡辺 幸三
「データベース設計論 −T字形ER」 佐藤 正美
「名人椿正明が教えるデータモデリングの技」 椿正明

■ 読むつもり
「データ中心システムの概念データモデル」 椿正明
「生産管理・原価管理システムのためのデータモデリング」 渡辺 幸三


「T字形ER」は新しいのを読んだので、ほか2冊は読まなくて良いかなと
思ってるんですがどうでしょう?
(店頭で見つからないので、内容確認できないんです)
0404NAME IS NULL
垢版 |
2006/04/22(土) 07:26:55ID:???
たくさん読めばよいというものでもないと思うが・・・
0405NAME IS NULL
垢版 |
2006/04/22(土) 13:18:55ID:pFb3dyuH
モデラーが10人いれば10通りのモデリングがあるって聞いたので。
実際、著者により主張が違うところがあるので自分で比較検討してみたいんです。
>>402 さんみたいに、サンプルを沢山見てみたい、てのもあります。
0406NAME IS NULL
垢版 |
2006/04/24(月) 04:43:21ID:???
T字型ってモデルの属人性を排除するんじゃなかったけ?
0407NAME IS NULL
垢版 |
2006/04/25(火) 00:55:55ID:???
そういう問題ではないだろう。
いろいろ勉強すればT字型ってダサいなぁと気付いたりするわけよ
0409NAME IS NULL
垢版 |
2006/04/25(火) 13:26:45ID:???
>>407
じゃあ、ナウでヤングなモデリングを教えてくだされ。
0410NAME IS NULL
垢版 |
2006/04/28(金) 01:15:02ID:???
T字形って、認知番号重視なのは解るけど、
わざわざ主キーを非明示にする理由がわからん。
0412NAME IS NULL
垢版 |
2006/05/07(日) 13:07:50ID:???
データモデリングはどのような書籍で勉強しましたか?
0414NAME IS NULL
垢版 |
2006/05/11(木) 00:42:24ID:???
>>411
えー。
DB屋以外の関係者との会話に使えないような記法はどうかと思うけど。
0415NAME IS NULL
垢版 |
2006/05/11(木) 00:59:09ID:???
うん、だから流行らない
0416NAME IS NULL
垢版 |
2006/05/11(木) 07:29:29ID:???
>>414
哲学者とは会話できるようになるぞw
0417NAME IS NULL
垢版 |
2006/05/14(日) 01:28:50ID:???
T字形の新しい本を読んで思ったのは...
あの理論編の哲学議論がまさに「言語ゲーム」。
0418NAME IS NULL
垢版 |
2006/05/14(日) 01:42:07ID:???
ヲウムと同じだよね。
悟り開いて宙に浮く様になれば尊師の教えが分かるよって感じ。

傍から見てるとDQNにしか見えない罠。
0419NAME IS NULL
垢版 |
2006/05/14(日) 13:29:08ID:???
理論編だけ読み飛ばせばモーマンタイ
0420NAME IS NULL
垢版 |
2006/05/15(月) 00:55:43ID:???
そうはいかんよ。

従来のER手法でエンティティとリレーションを同時並列的に検討するのは、
純粋な「実体主義」も、純粋な「関係主義」も、現実的には極端すぎるから両方を同等に扱いましょう、
ていうのが背景にあると思う。(明示的にではないにしろ)

それを“実体主義のほうが本質的で、だからエンティティーを重視するんだ!”って主張するんだったら
そのへんをちゃんと論理的に、かつ皆が納得できるように説明してくれないと...

あの理論編は、ぜんぜん「理論」になってなくて、いろんな哲学のオイシイ結論を寄せ集めただけに見える。
だってボク、クリプキ好きなんだもん、とか言われても困っちゃう。
0421NAME IS NULL
垢版 |
2006/05/15(月) 04:32:07ID:???
実践編、かなり有用と思うよ
でも、たしかに理論書としては、ちゃんと筋道たてて説明してない感じがする。
論理の飛躍がある、というより、断片を継接ぎした結果みたいな。

モデリングって学問としてあるわけじゃないのかな・・
奥が深いし、博士号取得した哲学者や数学者がもっと研究してほしい
0422NAME IS NULL
垢版 |
2006/05/16(火) 19:37:34ID:???
計算量の上界値、下界値ってどういうことなんですか?
上界値=計算量が最大と思われる値?
0423NAME IS NULL
垢版 |
2006/05/16(火) 23:01:00ID:???
それより大きいことはありえないと保証できる値
てか板ちがい
0424NAME IS NULL
垢版 |
2006/05/16(火) 23:20:39ID:???
>>423
レスありがとうございます。
では、これはどこの板行けばいいんですかね?プログラム板ですか?
0425NAME IS NULL
垢版 |
2006/06/29(木) 00:28:29ID:s69NJyt8
Visioって作ったモデルからCreate文生成したり,DBに直接テーブル作成したりできるん?
0426NAME IS NULL
垢版 |
2006/06/30(金) 12:54:48ID:5MdCXCSh
新しい職場で、設計がやたら縦持ちになってるんですが、縦持ちってポピュラーな方法なんですか?
扱いにくくってしょうがないんですが。
0427NAME IS NULL
垢版 |
2006/06/30(金) 13:03:31ID:???
>>425
VisioのProfessional版を使っていて、できそうだったのでちょっとやってみたら
「Enterprise Editionを使え( ゚Д゚)ゴルァ!」と言ってきました。インスコしてないので試せないが、
Enterprise版を使えばできると思われ。MSDNにはついてきていると思う。
0428NAME IS NULL
垢版 |
2006/06/30(金) 23:23:03ID:???
Create分まで作りたいんなら、VisioよりDBDesigner4を勧めたい
0431NAME IS NULL
垢版 |
2006/07/02(日) 07:56:49ID:???
仕様書作る時にはvisioのほうが便利。
実装と文書化の二度手間のほうが苦痛。
0432NAME IS NULL
垢版 |
2006/07/02(日) 09:59:38ID:???
仕様書ってどういうレベルのもの言ってんだ?
DBDesignerでもER図やDB定義書くらい作れるぞ
0433NAME IS NULL
垢版 |
2006/07/02(日) 15:46:50ID:???
客と下請けに提出する清書レベルだよ。
手書き程度ならチラシの裏に落書きで十分だし。
0434425
垢版 |
2006/07/05(水) 22:25:25ID:???
レスくれた方ありがとうございました。Visio for Enterprise Architects
というバージョンで出来ました。

ところで、教えていただきたいことがあるのですが、3種類のコードが組み合わさって
出来ているコードがあるのですが

  AAABBCC

  コードA VARCHAR(3)
  コードB VARCHAR(2)
  コードC VARCHAR(2)

こんな感じです。AとBとCは親−子−孫の関係にあるのですが
この親−子−孫を表せるようにモデリングするにはどうしたらよいでしょうか・・・・
0435NAME IS NULL
垢版 |
2006/07/06(木) 18:28:47ID:???
>>434
親=PK:|AAA|
子=PK:|AAA|1-n|BB|
孫=PK:|AAA|1-n|BB|1-n|CC|
かな?

んで。気になるのは。各コードは固定長でなく可変長なんですか??
0436NAME IS NULL
垢版 |
2006/07/06(木) 22:26:39ID:???
>>435
あ、固定長です。

>親=PK:|AAA|
>子=PK:|AAA|1-n|BB|
>孫=PK:|AAA|1-n|BB|1-n|CC|

これは、まさしくこんな関係です。
0437NAME IS NULL
垢版 |
2006/07/10(月) 23:41:46ID:2umW5dHJ
あるリソースエンティティ同士の関係を表すのに
交差エンティティを作成するという例はよく見かけるのですが、
イベントエンティティ同士の関係についても交差エンティティを作成するという
事はあるのでしょうか?
たとえばある複数の勘定科目から出金して、出金した額を別の種類の複数の
科目へ入金するといった作業があるとして、出金エンティティと入金エンティティ
との関係はどう表したらよいのでしょうか。
0438NAME IS NULL
垢版 |
2006/07/10(月) 23:45:40ID:EbhJ+Fw+
yhSEfIF00
0439NAME IS NULL
垢版 |
2006/07/11(火) 02:01:08ID:???
>>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
0440NAME IS NULL
垢版 |
2006/07/11(火) 14:42:29ID:???
DB作る前に簿記の勉強したほうがいいね。
帳票をそのままDBにすればおk。
0441NAME IS NULL
垢版 |
2006/07/15(土) 15:39:26ID:???
簿記検定受験後の今その言葉の重みが良くわかる
0442NAME IS NULL
垢版 |
2006/08/27(日) 18:38:29ID:7FPwEeLv
つまらない質問で申し訳ないのですが、
顧客IDなどのコードの作成方法は
決まっているのでしょうか。
社員番号なら入社年月日+連番
などでいいと思うのですが、
何か指針はあるのでしょうか。
0443NAME IS NULL
垢版 |
2006/08/28(月) 01:10:22ID:???
連番も何桁取るとか有るよ。2桁じゃ100人入ったら終わり。
総務や人事と打ち合わせて決めたほうがいいよ。
全社的に統一しないと意味がない。

顧客コードなら営業とかと打ち合わせて決めるべき。
営業上、顧客の元に自社の顧客番号が付いたものが送られるし、「ああ、うちって100社目なんだな」って推測されちゃうような顧客IDは恥ずかしい。
0444NAME IS NULL
垢版 |
2006/09/01(金) 01:41:11ID:???
設計するのに使ってるツールとか教えて!
XEADとかJude、ObjectBrowserERあたりがよさげなんですが!!
今試そうと思ってるのがOracle JDeveloper10g!!!
0445NAME IS NULL
垢版 |
2006/09/01(金) 17:52:21ID:???
DBDesigner4最強。
XEADだけは勘弁
0446NAME IS NULL
垢版 |
2006/09/02(土) 23:04:56ID:???
>>445 さんへ
XEADは、どこら辺が駄目だと思いますか?
0447NAME IS NULL
垢版 |
2006/09/16(土) 01:13:27ID:???
ナチュラルキーとサロゲートキーって使い分けどうしてますか?
顧客マスタとか商品マスタみたいなのはナチュラルキー、
受注TRとか売上TRはサロゲートキー、
仕様変更が多そうならサロゲートキー多め、
ERモデリングツール使うならナチュラルキー、
ORマッピング使うならサロゲートキー、
こなかじ?
0448NAME IS NULL
垢版 |
2006/09/16(土) 01:23:02ID:???
知るか。何でもいいよ。
あれもアホな議論だったな
0449NAME IS NULL
垢版 |
2006/09/17(日) 01:56:26ID:???
佐藤 正美氏が提唱する「T字形ER」ってどうなんでしょ。会社の上司が
信者(?)で何が何でも導入したいみたいで。。。本を読んでみたけど
文章表現は下手(だと思った)だし理論にしても判り辛いような。。。
数千人規模の会社の基幹業務構築のモデリングには大丈夫なのかな〜?
と思ってます(例えば数年後には理論自体廃れてるとか・・・)。
0450NAME IS NULL
垢版 |
2006/09/17(日) 02:41:45ID:???
>>449
いいところはresource概念とevent概念云々のところぐらいか
あとはちょっと・・・。identifierの扱いがアレなんで、あの理論をそのまま適用するのは
実際的ではないと思う
0451NAME IS NULL
垢版 |
2006/09/17(日) 04:11:40ID:???
データモデリングなんて勘でやるのが一番いい。
主キーと関連だけしっかり抑えとけば大概上手くいく。

大事なのは、間違ったモデリングなんてないと知っておくこと
0452NAME IS NULL
垢版 |
2006/09/17(日) 16:38:22ID:???
勘でやる時点でだめだめな悪寒。

いろんなモデリングのシミュレーションソフトとかあれば設計時に検証しやすくて便利なのにな。
0453NAME IS NULL
垢版 |
2006/09/18(月) 11:28:44ID:???
>>449
基幹ではないが、大手での採用例はあり。
和光市の某自動車メーカとか、麹町の某信販会社とか。
ただ、T字型を使ったプロジェクトで試行錯誤した経験者がいない状態で
本読んだだけでいきなり実地の大規模システムに適用しようとすると
多大な困難が待ち受けていそうな悪寒が…
0454TM使ってるよ
垢版 |
2006/09/20(水) 14:17:52ID:6C6LnzZC
TM(T字形ER手法)は、CoddのRDBMに始まって、正規化だけでは解決しない問題を検討している間に、
業務系のシステムでは「コード体系」を使って分析するのが便利って便法を思いついたりしながら発展して
きましたが、根っこの部分ではオブジェクト指向におけるドメインモデリングと繋がっています。
なので、#453 の方が言われる様に、本を読んだだけで見よう見真似で始めるのは、少し辛いでしょう。
できれば、本人から習うことが可能なので、それが一番だと思います。
http://www.sdi-net.co.jp/ に行ってみましょう。
0455NAME IS NULL
垢版 |
2006/09/23(土) 17:10:07ID:???

HP見てみたけど、本当大丈夫なの?かなり素人っぽいHPで
すが。コンサルとかやってるんんだったらもうちょっとマシな
HPにした方がいいような。。。
それに実績も書いてないし。>>453 の和光や麹町の会社ではどれだけ
TMにより実績がでたのかな?
コンサルやるなら会社(?)の規模も知りたいなー
0456NAME IS NULL
垢版 |
2006/09/24(日) 12:10:14ID:???
麹町では使ってはいるが「お絵かきソフト」程度の使われ方。
「Visioの方が書きやすいじゃん」ってノリだから「TMを
導入してビジネスの強み・弱み・・・」なんて程遠い状態。
0457NAME IS NULL
垢版 |
2006/09/24(日) 20:16:59ID:???
>>455
WebPages見てそういう感想抱いたのなら、TMとは出会わなかったことにした方が多分幸せになれる。
いや、煽りや皮肉ではなく、本音ベースの話。
感覚的な「合う」「合わない」っていうのは結構重要な要素かと。
0458NAME IS NULL
垢版 |
2006/09/25(月) 00:31:01ID:???
HP見たけど「1,000,000 ステッフ゜ 規模の システム であれば、10数名で、6 ヶ月以内に導入する。」
ってのは凄いなー。
事例とかあるといいけどね。
0459NAME IS NULL
垢版 |
2006/09/25(月) 01:10:08ID:???
優秀なエンジニアが集まればとか、そのための費用を出せるならとか前提条件いっぱいだろ?
まあ優秀なエンジニア集めれば、別に何でも短納期でできそうな悪寒。
そういう論点のすり替えをして一儲けするのがコンサルと言えばそうだけど。
0460NAME IS NULL
垢版 |
2006/09/25(月) 10:26:51ID:???
>>458
ステップってコード量だよねぇ?
でコンサルが開発するわけじゃないだろうし、有効なメトリクスなのかね?
コンサルとしてはそういうところ大事だと思うんだが。
0461NAME IS NULL
垢版 |
2006/09/26(火) 00:04:22ID:???
画面数とかテーブル数とかユースケース数とかでないとピンと来ない
0462yossy
垢版 |
2006/09/26(火) 00:38:05ID:3/C3qjqe
皆様始めまして。
DBDesigner4の使い勝手が良かったので日本語化してみました(需要アルカナ・・・)
http://dbdesigner.iimp.jp/
使ってみてご意見いただければと存じ上げます。
Delphiはあまり使ったことがないので安定度が下がっているかもしれません。。
あと、、まだWindows版しかコンパイルしていないです・・・。
Linuxはあまり慣れていないもので。。すみません。。。
0463NAME IS NULL
垢版 |
2006/10/02(月) 23:45:41ID:???
>447

主キーベースのERDを作成する段階では、ナチュラルキーでモデリングし始め、
全属性ERDを作成する段階で、最終的にサロゲートキーに再設計してる。
(最初はナチュラルキーの方がわかりやすいので・・・)

全部サロゲートキーにしてる理由は、
(1)安定性の確保
  :将来のシステム改善などでの主キー属性の設計変更を、極力抑える。
   (候補キー自体が安定していることが前提なのに、変わることあるから・・・)
(2)データへのアクセスコストを抑えたい
  :ナチュラルキーだと3つ以上のコンポジットとなってしまう場合がある(特に連関エンティティ)
(3)ポリシーの統一
  :全エンティティを同じポリシーで設計するため全部サロゲートキー

なんて言い訳でサロゲートキーにしてる。
0464NAME IS NULL
垢版 |
2006/10/02(月) 23:56:56ID:???
>>463
>候補キー自体が安定していることが前提なのに、変わることあるから・・・
間違えた。
候補キー -> 主キー
0466NAME IS NULL
垢版 |
2007/05/15(火) 19:54:55ID:/Spdz0dJ
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だとキーの作成は簡単だが、データの入力順を間違えると気持ち悪いナンバリングになってしまう。

どのような場合にどちらがいいか教えてください。
0467NAME IS NULL
垢版 |
2007/05/15(火) 23:21:27ID:???
>466
複合キー列への外部キー設定は列が増えてしまって、
子表が増えるほど面倒になるから案2がいいなぁ。どうせ
武器IDなんてもとより意味のあるものじゃないんだし。


もういっそ武器IDは乱数を採番するようにしちゃえば気にならないよ。
0468NAME IS NULL
垢版 |
2007/05/16(水) 03:44:39ID:???
1の方がデータ移行は楽そうだな。
最近の流行は2か。アプリケーションフレームワーク的に2のようになってないとあかんものがあるな。

武器リストだと表示順ってのも気にしたいだろうから、
1のテーブルにさらにid列を一つ追加して、
武器IDは表示順的な意味を持たせるのもありかも
0469NAME IS NULL
垢版 |
2007/07/08(日) 18:42:56ID:???
MySQLのDBDesignerに相当するpostgresqlのツールってありますか?
それとも、postgresqlをodbcで接続して、DBDesignerを使っても、幸せになれますか?
0470NAME IS NULL
垢版 |
2007/08/07(火) 20:28:30ID:bIEMzxGi
このスレでも何回か見かけるが、簿記の知識がSEにも要求される場合がある。
独学で簿記を勉強しようとすると、書籍を購入して勉強となりがちだが、
項目が羅列してあり説明は最小限のような簿記の書籍ではなかなか理解は進まない(俺だけか)。
簿記の書籍は不親切であり、そのために資格学校が存続できてる気がする。
資格学校に通わなくても資格学校の通信教育等もあるし、それもそんなに高くはない。

さらに講義形式の勉強で一番手軽なのは、資格学校が出版しているDVDビデオの教材がある。
例えば、以下のような教材がある。

合格テキスト講義DVD日商簿記3級 商業簿記 Ver.4.0(10,500円)
DVD6枚組 TAC出版

俺は本屋で買ったが、amazonにもある。講師は違うが2級もある。
これと対になってる書籍(テキスト)も別に売ってるが、なくても特に困らない。
DVDの講義なので、好きなときに何回でも見れる。
これを見てしまうと、いかに市販の書籍で学ぶことが能率が悪いかということがよく分かる。
おそらく簿記の勉強は書籍ではなくて人の話を聞いて学ぶのが一番よいのでは
ないかと思う。「要はこういうこと」みたいな言葉やくどいぐらいの説明は
なかなか書籍には載りにくい。このDVDのテキストも同じ欠点がある。

例えば減価償却累計額について簿記上の具体例を含めて詳しい説明を書籍で
探そうとすると結構大変だと思う。また、講師がしゃべってくれるわけで漢字の
読み方も問題なくなる。この3級の講師は大変よいと思う。きっちりとよく話してくれている。

スレ違いすまん。

0471NAME IS NULL
垢版 |
2007/08/08(水) 00:35:59ID:???
まぁ、SEが片手間に勉強するのにむいた教材は確かに少ないかもしれんけど、
たかが3級レベルで分かりやすいも分かりにくいも無いと思うんだが・・・
0472NAME IS NULL
垢版 |
2007/08/08(水) 21:18:53ID:???
まったくその通り。10日でわかるとかそういうので十分、
実際は1週間足らず勉強してケアレスミスで落として
90点代後半取れた。
0473NAME IS NULL
垢版 |
2007/08/09(木) 22:20:09ID:MI2mCbx1
初心者です。
物理データモデルの「内部スキーマ」とは、具体的にRDBMSで
いうところの、どのようなオブジェクトなのでしょうか?

どなたか御教授ねがいます。
0474NAME IS NULL
垢版 |
2007/08/10(金) 02:23:03ID:???
テーブルとかカラムとか
0475NAME IS NULL
垢版 |
2007/08/10(金) 22:15:11ID:???
>>473
ANSI/SPARC 3層スキーマのことなら、
概念スキーマ:テーブル
外部スキーマ:VIEW
内部スキーマ:物理ファイル定義(oracleだとセグメントかな)
0476473
垢版 |
2007/08/11(土) 00:56:13ID:Fq8lPKBO
>>475さん
ありがとうございます。
ANSI/SPARC 3層スキーマに関してですが、SQL Server 2000
について「内部スキーマ」なるものが、どのようなオブジェクトを
指すのかご存知なら教えていただけますか?

宜しくお願いします。
0477NAME IS NULL
垢版 |
2007/08/11(土) 09:26:15ID:???
>>476
内部スキーマについて、oracleだとセグメントって書いたけど、
データベース上の特定のオブジェクトや構造を指している
というよりも、索引からセグメントからデータファイルまでの
物理構造のことを指してる。
SQL Serverは詳しくないのだけど、同じようにセグメント
(oracleでは表領域に相当)からデータベースデバイス?までの
物理構造のことを指しているのではないかな。
0478NAME IS NULL
垢版 |
2007/11/19(月) 21:31:13ID:YgXjo0NC
次のケースの一般的なデータモデルをご教授ください。
長文で申し訳ありませんが宜しくお願いします。

<前提条件>
製造業向けの部品加工を想定(在庫関連の処理は無し)
製品・部品・工程・実績の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, 着手日, 労務費, 労務時間...

そもそも考え方がおかしい場合はご指摘ください。
0479NAME IS NULL
垢版 |
2007/11/19(月) 21:32:24ID:YgXjo0NC
続きです。
*** 質問2***
次の原価をリアルタイムで把握したい場合には原価データをどのように保持するのが一般的なのでしょうか?
(※ここでは外注費は無いもとする)

 1.製品別原価(製品別の材料費計+購入品費計+労務費計)
 2.部品別原価(部品別の材料費計+購入品費計+労務費計)
 3.工程別原価(工程別の労務費計)

考えているのは次のとおりです。

@製品エンティティに"材料費計", "購入品費計", "労務費計"のデータ項目を持たせる。
A部品のスーパータイプエンティティに"材料費計", "購入品費計", "労務費計" のデータ項目を持たせる。
B工程エンティティに"労務費計"のデータ項目を持たせる。

各計データの更新はトリガーやストアドにて行う


そもそも考え方がおかしい場合はご指摘ください。
以上、宜しくお願いします。
0480NAME IS NULL
垢版 |
2007/11/20(火) 02:27:57ID:???
質問1

正規化をきちんとするなら、@の材料と購入品には製品idは入らないはず。
俺なら他のテーブルとの一貫性を保つために

材料: 材料id(PK), 部品id(FK), 仕入先cd(FK), 寸法...
購入品: 購入品id(PK), 部品id(FK), 仕入先cd(FK), 購入品品番(FK)...

とする。でも、部品idにユニーク制約をつけなきゃいけないのでそこを手間と感じるかどうか。

@かAかはどっちでもいいけど、最近は@が主流。
処理側のフレームワークと言うかプログラムロジックに便利な方を選択。

質問2

集計用のテーブルを別に作るべき。
完全なリアルタイムにせずに、例えば10分ごとに集計バッチをまわすとか、
Oracleならマテビューを使うとかする
0481NAME IS NULL
垢版 |
2007/11/20(火) 14:49:55ID:/GHn6NrO
>>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, 着手日, 労務費, 労務時間...
0482NAME IS NULL
垢版 |
2007/11/20(火) 14:51:01ID:/GHn6NrO
続きです。
>>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), 労務費計...


以上、質問ばかりで申し訳ございませんが
宜しくお願いします。
0483NAME IS NULL
垢版 |
2007/11/20(火) 20:40:10ID:wWhiZNbu
パソコンショップならここ!!
http://want-pc.com
レスを投稿する


ニューススポーツなんでも実況