5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :名無しさん@お腹いっぱい。:03/07/07 01:41 ID: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画像を閲覧するためのプラグイン


2 :名無しさん@お腹いっぱい。:03/07/07 02:58 ID:Q7SvyCOg
http://book-i.net/ad07/

3 :名無しさん@お腹いっぱい。:03/07/07 19:12 ID:SY8PbIMK
スーフリのモデリングキボン

4 :名無しさん:03/07/08 03:25 ID:???
visioってモデリングツール??

5 :名無しさん@お腹いっぱい。:03/07/08 10:31 ID:tx3ry9fl
うちの課長がT字型ER手法をやりたいとかいってるけど
南下不安。
きわものに飛びつくよりIDEF1Xで我慢しとけといいたい



6 :名無しさん@お腹いっぱい。:03/07/08 23:12 ID:???
>>4
そだよ?知らなかった?
その手の比較には必ずっていうほど出てくる。

オマエの場合は、ただのオエカキツールと一緒だろうが。

7 :名無しさん@お腹いっぱい。:03/07/09 00:45 ID:wCmp9XwB
漏れ普段IDEF1X使ってる。
いろんなツールが対応してるし、ERDと違って描き手によって表現が少しずつ違うってこともない。
ERDは、ツールによって表現が違うから、統一できなくて気持ち悪い。

つーかIDEF0の描き方がよくわからん・・・だれかいいサイトなり書籍なり教えて・・・

8 :名無しさん@お腹いっぱい。:03/07/09 19:57 ID:wCmp9XwB
ぶっちゃけモデリングの技術磨くの難しいよな。
独学じゃ限界もあるだろうし。
なんかいい練習法ないかな?

9 :名無しさん@お腹いっぱい。:03/07/09 20:00 ID:qxLW72KX
福岡発!ミリオンゴッドでぼろ儲け!!!

ミリオンゴッドで稼ぎたい人はいませんか?
攻略法でも体感機でもありません。一日十万はいけます!
(私自身も三人グループで八十万いきました★)

詳しい内容については確実に連絡の取れるメールアドレスで
god-game@jp-q.ne.jpまでお願いします。

量産タイプのコピー品と違い、数に限りがありますので稼ぎ
たい人はお早めにどうぞ!!!

10 :あぼーん:あぼーん
あぼーん

11 :7:03/07/09 22:02 ID:wCmp9XwB
ちなみに自分が買った本は以下3つ

データモデリング基礎講座―データベース設計を楽しもう! DB Magazine SELECTION
http://www.amazon.co.jp/exec/obidos/ASIN/4798101109/qid%3D1057755191/249-8156321-9557966

実践的データモデリング入門 DB magazine selection
http://www.amazon.co.jp/exec/obidos/ASIN/4798103853/qid%3D1057755316/249-8156321-9557966

業務別データベース設計のためのデータモデリング入門
http://www.amazon.co.jp/exec/obidos/ASIN/4534032501/ref=pd_sim_b_dp_1_4/249-8156321-9557966

ちなみに今手元にないし、全部カバーかけて表紙覚えてないので、
感想はすぐかけません。であ。

12 :名無しさん@お腹いっぱい。:03/07/10 09:51 ID:QyUEwDAR
はじめてこの手の勉強をし始めたんだけど
データモデリング基礎講座 はすごくわかりやすかった。
でもあれに出てくる書き方であるシュレイアーメラー?(T字型というやつなのか?)
ってはやってんでしょうか?

手元のVisioじゃあの書き方はできないし

13 :名無しさん@お腹いっぱい。:03/07/10 13:49 ID:EwRs8XaC
>>5
T字形いいよ。漏れは7年ほどやってる。設計品質の確保には便利。
でも書籍だけだと細かいところで悩むので、お金があるならセミナーを
受けるといいかも。漏れは受けたことはないし、自己流でアレンジしてる。

ちなみにツールはErwinでIDEF1Xでやってる。考え方がT字形ってことで。
多分佐藤氏からすれば邪道なのだろうが、納期に間に合い品質と性能が
出れば、それで良いのだよ(w

14 :名無しさん@お腹いっぱい。:03/07/12 10:31 ID:/MBRqZ7d
基礎からのデータベース設計買ってみた。
対話形式の内容なので、イメージがしやすい。
モデリングの入門者にはいい本だと思う。
http://www.amazon.co.jp/exec/obidos/ASIN/4797321296/qid=1057970961/sr=1-1/ref=sr_1_2_1/249-9336605-0510750

15 :あぼーん:あぼーん
あぼーん

16 :名無しさん@お腹いっぱい。:03/07/13 13:43 ID:vNL7QqBW
モデリングツールっていくらくらいすんの?
visioって6万くらいでしょ?
ほかのは?

17 :名無しさん@お腹いっぱい。:03/07/13 13:59 ID:???

  ageるな!
  ヴォケッ!!

  ドラゴンボール厨が寄ってくるだろ!



18 :名無しさん@お腹いっぱい。:03/07/13 14:08 ID:???
光る雲をつきぬけ フライ亜ウェー

体中に広がるパノラマー

19 :16:03/07/13 14:41 ID:???
ゴメン

20 :名無しさん@お腹いっぱい。:03/07/13 18:30 ID:???
ドラゴンボール厨うざいが
>>17-19の流れに思わず笑ってしまった。


21 :名無しさん@お腹いっぱい。:03/07/13 22:45 ID:???
ワダサン<--------------------幹部
      尊敬される

22 :名無しさん@お腹いっぱい。:03/07/13 22:46 ID:???
する のほうか スンマセン

23 :名無しさん@お腹いっぱい。:03/07/14 17:48 ID:???
>>21
プチワロタ

24 :名無しさん@お腹いっぱい。:03/07/18 12:07 ID:SKq247KI
ttp://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/vsent7/html/dvcondatadesign.asp

25 :名無しさん@お腹いっぱい。:03/07/18 21:54 ID:QjpeAqCT
ドラゴンボール板http://cgi32.plala.or.jp/mg916/dragon/
2ちゃんねるp http://www11.plala.or.jp/mg916/
こっちにも来てください!!

26 :名無しさん@お腹いっぱい。:03/07/23 12:53 ID:???
独学でDB設計を勉強するのに、お勧めの書籍などありますか?
また、練習方法とかあったら教えてください。

27 :あぼーん:あぼーん
あぼーん

28 :あぼーん:あぼーん
あぼーん

29 :あぼーん:あぼーん
あぼーん

30 :DB2世 ◆rsm9sTjowQ :03/07/23 23:00 ID:???
>>26 勉強したいデータベース製品を絞り込むことから
はじめたほうがいいよ。
あとDBと書くと今の時期 ドラゴンボール設計って感じに
見られてしまう。。。(わけないか)

31 :◆/iQf.Br2tM :03/07/23 23:21 ID:BWf0c5Mj
>>26
ずばりAccess。会社でOracleのCDがゲットできるなら家のPCにインストル
してそれで遊ぶことも出来ます。この場合もAccessと併用して取り扱うと
能率が向上します
(SQL PLUSかナニかでクエリーを投げる→出てきた結果とAccessで覗き見ている
テーブルのデータを比較等)

会社にOracleなどのソフト類がない場合,自宅で練習にはとりあえずAccessでしょう。
自分で買ってもそれなりに安い
(そうしなくても大概は会社にCDあるからそれを自宅のPCに 以下自粛)
のとヘルプがしっかりしているから。
Access‐Oracle間はクエリーの命令式等多少の違いはありますが
基本的な取り扱い方はほぼ同じです。
データベース設計の一番の肝は データをどう整理していくか なので
(俺の意見ですがどうなんですかね)表領域の取り方とかそういう
カコイイことは色々習熟してから手をつけたほうがいいでしょう。


32 :DB2世 ◆rsm9sTjowQ :03/07/23 23:26 ID:???
>>26
DB2 でも勉強できるよ。
公的資格もオラオラと同様にあるし。

33 :あぼーん:あぼーん
あぼーん

34 :26:03/07/28 08:09 ID:???
>>30,31
Oracleは、勉強しようとおもって一時OTN Pro入ってたから、
開発用ライセンスを持ってます。
勉強したいのは、DBに依存しない部分についてです。
このスレタイにあるような、モデリングなんかを覚えたいのですが・・・

Accessも、Office2000 Proがあるので、触れる環境ではあるし、
ちょっとしたものなら作れます。
正規化なんかもちょっとはかじりました。
しかし、その前の段階をどうやって勉強すればいいのかわからないんです。

DFDなんかも覚えてみたはいいものの、どこでどう使えばいいのかもよくわからないし・・・

>>32
DB2は、見たことすらないです・・・

35 :ぼるじょあ ◆ySd1dMH5Gk :03/08/02 05:00 ID:???
     ∧_∧  ∧_∧
ピュ.ー (  ・3・) (  ^^ ) <これからも僕たちを応援して下さいね(^^)。
  =〔~∪ ̄ ̄ ̄∪ ̄ ̄〕
  = ◎――――――◎                      山崎渉&ぼるじょあ

36 :名無しさん@お腹いっぱい。:03/08/03 02:20 ID:???
どこぞで紹介されてた
WEB+DB Pressの11号「RDBMS再入門」中々参考になった。
お勧め。

37 :名無しさん@お腹いっぱい。:03/08/07 12:51 ID:???
>>36
へ〜・・・ってォィ!完売じゃねぇかYO!
ttp://www.gihyo.co.jp/magazines/wdpress/archive/Vol11

38 :名無しさん@お腹いっぱい。:03/08/08 23:35 ID:???
>> 37
まじで。
数日前に近くの書店で見かけて買ったんだけど。
渋谷のBook1にもあったと思う。


39 :36:03/08/11 09:44 ID:???
サンクス。探す

40 :名無しさん@お腹いっぱい。:03/08/11 17:41 ID:???
T字形の勉強をしたいのだがお勧めの本やサイトありますか?


41 :名無しさん@お腹いっぱい。:03/08/13 20:25 ID:???
>>40
T字型?このスレで紹介されてた書籍に載ってたような・・・?
今手元にないんで、あとでISBNとか晒す。

42 :名無しさん@お腹いっぱい。:03/08/13 21:37 ID:???
「データモデリング基礎講座―データベース設計を楽しもう! DB Magazine SELECTION」
http://www.amazon.co.jp/exec/obidos/ASIN/4798101109/qid%3D1057755191/250-1323438-1825824
これですよね。
これは持ってるんです。
他に分かりやすい本ありますか?
やっぱりコースを受講するしかないのかな。

「論理データベース論考―データ設計の方法:数学の基礎とT字形ER手法」
http://www.amazon.co.jp/exec/obidos/ASIN/4883731340/qid=1060778023/sr=1-1/ref=sr_1_2_1/250-1323438-1825824
この本は難しくて・・・

43 :山崎 渉:03/08/15 23:02 ID:???
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

44 :名無しさん@お腹いっぱい。:03/08/17 00:27 ID:???
T字形ならここに行って来い
http://www.sdi-rad.com/index2.html

45 :名無しさん@お腹いっぱい。:03/08/23 16:45 ID:???
IFED1Xで質問があるんですけど、いいですか?

1)モデルをカテゴリー化するときってどんなときですか?
  パートと従業員の例だと解りやすいのですが、逆にこれだと区分つけた方が
  理解しやすくないですか?
2)1:NのリレーションでNが依存エンティティの時、Nの外部キーって必ず主キーにしなくては駄目?

教えて君で申し訳ないですけど、よろしくお願いします。

46 :名無しさん@お腹いっぱい。:03/08/24 12:22 ID:???
1)漏れはカテゴリ化はしない。
2)依存だと主キーになっちゃうだろうな。漏れはいつも非依存で設計してる。
どっちも漏れ流なので、IDEF1Xの正道としてどうかというのはわからん。

47 :名無しさん@お腹いっぱい。:03/08/26 13:24 ID:fop7qkdO
ER Creator
http://www.modelcreator.com/
ってどうでつか?
$150 程度と手頃そうなんでつが。

48 :名無しさん@お腹いっぱい。:03/08/26 15:25 ID:fop7qkdO
うう、ER Creator ファイルを xml で保存するのはいいが、文字を S-JIS ベタで
埋め込んでしまう。

49 :名無しさん@お腹いっぱい。:03/09/09 11:39 ID:RCsLfec9
SVG Catsがあるなら、Dynamic Drawがないのはおかしー気がする。
http://www.molips.com/jp/

50 :名無しさん@お腹いっぱい。:03/09/16 13:27 ID:nh/rX7Cl
1足500円だけど色々組み合わせで3足なら1000円とかの靴下とかって
どういう風に単品在庫&売上管理してのでしょうか?

単純に店員が人力でディスカウントという名の売上レコードを挿入するだけだと
ミスは多そうだし、粗利率や回転率なんかも後々で必要になるとややこしい話になりそうなので
以下のようなこと考えてるのですが、王道みたいなのがあれば教えて下さい。

*売上明細テーブル*
品番 名 基本単価 値引 値引後単価 個数 金額 値引コード
1 靴下A 500円 157円 343円 x 2ヶ = 686円 A 
2 靴下B 500円 157円 343円 x 2ヶ = 686円 A
3 靴下C 500円 157円 343円 x 3ヶ = 1029円 A
4 靴下D 500円 157円 343円 x 4ヶ = 1372円 A
5 靴下E 500円 157円 343円 x 5ヶ = 1715円 A
6 傘A 1000円 0円 1000円 x 2ヶ = 2000円 NULL
---------------------------------
合計 7488円

*値引の157円は値引テーブルを検索する

*値引テーブルの内容*
値引コード 個数 値引合計金額 値引単価
A 1ヶ 0円 0円
A 2ヶ 0円 0円
A 3ヶ 500円 166円
A 4ヶ 500円 125円
省略
A 16ヶ 2500円 157円

売上明細.金額など正規化でわざわざテーブルに値を保存しなくてもいいものも
説明の為含めています、あしからず。

51 :名無しさん@お腹いっぱい。:03/09/16 14:06 ID:???
>>50

わからんけど、それはデータベースのやることじゃなくて、
売上げ管理ソフトのプログラムがやることではなかろうか。

52 :50:03/09/16 15:46 ID:Fb2G3tFn
>>51
そうです。実際の値引き額のSETは
売上げ管理ソフトのプログラムからUPDATE系のストアドなどを叩こうと思うのですが
データモデリングで王道のサンプルみたいながあれば知りたかったのです。
あとマクドナルドのバリューセットなんかはどうなってるのだろう?
とかはデータモデリングの範疇じゃありませんか?
とりあえず、上記に載ってる本のどれか買って色々なSample見てみます。

53 :名無しさん@お腹いっぱい。:03/09/16 17:36 ID:???
>>52
なんかセット用のフィールドを作った気がする。
詳しいことは忘れた。

54 :名無しさん@お腹いっぱい。:03/09/16 17:57 ID:???
まったくの別商品でしょう

55 :名無しさん@お腹いっぱい。:03/09/18 00:06 ID:YP920n31
UMLでモデリングをして、データベースの構造をER図で書こうとすると、
クラス図とは、全く違ったものになると思うのですが、
UMLとER図の連携?というのは、どうなのでしょうか?

まったく別物として考えるのでしょうか?
たまに、本で、クラス図を利用して、データベースを、表現したりしているものもあるのですが、
どのような、使い分けをするものなのでしょうか?


56 :名無しさん@お腹いっぱい。:03/09/19 13:48 ID:9kTuVrlL
>>55
ER 図も書ける EA 使うってのは?
http://www.sparxsystems.jp/

あと、買ったっきり読んでないのでわからんが(をひ)
「データベース設計のための UML」参考になるかもね
http://www.amazon.co.jp/exec/obidos/ASIN/4798103675/


57 :名無しさん@お腹いっぱい。:03/09/25 09:08 ID:inMyKwMQ
安くて、日本語が通って、よい(ER)モデリングツールってないでつか?
以下の2つはよさげなんだけど、日本語のハンドリングにちょっと難点があり。

■DDS-Lite
http://www.chillisource.com/
http://www.dds-lite.com/
現在正式リリースされているのはライト版のみ。フルセットの Pro バージョンは
開発中。現在、ダウンロード版が特売価格で $79.95
ライトバージョンでも、DFDを扱える。(でもリーバースエンジニアリング機能はない)
ER図の日本語表示はなんとかなるが、ダイアログはだめ。
リソースはいろんなところに分散していて直すのが面倒。
また、無理矢理2バイトコードをぶちこむと落ちることがある。(うーむ)

■CaseStudio2
http://www.casestudio.com/
フルセット版で $329 ER、DFD (ライト版は DFD 非対応)
ER 図そのものに日本語の表示は可能なものの、ダイアログボックスが全滅
リソースいじろうとしたが、変な実装で、フォント名かえると、起動できない。

58 :57:03/09/25 10:26 ID:inMyKwMQ
DDS-Lite は、エンティティ名に日本語通らない(そんなもんに2バイトコード使うなってか)
だけで、日本語のハンドリング問題なかったよ。安いんで、とりあえずレジスト。
使い物になるかな?

59 :名無しさん@お腹いっぱい。:03/09/29 22:53 ID:???
>>50-53
三足セットを別商品にして\1,000の単価をつけ、
三足セットの内訳「靴下×3」を部品表構造で表現するのは?

60 :NAME IS NULL:03/10/15 09:17 ID:???
>>50
在庫と商品を別テーブルにすればいいんじゃないかな?

61 :NAME IS NULL:03/11/04 14:38 ID:???
age

62 :NAME IS NULL:03/11/07 01:58 ID:???
DATARUN 忘れられてる?
データの発生源から entity を抽出してゆく方法は、
目からうろこでした。

63 :NAME IS NULL:03/11/15 00:38 ID:6MpuOD/N
DATARUN は独自表記だから日本じゃ流行らない。

64 :もでるConflict:03/11/26 23:03 ID:y70urj7V
渡辺幸三著「業務別データベース設計のためのデータモデリング」に継承属性に関する説明があるが、
正規化違反せずに実装する例が示されていません。継承属性を含むモデルを正規化違反せずに実装する
例を示せる人いますか?(もちろん著者は示せるだろうが)教えてください。例えば、p153 図5●将来の日別在庫推移
を管理する、における(商品C)は継承属性を含むモデルとして挙げられます。

65 :NAME IS NULL:03/11/30 09:27 ID:pfYVgiCC
>>64

トリガーとか使って関連テーブルから
読み込ませるとか?

66 :NAME IS NULL:03/12/04 23:24 ID:fvR2Sp9q
データモデリングに関しての
いいホームページとかないですかねえ?
ITアットマークとか見てるのですが
モデリングに関してはなかなかないですね。


67 :NAME IS NULL:03/12/06 18:45 ID:PHxQoDnU
MSDNのARCHのVISIOを使ってるんだけど、
これ、リバースエンジニアリングしたのをさわった後、
実際にテーブル構造を書き換えるにはどうすればいいのでしょうか?


68 :いなむらきよし:03/12/09 13:42 ID:90H4pzxx
キケー!

69 :NAME IS NULL:03/12/10 21:34 ID:6/7ibqHE
T字型ERで教えていただきたいのですが、
会社で社員が部門に所属しているのを表すとき、
社員(社員コード、氏名) 部門(部門コード、部門名) 所属(社員コード、所属部門コード)
のようになるようなんですが、T字型でないERの場合は
社員(社員コード、氏名、所属部門コード) 部門(部門コード、部門名)
となると思うのです。
T字型ERでは所属というのを設ける理由はなにでしょうか?


70 :NAME IS NULL:03/12/10 23:27 ID:fNZKjiUj
>>69
社員が一人が複数の部署に配属される場合以外は
あまり必要がないような気がしますね。

71 :NAME IS NULL:03/12/10 23:51 ID:???
>>69
社員と部門の間に依存関係が存在するかどうかの違い。
部門に所属しない社員が許容されるならば、必然的に上の形になる。
所属部門コードにNULLを許して下の形の社員テーブルとする場合は、
概念スキーマ上の社員と所属を結合したものと考える。
あとは>>70の言う通り、所属の主キーを何にするかによっても
表現するものが変わる。

72 :69:03/12/12 08:56 ID:???
ありがとうございます。
データの状況や考え方次第ということですね。

73 :NAME IS NULL:03/12/12 17:06 ID:yh7D7A4g
>>71
うーん、納得できないなあ。

部門に所属しない社員がいるとしても、社員が最大ひとつの部門にしか
所属できないとしたら、概念レベルでも「所属」は必然的ではないと思うな。
概念レベルでそういうエンティティを設けてそのまま実装したら、
ひとりの社員が複数の部門に所属しないための余計なコードを書かなきゃ
いけなくなるからね。

74 :NAME IS NULL:03/12/13 17:11 ID:???
>>73
>概念レベルでそういうエンティティを設けてそのまま実装したら、
>ひとりの社員が複数の部門に所属しないための余計なコードを書かなきゃ
>いけなくなるからね。

なんで?制約で表現できると思うのだが。

75 :NAME IS NULL:03/12/15 09:38 ID:8oMPv+z7
>>74
「所属」にどんな制約を組み込めば、
複数の部門に所属する社員が登録されるのを
避けれるんだろう。

76 :NAME IS NULL:03/12/15 19:35 ID:???
>>76
社員キーをユニークにするんじゃだめなんか?

77 :NAME IS NULL:03/12/15 20:01 ID:8oMPv+z7
あれ?T字型では「所属」のユニークキーは
社員コード+所属部門コード
になるんではないのかな。

もしユニークキーが社員コードだけだと
すると、「所属」ってのは「社員」とキー
がいっしょってことになるな。
所属部門コードがNULLではありえないなら
「所属」って意味ないような気がするんだが。


78 :NAME IS NULL:03/12/16 23:03 ID:???
>>77
>もしユニークキーが社員コードだけだと
>すると、「所属」ってのは「社員」とキー
>がいっしょってことになるな。
>所属部門コードがNULLではありえないなら
>「所属」って意味ないような気がするんだが。

「社員」「部門」はエンティティ、「所属」は「社員」と「部門」間の
リレーションシップを表現している。
意味がないと思うなら、>>71の言う通り、論理設計の段階で
結合してしまえば良い。

79 :NAME IS NULL:04/01/01 20:26 ID:???
>>69-78
そのモデルだと所属が変わったときにその事実がどこにも残らないだろ。

モデリング対象の会社に社員の所属変更があるのなら、
配属イベント(配属コード、社員コード、部門コード、配属日)を置く。
そこから所属(=指定日付における所属状態)がすべて再現できる。


80 :NAME IS NULL:04/01/02 00:33 ID:???
>>79
そりゃ要件しだいだな。
履歴が必要ならそういう設計もするだろうが、必要ないなら
徒にトランザクション性能を下げるだけだし。

結局のところ、業務分析した結果にそれが現れるかどうかだろう。

81 :NAME IS NULL:04/01/02 00:34 ID:mdzOBQVK
Kさん 好循環  Aさん 悪循環  
 (健康体)  (喘息)

1.(神が喘息であるかないかを決める)

2.K 喘息でない人 A 喘息の人は
は体力がある    体力がなくなる

3.K        A 行動力、
          五感(嗅覚)が鈍り感性が変化する

4.K&A 神は異常な感性の人間は本来人に迷惑をかけ
るから外に出てはいけないと思っている。

5.K 変化なし   A アトピーになる

6.K 正常な感性  A 外に出なくなりさらに異常な感性になる

7.K 正常な人間   A 異常な人間(レッテル)


82 :NAME IS NULL:04/01/02 08:01 ID:???
>>80は業務分析と設計の区別がついていないのか?
「業務分析」の結果に配属履歴が現れるかどうかは、「業務」によって決まる。
だから「モデリング対象の会社に社員の所属変更があるのなら」と言ってる。
業務は個別アプリケーションの都合で変わりはしないからな。
分析結果に履歴形式が現れた場合に、実際に履歴テーブルとして実装するかどうかは
設計段階で決めることで、トランザクション性能云々はこのときに考えること。

>>69-78はそういうことを踏まえずに、
配属イベントをすっとばして所属の話だけをしてるから、
それはおかしいっつってんの。


83 :NAME IS NULL:04/01/02 09:56 ID:???
>>82
>「業務分析」の結果に配属履歴が現れるかどうかは、「業務」によって決まる。

これは問題ないが、

>だから「モデリング対象の会社に社員の所属変更があるのなら」と言ってる。

ここがおかしい。所属変更があるということとその履歴が必要というのは
要件としてイコールじゃないから。

だから>>79が最初に言っている

>そのモデルだと所属が変わったときにその事実がどこにも残らないだろ。

これが必要かどうか次第なわけ。

実際、一人の社員が複数の部署に所属し得るという事実を表現するのには
>>69のモデルで十分だし、それは所属変更がありうるとしても変わらない。

84 :NAME IS NULL:04/01/02 15:13 ID:???
>実際、一人の社員が複数の部署に所属し得るという事実を表現するのには
>>>69のモデルで十分だし、それは所属変更がありうるとしても変わらない。

うーん、やっぱり設計と業務分析の区別がついてないね?
>>69のは、テーブル設計(設計の成果物)としては有りだが、
モデル(業務分析の成果物)としてはおかしいんだよ。
ここはモデリングのスレだろ。


85 :NAME IS NULL:04/01/03 01:01 ID:???

>>>69のは、テーブル設計(設計の成果物)としては有りだが、
>モデル(業務分析の成果物)としてはおかしいんだよ。

おーい、>>69が業務分析だと言っている香具師がどっかにいたか?
もしかして「モデリング」=「業務分析」とか?

つか、>>84にとっては「業務分析」と「テーブル設計」の間って
ないのかよ?

>ここはモデリングのスレだろ。

そう。データモデリングのな。

86 :NAME IS NULL:04/01/03 05:06 ID:???
>おーい、>>69が業務分析だと言っている香具師がどっかにいたか?

T字ERを>>69自身が持ち出しているんだから、分析の文脈で捉えるのが自然だろ。

>もしかして「モデリング」=「業務分析」とか?
>
>つか、>>84にとっては「業務分析」と「テーブル設計」の間って
>ないのかよ?

??? なんでこう話がかみ合わないかな…。
もしかして>>85はT字ERを知らないんじゃない?


87 :NAME IS NULL:04/01/04 02:19 ID:???
なんか、「業務分析」と分析フェーズ全体をごっちゃにしてないか?
T字型ERは業務分析だけで使うもんじゃないだろうに。

まぁそれは言葉の問題だとしても、分析フェーズのoutputってのは
要求分析を経てシステム境界等が明確に定義されているべきもの
なんで、要件と無関係に>>79のような断言はできるはずがない。

純粋に業務分析の話ならば、社員の所属変更というごく一般的な
プロセスについてなんらかの言及ができてもおかしくはないと思うが、
誰も最初から>>69がそういう意味での業務分析のことだと思って
いないし、>>69自身そのつもりじゃないだろう。
もともと業務分析じゃないものを「業務分析としておかしい」と言われ
ても意味不明だし。

とりあえず>>84

>>>69のは、テーブル設計(設計の成果物)としては有りだが、
>モデル(業務分析の成果物)としてはおかしいんだよ。

これだけじゃ何も言っていないのと同じだから、具体的にどう
おかしいのか説明してくれないかい?

確かに俺はT字型ERは使ったことがないしよく知らないけど、
業務分析から設計までスムーズに落とし込めるという謳い文句の
T字型ERで、逆にそこのところの明確な切り分けをどのように
行うのか興味があるしな。

88 :NAME IS NULL:04/01/06 04:42 ID:???
遅くなってすまん。

>誰も最初から>>69がそういう意味での業務分析のことだと思って
>いないし、>>69自身そのつもりじゃないだろう。

そうか、>>69自身が業務分析のつもりが全くないということが、
まだサワリの段階だったら十分ありえるわけだね。了解。

具体的にどうおかしいのかの説明かあ。
困ったな、俺にとっては自明なことなんだよ。T字型ERを算数にたとえると、
「算数では1+1=10になるようなのですが、なぜ10になるのですか?」
という質問のどこが具体的にどうおかしいのか、と聞かれてるような感覚。
でも「1+1は算数では2が答えだから、10になるという仮定は違うよ」という
言い方は算数を知らない人には絶対うまく伝わらないよね?
なので、どう説明したらいいものかと。

うまくできるかわからんが、T字型ERの体系をざっくり解説してみようか?
別に、T字型ERマンセー、って主張するわけでもしたいわけでもないけれど、
変な誤解(>>69のいう「所属」がT字型ERで普通に導かれる、というような)は
解きたいとは思うんだ。


89 :NAME IS NULL:04/01/08 00:54 ID:???
あぁ、道理で話が噛み合わなかったわけだ。
>>79の「配属イベント」が必要という話じゃなくて、>>69の「所属」が
余計だという話をしてたわけね。

>なので、どう説明したらいいものかと。

要は「T字型ER」での「業務分析の成果物」にはなんらかの「禁則」が
あって、>>69はそれに反している、ということだろう?それを一言で
指摘してもらえば済む話かと思ったんだが。

というか、具体的に、ってのは

>変な誤解(>>69のいう「所属」がT字型ERで普通に導かれる、というような)は
>解きたいとは思うんだ。

というようなことををはっきり書いてもらえばそれでよかったんだが。


90 :NAME IS NULL:04/01/09 03:45 ID:???
>要は「T字型ER」での「業務分析の成果物」にはなんらかの「禁則」が
>あって、>>69はそれに反している、ということだろう?

そういうこと。回りくどくてすまん。


91 :SS:04/01/15 00:32 ID:???
 T字型ERってのは業務モデリング手法であって、
実装については何ら言及していないと理解してる。

 T字型でモデリングした後、実装で

 社員コード・名前・部門コード
 部門コード・部門名

なんて実装もありだと思われ
−−−−−−−−−−−−−−−−−−−−−−
 T字型マンセーの解説キボン

92 :NAME IS NULL:04/01/15 12:38 ID:???
>>91
もう一回ちゃんと本を読め
論理モデルと物理モデルの乖離を否定するのがT字形だぞ

93 :SS:04/01/16 00:38 ID:???
>>92

 それは幻想と思ってる。もう3回読んだよ(ry

 プライマリーキーがどれになるかがわからないリソースや
イベントの例に悩んでいてこう結論つけた。このまま実装す
るなら全テーブルに連番でも振らないと実装出来ない予感。

 DWH(データマート)やチューニングの話がミスディレクション
になってるんだよきっと。佐藤さんは推理小説好きなんだろう

 「論理データベース論考」のP198にこうある
・対照表を実装するのかしないのか、という点を判断する
・サブセットについては、最上位のセットと・・するのかを判断
・VEについては、派生源のentityに戻して実装するのか・・判断

 結局、実装では属人性を排除出来ていないじゃん(w

 まあそれでT字形の偉大さが毀損されると思わないけど、
本だけでチャレンジした人はきっとSDIにコンサルを依頼
するしかないのかも。毎度あり〜

94 :NAME IS NULL:04/01/17 14:09 ID:???
連番?
ビジネスに出てこないアイデンティファイアを導入したらアウトでしょ。
どういうので悩んでいたのか言ってみて?

俺は論理データベース論考は何十回か通読したけど、
SDIやヒューネットのコンサルもセミナーも受けてない。
考え方を身に付けるのが目的だから、
特定のツールを売り込まれたりしたら嫌だし。

確かに、実装の属人性排除はT字形ERの謳い文句には入ってないね。
DBMS側の技術導入で実装には新しい解が出てくるから、普遍化できない。
(例えば今ならサブセットはORDBMSのテーブル継承で実装できるとか。)
だから、実装にあまり突っ込まないT字ER手法の態度は真っ当だと思うが、
実装まで全部を体系化して欲しいと思う人には物足りないかもね。


95 :NAME IS NULL:04/01/17 15:58 ID:???

この人は何を言っているのだ?

96 :age:04/01/18 21:26 ID:oePWTAbL
>95

 実用書でなく単なる学者のたわごとだと言ってるのかな?
何十回も通読しないとわからないのは実用書ではないからね。

97 :NAME IS NULL:04/01/20 00:49 ID:???
そうか。3回読んだだけで、他人に説法できるほど理解できるのか。
神か仏だな。

まぁ、神や仏は他人を馬鹿にしたりはしないが。


俺は知ってるけど、お前ら馬鹿だなという書き込みほど役に立たないものは無い。

98 :SS:04/01/21 03:37 ID:???
>>97
> まぁ、神や仏は他人を馬鹿にしたりはしないが。

 神や仏でもないし他人を馬鹿にした覚えはないが。

 今日佐藤さんに聞くと、T字形を大幅に変更したらしいよ。
今年には新書を出すと言われてたので楽しみ。実装につい
ても言及して欲しいといっておいたけど、どうなる事やら。

 また数十回読むのでしょうか。大変ですね。


99 :T型フォード:04/01/22 00:32 ID:???
>>91
>  T字型でモデリングした後、実装で
>  社員コード・名前・部門コード
>  部門コード・部門名
> なんて実装もありだと思われ

 ちょっとマジレスすると、サブセットを上位テーブルに実装
するのは「アリ」だが、対照表を上位に実装するのはルール
違反だと思われます。

 T字形って、プライマリーキーを意識せず実装するっての
が信条のように思ってます。DBによって違うでしょうが、
連番を振ってプライマリーにするのも「アリ」でしょう(多分)。


100 :NAME IS NULL:04/01/22 19:44 ID:???
>>98

>  今日佐藤さんに聞くと、T字形を大幅に変更したらしいよ。
> 今年には新書を出すと言われてたので楽しみ。実装につい
> ても言及して欲しいといっておいたけど、どうなる事やら。

へぇ〜。新書が楽しみだ。期待したいな。

101 : :04/01/25 23:31 ID:HFlIdygC
 渡辺幸三ってひとの本がすごいっておもうんですがどう?


102 :NAME IS NULL:04/01/27 11:18 ID:???
ウルトラマンとガンダムどっちが強いかって喧嘩してる子供と同じだな

銀の弾など無いんだし、お前がそれで納得のいく仕事ができればそれでいいじゃないか…

103 :NAME IS NULL:04/01/27 23:50 ID:???
>>102
探しているのは銀の弾ではなくガンド・ロア クラスの兵器かと。

104 :NAME IS NULL:04/01/31 03:52 ID:???
DBDesigner使ってる人少ないのか?オープンソースの良ツール
なんだが。
http://fabforce.net/dbdesigner4/

メニューとか英語なのは痛いが、一応日本語も(難あり)使えるし、
モデリングには結構いいツールなんで、使ってみてくれ。

Delphi使える人とか、日本語化してくれると尚良いなぁ。

105 :NAME IS NULL:04/01/31 04:51 ID:???
日本語使いたきゃ別のツール使うんじゃない?
SIとかさ。

106 : :04/02/12 22:56 ID:???
シンプルな商品マスタはこんなのでしょう

〔商品M〕   商品C  販売単価  仕入単価
         ~~~~~~
         ABC    \300     \200

 カラー・サイズがないならこれで充分でしょう。

 ところがこれで販売管理を作って運用すると
大変な事がわかります。商品数が5000件もある
ならまず間違いなく運用出来ません。

−−−−−−−−−−−−−

 年1回半分ほども単価変更が発生すると徹夜
作業になってしまうのです。さてどうしましょ?

107 :NAME IS NULL:04/02/13 00:00 ID:???
まずは、なぜ徹夜作業が必要なのか考えてみ。

108 :NAME IS NULL:04/02/13 17:07 ID:???
>>106
長年の疑問だが、商品マスタの単価の扱いは、どうするのがベストなのだろう。

COBOLの時代なら、同一レコードに単価項目を2つ(新旧)持ち、適用年月日
で判断するというのが一般的だったけど。

厳密に正規化すれば、単価は、商品マスタとは別に、
商品単価マスタ{商品コード、適用年月日、単価}を作ることになるけど、
この場合、適用年月日の判断が入るため、SQL一発で単価を取得できない。
そこで、ストアド・ファンクション使ったりするのだけど、内部的には結局カーソル
処理を行うことになる。

一方、旧来のCOBOL的なレイアウトだと、OracleならDecode関数で、一発取得
可能となる。他の製品でも、これは、可能だろう。
ただし、単価の履歴は2世代しか管理できない。

要件にもよるだろうけど、この辺、みんなどうしてるのかな。

109 :NAME IS NULL:04/02/13 22:16 ID:???
>この場合、適用年月日の判断が入るため、SQL一発で単価を取得できない。

なんで?

110 :NAME IS NULL:04/02/13 22:48 ID:Y1CFmVqe
>>108
>厳密に正規化すれば、単価は、商品マスタとは別に、
>商品単価マスタ{商品コード、適用年月日、単価}を作ることになるけど、

 「単価」を繰返し項目ととらえないなら、正規化違反じゃないよ

 エンティティをリソースとイベントに分ける考え方からいうと、
全項目に日付を入れるとイベントに近くなってしまう

 ホストだと、過去データの洗い換えするためにそういう実装
することがあるけど、バッチ処理をなくす方向で考えた方が、
パソコン(鯖)向きだと思う

111 :108:04/02/14 00:32 ID:???
>>109
え、できるの?
できるなら、ぜひそのSQLを教えて欲しい。

>>110

>「単価」を繰返し項目ととらえないなら、正規化違反じゃないよ

漏れもそう考えてたんだけど、最近、佐藤正美氏の本を読んで(まだ理解が浅いけど)、
むしろ、商品単価エンティティはeventと考えるべきなのかなという気がしている。
「eventの定義は、「DATE」が帰属するentityである、とする。」だそうだ。
読み違いの可能性も強いが・・・・。

別にT字型ER手法をマンセーするつもりはないけど、佐藤氏の本は色々考えさせられる。


112 :NAME IS NULL:04/02/14 09:17 ID:CE18kft9
>111

:問い合わせ年月日 時点の単価を求めたい場合

select A.商品名, B.単価
from 商品マスタ A
join 商品単価マスタ B on ( B.商品コード = A.商品コード )
where A.商品コード = :問い合わせ商品コード
and B.適用年月日 <= :問い合わせ年月日
and not exists (
select * from 商品単価マスタ
where 商品コード = A.商品コード
and 適用年月日 <= :問い合わせ年月日
and 適用年月日 > B.適用年月日
)


113 :108:04/02/14 16:02 ID:po36sjDo
>>112
Thanks!!!

確かに、やってみると出来る!

でも、理屈が理解できん(泣
Exists、Not Existsを勉強し直そう。

114 :108:04/02/14 16:51 ID:po36sjDo
直積表を書いてみて、やっと理解できた。

きっと、知ってる人にとっては当たり前の手法なんだろうけど、凄いなあ。
こういう方法があるとは。
Not Exists内のSQLは、主キーのみ参照なので、アクセスも軽い。

重ね重ねThanks>>112

115 :NAME IS NULL:04/02/15 00:59 ID:EVaACx4p
>>111
>「eventの定義は、「DATE」が帰属するentityである、とする。」だそうだ。

 本では、従業員マスタの例があったと思うけどイベントだととらえる
のは「入社イベント」であってマスタじゃない

 佐藤さんの言うDATEを文字通りとらえると、全部のエンティティが
イベントになるよ。更新日付くらい全部に持つからね

 「適用日付」でなく「登録日」が重要な意味をもつならイベントだろう
けど、やはりこれはリソースととらえるべきだとおもわれ

 ただ、T字形でどうなるかはわからない。乞詳しい方

116 :NAME IS NULL:04/02/15 22:14 ID:???
>>115
更新日に関する記事
http://www.sdi-net.co.jp/sdi_169.htm
http://www.sdi-net.co.jp/FAQ193.htm

単価に関する記事
http://www.sdi-net.co.jp/FAQ245.htm

単価変更に関する記述はなかった。


117 :NAME IS NULL:04/02/15 22:58 ID:fM+BL24T
>>112
スレ違いで申し訳ないです。
こっちのほうがシンプルでよさそうな気がするけど、、、ダメ?

select A.商品名, B.単価
from 商品マスタ A
join 商品単価マスタ B on ( B.商品コード = A.商品コード )
where A.商品コード = :問い合わせ商品コード
and B.適用年月日 <= :問い合わせ年月日
order by B.適用年月日 desc;

レコード数の抑制は
PostgreSQL、MySQL だと LIMIT句、SQL Server だと top が使える。

118 :NAME IS NULL:04/02/16 00:35 ID:???
>>101
どのへんが?

>>104
MySQL用じゃないのか?

>>117
1票

119 : :04/02/17 00:22 ID:???
>>117
> >>112
> こっちのほうがシンプルでよさそうな気がするけど、、、ダメ?

 結果は同じだけど、order byを使うと普通コストが高い
10万件程度のデータを作ってテストすればわかる
(はず・・実装によって違うから)

120 :NAME IS NULL:04/02/21 02:48 ID:yCOAnZGt
 TH法ってのを聞いたのですが、
メリット・デメリットとかご存知ですか?

 マイナ〜な手法なんでしょうか

121 :NAME IS NULL:04/02/21 19:49 ID:???
TH法がマイナーっていわれると時代を感じるな
椿さんの本を買って読め

122 :NAME IS NULL:04/02/22 13:50 ID:/gnEdeW3
 amazonで調べると、椿正明って人ですか?

 過去の苦い経験からオーム社ってのが信用
出来ないのですが・・・書評も1件しかないって
のは終わってる本なんじゃないですか

123 : :04/02/26 02:00 ID:???
 DOAを調べてると、なにげに面白そうな事をやってました
http://www.doaplus.com/

こういう学術的な(?)会と2chは無縁でしょうか
どなたか参加されてます?

124 : :04/02/26 08:20 ID:qvDCVOss
*現代の* DOA を学ぶのによい一冊を教えてください。
600ページくらいまで、洋書でもまったく構いません。

DOAのプロジェクトにアサインされるのですが、
自分がずっとやってきたオブジェクト指向の方法論と比べて
何が共通して何が異なるのか、一通り押さえておきたいのです。


自分はオブジェクト指向の信奉者で、
構造化設計やDOAはその過程として歴史程度でしか学んでいません。

オブジェクト指向設計で言うところのユースケース、ドメインモデルは、
DOAではどのフェーズで何として書くのかが特に知りたいところです。



125 :124:04/02/26 08:21 ID:qvDCVOss
【自分の考える対比】
・機能要求、非機能要求を項目として列挙する。
→ 要求定義だから変わらないと思う。

・業務フローを描く
→ 変わらない(自分はアクティビティ図で描いていた)

・ユースケース図を書く
→ コンテキスト図に相当?

・ユースケースのシナリオを書く
→ DFDのバブルの仕様として記述?

・ドメインモデルを抽出する
→ 新業務に対するER図に相当する?しかし振る舞いを描けない

・ドメインモデルの状態遷移を記述
→ 変わらない

● 特に分からない疑問
・ユースケースからDFDを導くのなら理解できるが、DFDからユースケースを導けるのか
 シナリオは、DFDのバブルに対する説明として記述する?
・ユースケースシナリオ(外部から見た、システムの振る舞い)は、どの時点で決めるのか
  DFDでは「システムがどう動くのか」は分かるかもしれないが、
  「ユーザーがどのようにシステムとコミュニケートするのか」は分からないと思う。
  



126 :NAME IS NULL:04/02/27 00:37 ID:Pd0YyzCW
DOAでUMLは重要ですか?またどの図を使いますか?

127 :NAME IS NULL:04/02/27 22:42 ID:jks+KnjA
>>124
>600ページくらいまで、洋書でもまったく構いません。

 DOAは日本の文化です。歴史と伝統が必要な技です。
米国人には無理です。

 DOAはビジネスを知らないと本当にはわかりません。

 生産管理に興味があれば
「生産管理・原価管理システムのためのデータモデリング」
が一押しです。どういうビジネス的要件からどういうモデリング
になるかが丁寧に解説されています。

 ただ、これには正規化の方法論が書かれていません。同じ著者の
「業務別データベース設計のためのデータモデリング入門」の
前半は実務で使うための初心者向け解説になっています。
たった3つのルールだけで、完璧な正規化(1〜5&BC)にする
秘伝も書かれています。たぶんこれは著者オリジナルでしょう。


128 :NAME IS NULL:04/02/29 16:02 ID:???
>>112
商品名の履歴が必要なシステムで、

:1年前の年月日 時点の商品名を求めたい場合

はどうしたらいいですか。結構複雑になりそうな気がしますけど。

129 : :04/03/04 00:46 ID:???
>>128
 無視されてるのじゃなくて、答える必要を感じてないんですよ

 求めたい日付を「問合せ年月日」に入れるSQLですから、
求めたい日付がわかってるなら困ることないですね(*^ー゚)b


130 :128:04/03/04 08:49 ID:???
勘違いしてました。
全然問題ないですね、問い合わせ年月日が1年前でも。
失礼しますた。


131 : :04/03/04 21:25 ID:???
>>130

 現実の業務だと、売上の「前年同曜日比較表」ってのがあったりします。
曜日によって売上が大きく違いますから「同日比較」だと意味ないのです

 こんなのは流石にSQLで書けないでしょう

132 :(゜Jし゜):04/03/04 23:28 ID:???
昔、我が社で開発した前年度比計算プログラムでは、
うるう年のチェックをしてなかったので、先月末に大パニックになったらしい。

133 : :04/03/05 08:08 ID:???
>>132

 Windows2000のSP2でも、ある操作をすると日付が2/30
になるっているバグがあった。それよりはましだろ

 2/29が日曜だったので大きな混乱がなくてよかった

134 :NAME IS NULL:04/03/11 16:00 ID:???
>>131
各年の基準日をテーブルに入れておけば
基準日からの日数を計算してSQLで処理できそうだけど
そんなに甘いもんじゃない?

135 :NAME IS NULL:04/03/25 00:07 ID:SVaksVzX
age

136 :NAME IS NULL:04/05/23 22:43 ID:???
ERすたでぃおのライセンス高すぎ

137 :NAME IS NULL:04/06/29 00:24 ID:4yFnbnwy
総勘定元帳のテーブル作ってみたら凄い横長になっちまったんですが、どうしたもんでしょう・・・

部門コード、勘定科目コード、繰越残高貸借区分、繰越残高、当年借方第1月金額〜当年借方第12月金額、
前年第1月実績金額〜前年第12月実績金額

・・・とまあ基本がこんなんで、これにさらに配賦と予算(当年・前年で各月ごと)を入れると
物凄い長さになるんですが、こういうものなんでしょうか?

やはりカラムに年や月を作ってレコード分けてしまうべきなんでしょうか?
どなたか有効な意見をいただけると幸いです

138 :NAME IS NULL:04/06/29 07:07 ID:???
>137
データの発生元が異なる物を同じテーブルに入れない方が良い.


139 :137:04/06/29 20:40 ID:???
すると例えば、こうでしょうか

部門、勘定科目、会計年度、繰越残高貸借区分、繰越残高、借方金額1〜12、貸方金額1〜12

140 :NAME IS NULL:04/06/30 01:09 ID:???
>139
借方金額、貸方金額は別テーブルから導出できない?
導出可能なデータはViewでもってもテーブルにもたない方が良い.
よほど速度を気にする場合は別だが.

総勘定元帳 ってのは 記録媒体 だよね?
記録媒体の項目を単純にテーブルにマッピングしてはだめだよ.
データ発生源が何かをちゃんと考慮してあげないとデータ再利用性が低下する.

141 :137:04/06/30 03:14 ID:???
うーん、そうすると仕訳の明細を持ってるテーブルから算出する形になるかな?
いちいち計算させるのはどうかと思ったのでテーブルに持たせた方がいいかなあと

まあ、元帳や試算表を出すのは月次と決算の時ぐらいだから個々の勘定を画面に出す時の
速度に問題がなければ、わざわざテーブルに持たせる必要はないんでしょうけど・・・

142 :NAME IS NULL:04/06/30 06:21 ID:???
>141
>> いちいち計算させるのはどうかと思ったのでテーブルに持たせた方がいいかなあ

正規形をくずすのは後で良いと思われ.
Viewとして計算させた値を保持させとけば良いのでは?
テーブルとして持たなくても良いとおもわれ.
できるだけデータはプリミティブに保持させておいた方が.

まずはデータをプリミティブに保持したテーブル群から作成したViewで 総勘定元帳View 作成しておく.
正規形くずしてもView定義が変更されるだけで、プログラムには影響ないようにするのが良いのでは.



143 :NAME IS NULL:04/06/30 07:04 ID:???
>141
あと個人的経験よりのアドバイス.
もしも元の考え通りに借方金額等を同じテーブルに入れるなら、別のプリミティブデータのテーブルからコピーする事になるだろう.
だが、ここでプルグラムを作成させるなよ.どうしてもやりたいならトリガでやれ.

とにかくやつらにプルグラムを作成させるな.

借方金額をいちいちプリミティブテーブルからView上で再計算させる速度なんてたいした事はない.
やつらの作成した 元帳View から帳表を出力するプルブラムの方がよっぽど遅い.



144 :137:04/07/01 21:55 ID:???
>>142-143
ありがとうございます
大変、参考になりました

また、意見がほしくなったらココ来ますね

145 :NAME IS NULL:04/07/04 01:59 ID:SPlLydxx
クラスタ表って、どのくらい使われてるのだろう。
とりあえず、俺が設計するなら一生使いたくないのだが。

クラスタキーの利用頻度、メリット・デメリットを知りたい

146 :NAME IS NULL:04/07/08 22:31 ID:???
T字型ERってどうですか?

147 :NAME IS NULL:04/07/08 23:59 ID:???
>145
>> 俺が設計するなら一生使いたくないのだが。
なぜ?

クラスタ化は検索中心の複数テーブルをJOINする場合に速度上の利点がある.
わたしの場合は第4正規化あたりまでする(正確には最初から第4正規化されてい
る状態で設計する)ので、更新は早いが検索が遅くなる傾向にある.
その場合にクラスタ化する.

>146
使い用.


148 :NAME IS NULL:04/07/09 00:09 ID:???
途中で送信してしまった.

>146
T字形だよ.良くまちがえられるけど.
DBの知識にしたがった方式.
知っているのと知らないでは格段に違うのは確かだけど、そのまま信じきるのもどうかと思う.
DATARUNと併せて知っておいた方がいい方法論.
最近はアジャイルデータベースとかオブジェクト指向方面からの方法論もいろいろあるようだ.




149 :NAME IS NULL:04/07/23 10:53 ID:???
>>146

      r;ァ'N;:::::::::::::,ィ/      >::::::::::ヽ
.      〃  ヽル1'´        ∠:::::::::::::::::i
       i′  ___, - ,. = -一   ̄l:::::::::::::::l
.      ! , -==、´r'          l::::::/,ニ.ヽ
      l        _,, -‐''二ゝ  l::::l f゙ヽ |、 ここはお前のER図じゃねえんだ
        レー-- 、ヽヾニ-ァ,ニ;=、_   !:::l ) } ト
       ヾ¨'7"ry、`   ー゙='ニ,,,`    }::ヽ(ノ  「ラピュタ」の中にでも書いてろ
:ーゝヽ、     !´ " ̄ 'l,;;;;,,,.、       ,i:::::::ミ
::::::::::::::::ヽ.-‐ ト、 r'_{   __)`ニゝ、  ,,iリ::::::::ミ    
::::::::::::::::::::Vi/l:::V'´;ッ`ニ´ー-ッ-,、:::::`"::::::::::::::;゙ ,  な!
:::::::::::::::::::::::::N. ゙、::::ヾ,.`二ニ´∠,,.i::::::::::::::::::::///
:::::::::::::::::::::::::::::l ヽ;:::::::::::::::::::::::::::::::::::::::::::/ /
::::::::::::::::::::::::::::::! :|.\;::::::::::::::::::::::::::::::/ /

150 :NAME IS NULL:04/09/10 21:46:17 ID:???
>>98
新作マダー?

151 :NAME IS NULL:04/09/20 19:27:25 ID:6Fl/7m0x
visio2003なんですが、データベースのER図で
ただの矢印でなくリレーションの種類によって
蛸足とか丸印とか付いてるのを見かけます。
あれはどうやったら出せるのでしょうか?


152 :NAME IS NULL:04/09/22 12:16:06 ID:???
2000しか知らないけど、線のプロパティで始点と終点の形状を弄れば出てくるぞ。

153 :NAME IS NULL:04/09/24 16:52:16 ID:AXzql5sY
たとえば顧客マスタで、顧客には最大5人まで担当者がいる場合に、

顧客コード・顧客名・担当1・担当2・・・担当5
とするか、

顧客コード・顧客名
担当コード・顧客コード・担当
というふうに2テーブルに分けるか、どうしたものだろう。

担当者の最大値が決まっている場合には繰り返し項目にならないと
思うので(違ってたら指摘して!)、正規化違反にはならないと
思うのだが、作ろうとしてるテーブルの列数が40位になりそう
なので、分けたほうがいいのかしらんと迷ってます。

154 :NAME IS NULL:04/09/24 17:40:43 ID:???
迷うならとりあえず正規化しとけ。
プログラミング局面では、最大値が決まっていようがいまいが正規化されてるほうが楽な事が多いよ。
担当者が3人以上いる顧客を抽出・・・ってな要件が出たとき、横に長いテーブルだとマンドクサ
あくまで例えだけど。

155 :151:04/09/25 00:26:24 ID:???
>>152
ありがトン!


156 :NAME IS NULL:04/09/25 01:29:10 ID:axxmUZh0
>>154
でも担当者を横一列に並べようとする時に
正規化するとめんどくさいですね。

明細がぶらさがるとかじゃなくて
5人って決まってる場合は
そういう出力の仕方の方が多くないかな。

でも>>154の要件もあるかも知れないし
出力する局面でどっちにするか判断するって
ところじゃないでしょか。

157 :NAME IS NULL:04/09/26 00:57:28 ID:???
>>156
出力する局面で正規化するしないを判断するなんて論外。

・担当者別顧客リストなんて間違いなく要件の中にあるはずだが、どうやって実現する?
・とある担当が辞めた場合どうする?
 全ての顧客マスタの担当項目1-5を検索して、該当する顧客レコードを更新。
 更新箇所以降の担当項目の前詰め処理。
 ↑5人横に並べるのとどっちが面倒くさいよ?

素直に正規化しておくべき。

>>154
> 最大値が決まっている場合には繰り返し項目にならない

そんなことはない。
「最大値が100だから繰り返し項目じゃないです。」
って言われても納得できないだろ?

158 :156:04/09/26 10:22:16 ID:Etehnh4k
レスくれた人さんきゅ。
繰り返し項目の正しい定義ってなんだろうね。
俺っちは、最大値が決まってる場合、担当1・担当2・・・というふうに
2次元の表にできるから、繰り返し項目にはならないのかと思ってた。



159 :156:04/09/27 10:26:37 ID:p0HsFnJ6
>>157
うーんそうか、流石に5人ともなると前詰とか考えなきゃいかんわけか。
実は俺がやったシステムは担当者は2名だったんで
正規化してませんでした(設計は別の人)。

2名だと正・副のニュアンスもあるからあえて正規化しなかったって
話かも知れなかったですね。うーん。

160 :NAME IS NULL:04/10/08 07:13:32 ID:???
担当1・担当2のようになるなら繰り返し。
最大値が決まってるというのは幻想で、実は今だけってのが現実

161 :NAME IS NULL:04/10/08 07:15:55 ID:???
最大値を制限するのはプログラム側でなくDBのトリガや制約等の機能を利用し
て制限するのが普通


162 :NAME IS NULL:04/10/08 07:16:48 ID:???
とにかくやつらにプログラムさせるな、が基本

163 :NAME IS NULL:04/10/08 07:52:30 ID:???
>>161
ユーザーにやさしくエラーを返してあげるためにプログラム側での工夫も必要?

164 :NAME IS NULL:04/10/08 10:05:34 ID:h796f5Km
>>163
それはこっちでちょっと話題になったな

制約っていらなくね?
http://pc5.2ch.net/test/read.cgi/db/1087483786/l50

悩みどころだね。

165 :NAME IS NULL:04/10/09 01:08:08 ID:???
>163
制約エラーが発生すればエラーメッセージを出すようにはプログラムする
普通のエラー処理のある言語なら問題なく可能
制約でのエラーの方がプログラムをほぼしなくて済むので良い

とにかくやつらと、そしてわたしにプログラムさせるな、が基本である事にかわりない
プログラムは組めば組むほどバグが増加する物、それはだれが作成してもだ


166 :NAME IS NULL:04/10/09 14:07:44 ID:WoYiUuS/
>>165
C/Sの業務アプリなんかだとそう理想どおりいかないんですわ。

例えば、必須項目の入力チェックをする時に、
エラー表示を閉じたら自動的に
未入力の入力欄にフォーカスを移動して欲しいって
要望があった場合、アプリ側でチェックせんといけない、
NOT NULL制約のエラーだけに頼れないんですよ。

とはいえ、制約はそれをみればドキュメントが貧弱だったとしても
設計した人の意図が浮き上がりやすいので捨てがたい。

で、制約・アプリ両方盛り込むと二重管理になる。
どうしたもんかなあ、ってところで上のスレは止まってる。

167 :NAME IS NULL:04/10/09 16:04:43 ID:???
アプリ側でのバリデーションなんてWebだろうが業務アプリだろうが当然すると思うけど
DB側の制約(CHECKとかNOT NULLとか)は制約内容とDB設計者の好みに寄る希ガス

漏れはビジネスルール的なものであればアプリ側でかけさせて
それ以外はなるべくDB側でかけさせるようにしてるかなあ
まあ、NOT NULLなんかは二重管理になりがちだけど

168 :NAME IS NULL:04/10/09 16:12:21 ID:???
ユーザーに返すエラーメッセージを「不正な処理を行ったため停止します」に統一
すればいいんじゃない?

169 :NAME IS NULL:04/10/10 13:02:37 ID:???
>>166
DBMSの制約情報を動的に読みとってアプリ側でチェックするような仕掛けを
作ればいいのでは?
結局は二重だけどDBMS側をいじればアプリ側も追従してくるようにすれば
目的は達成できる気がする。

170 :NAME IS NULL:04/10/10 14:11:41 ID:???
それやるとアプリのDBMS依存性が高くなる
 ↓
ライブラリ/ミドルウェア層にまとめちゃおう
 ↓
だったらDBMSの制約情報読み取るよりも、最初からこっちで
管理した方が融通が利いて良いよな

SAPとかそんな感じだよね

171 :165:04/10/10 19:39:45 ID:???
>166 >169
わたしの所はあるアプリでDB定義を書くのだが、そこからSQLと
Valid用XMLが自動生成されるようになっている









172 :NAME IS NULL:04/10/17 20:38:10 ID:gvma0fXW
DB設計ビギナーです。
相談に乗ってください。

たとえば次のようなテーブル群があるとします。
部署(部署ID, 部署名)
社員(社員ID, 社員名)
所属履歴(所属履歴ID, 部署ID, 社員ID, 所属開始年月日, 所属終了年月日)

社員は時を経るにつれて所属が変わるのですが、
これは所属履歴レコードを1件追加することで示します。

ここで、経年するごとに次のような変化がおきます。
・部署名が変わる
・部署が統廃合される
・部署が分裂する

このとき、ある社員の部署所属履歴をうまく保持するにはどうすればいいでしょうか。

思いつく案は次のとおりです。
(1) 部署と部署情報履歴に分ける
部署(部署ID)
部署情報履歴(部署ID, 開始日, 終了日, 部署名)
(2) 所属履歴レコードを作成する時点で、部署テーブルの情報をコピーする
所属履歴(所属履歴ID, 部署ID, 部署名, 社員ID, 所属開始年月日, 所属終了年月日)

どうするのが一般的なんでしょうか。
またどうするのが楽なんでしょうか。

173 :NAME IS NULL:04/10/18 01:10:05 ID:???
合併した部署は、新しいIDを振ればいいのでは?

174 :NAME IS NULL:04/10/18 09:55:59 ID:???
>>172
一般的な方法として、やるとしたら(2)だけど、本当にそこまでする必要が
あるのかどうかって所が一番大事だと思われ

175 :NAME IS NULL:04/10/18 16:18:02 ID:???
先生
名前・メールアドレス・パスワード・他色々

生徒
名前・メールアドレス・パスワード・担当先生・他色々(先生と全く同じパラメータ)

という構成の場合どういう設計にすべきですか?

(1)
先生
先生id(主キー),名前,メールアドレス・パスワード,他色々

生徒
生徒id(主キー),名前,メールアドレス・パスワード,先生id(外部キー:先生->先生id),他色々

(2)

人id(主キー),名前,メールアドレス・パスワード,他色々

先生
先生id(主キー),人id(外部キー:人->人id)

生徒
生徒id(主キー),人id(外部キー:人->人id),先生id(外部キー:先生->先生id)

(3)

人id(主キー),名前,メールアドレス・パスワード,他色々

先生
人id(主キーかつ外部キー:人->人id)

生徒
人id(主キーかつ外部キー:人->人id),先生id(外部キー:先生->先生id)

(4)その他

176 :NAME IS NULL:04/10/18 16:19:18 ID:???
(3)間違えたので修正

人id(主キー),名前,メールアドレス・パスワード,他色々

先生
人id(主キーかつ外部キー:人->人id)

生徒
人id(主キーかつ外部キー:人->人id),先生id(外部キー:先生->人id)

177 :175:04/10/18 16:19:55 ID:???
すいませんがageさせて頂きます。

178 :NAME IS NULL:04/10/18 16:53:31 ID:???
>>175
(4)

179 :NAME IS NULL:04/10/18 18:17:57 ID:???
>>178
具体的にはどんな感じですか?

180 :NAME IS NULL:04/10/18 22:19:10 ID:???
>>179
その前に他色々を具体的にしてくれ。

181 :NAME IS NULL:04/10/19 06:30:22 ID:???
>172
所属履歴IDって必要か?
まあそれは良いとして、部署の統廃合を管理するだけなら部署expire期間を入れるのはどうか
実質173と同じ意見だけどIDは同じにできる
# 良いかどうかは別

182 :NAME IS NULL:04/10/19 08:44:54 ID:???
>>175
要件次第でどれが適切かは変わってくると思われ。

生徒でも先生でもない人をシステム上扱う必要があるのなら、人テーブルを
分けた方がいいかもしれない。その必要がないのなら(1)で十分だと思うよ。

183 :NAME IS NULL:04/10/25 23:05:28 ID:0Gqq1XjY
すいません、ありきたりな質問なのですが、
データモデリングって何ですか?

データベースのテーブルのカラムを考える人?


184 :NAME IS NULL:04/10/26 00:49:47 ID:???
>>183
データベースのテーブルとカラムを考える事。

渡辺幸三先生の本を読んでみましょう。

185 :NAME IS NULL:04/10/26 01:10:00 ID:???
まあアレだ。
顧客の業務を視姦して丸裸にしてヌードデッサンする行為の事。

186 :NAME IS NULL:04/10/26 01:25:51 ID:???
おっ、かっこいいな。悪魔の辞典みたいだな。

187 :NAME IS NULL:04/10/26 14:10:28 ID:???
>>185
わりと死姦だったりするがな。


188 :NAME IS NULL:04/10/26 17:08:53 ID:???
なんだここは上手い事いうスレなのか。

189 :NAME IS NULL:04/10/27 00:51:41 ID:???
ヌードだからといって素直に喜べない。
異様にデブだったり極端にガリガリだったり、それ以前に
奇形なモデルだったりする事がおおいからなw

190 :NAME IS NULL:04/10/27 15:12:50 ID:???
きょうせらは人間じゃなくて単細胞生物らしいし。

191 :NAME IS NULL:04/11/18 19:46:59 ID:oOnWd0J7
ERWinのトライアル版の制約事項ってありますか?
作成出来るエンティティ数とか?

192 :NAME IS NULL:04/12/15 10:40:56 ID:???
Accessで、部品表の展開と集計をむりやりっぽくやってるんですが、
なにかうまい方法ないでしょうか・・・ ○| ̄|_

【 QRY_INV_IO_CALC_OUTPUT_1 】
SELECT
    [QRY_INV_IO_CALC_SOURCE]![ID] AS parentID,
    1 AS STRUCTURE_LEVEL,
    [品目-品目_再帰].標準部品コード2 AS PID,
    … AS ID,
    … AS eventDATE,
    … AS QUANTITY,
    …
    (Count([品目-品目_再帰_1]!標準部品コード1)>0) AS RESOLVABLE
FROM
    (
        (QRY_INV_IO_CALC_SOURCE
         RIGHT JOIN
         [品目-品目_再帰]
         ON
         QRY_INV_IO_CALC_SOURCE.PID = [品目-品目_再帰].標準部品コード1
        )
     LEFT JOIN
     部品 ON [品目-品目_再帰].標準部品コード2 = 部品.部品コード
    )
    LEFT JOIN
    [品目-品目_再帰] AS [品目-品目_再帰_1]
    ON
    [品目-品目_再帰].標準部品コード2 = [品目-品目_再帰_1].標準部品コード1
GROUP BY …;

193 :NAME IS NULL:04/12/15 10:41:12 ID:???
QRY_UNION_INV_IO 】
SELECT ID,…,eventID,eventDATE,QUANTITY,NOTE,0 AS STRUCTURE_LEVEL,RESOLVABLE
FROM QRY_INV_IO_CALC_SOURCE
UNION
SELECT ID,…,eventID,eventDATE,QUANTITY,NOTE,STRUCTURE_LEVEL,RESOLVABLE
FROM QRY_INV_IO_CALC_OUTPUT_1
WHERE RESOLVABLE=FALSE
UNION
SELECT ID,…,eventID,eventDATE,QUANTITY,NOTE,STRUCTURE_LEVEL,RESOLVABLE
FROM QRY_INV_IO_CALC_OUTPUT_2
WHERE RESOLVABLE=FALSE
UNION
・・・
UNION
SELECT ID,…,eventID,eventDATE,QUANTITY,NOTE,STRUCTURE_LEVEL,RESOLVABLE
FROM QRY_INV_IO_CALC_OUTPUT_5;

【 在庫の変遷を日ごとに集計 】
SELECT
    QRY_UNION_INV_IO.ID,
    QRY_UNION_INV_IO.inputDATE,
    QRY_UNION_INV_IO.PID,
    …
    QRY_UNION_INV_IO.eventDATE,
    QRY_UNION_INV_IO.QUANTITY,
    DSum("[QUANTITY]",
       "TBL_TEMP_UNION_INV_IO",
       "([PID] = " &
           [PID] &
        ") AND ([eventDATE] <= #" &
           Format([eventDATE],"yyyy/mm/dd") & "#)"
      ) AS STOCK,
FROM (QRY_UNION_INV_IO INNER JOIN 部品 ON QRY_UNION_INV_IO.PID = 部品.標準商品コード)
   INNER JOIN
   TBL_EVENT_INV ON QRY_UNION_INV_IO.eventID = TBL_EVENT_INV.ID


194 :NAME IS NULL:04/12/25 22:54:27 ID:ZtSP5EZK
もう解決したのかな?
いいクリスマスを迎えることができてるといいのだが。

さて・・・どう「うまく」やりたいんだろ?

パフォーマンスの改善?
今後に備えて、データモデル(テーブルの実装も含め)を見直したい?
それとも?

そもそも、
・データモデル自体を見直したいなら、SQL書かれても困る
・SQLを評価して欲しいなら、テーブル定義くらい無いと、マンドクセェ
・データの件数によっても、モデルは変える事がある
んだ。ヨロシコ。

195 :NAME IS NULL:04/12/27 18:29:20 ID:???
レスありがとうございます。
(レスを頂けた事に、正直驚いています)

テーブル定義のフォーマルな表記方法はわからないのですが、
部品とその構成情報は、
                              
 ┏━━━━━┓  ┏━━━━━━━━┓          
 ┃部品     ┃  ┃品目- 品目_ 再帰 ┃   ┏━━━━━┓ 
 ┃----------┃  ┃----------------┃   ┃部品_1   ┃ 
 ┃部品コード ┠─┨親部品コード    ┃  ┃----------┃ 
 ┃…      ┃  ┃子部品コード    ┠─┨部品コード ┃ 
 ┗━━━━━┛  ┃員数         ┃  ┃…      ┃ 
             ┗━━━━━━━━┛  ┗━━━━━┛ 
                              
のようなリレーションシップになっており、[部品]=[部品_1]です。
部品の構成に中間品が沢山あり、中間品在庫が沢山あります。

やりたいことは、
未来のある時点での在庫の推移・過不足を見ることです。

そのための方法として、
全在庫を最下位まで部品展開したうえで、
部品ごと・出入庫日ごとに、それまでの出入庫を全集計し、

 部品名   受払い日  受払い    在庫数
--------------------------------------------------
 パーツA  01/15   入庫  +350  2350
 パーツA  01/23   出庫  -900  1450
 パーツA  02/06   入庫  +210  1660
 パーツA  02/11   出庫  -870   790
 パーツA  02/19   出庫 -1390  -600  欠品発生!

のような結果を出したいと考えています。
(その方法がどこか間違っているような気もしていますが)

仕入れによる入庫や、リペアパーツの出庫などを、
過去・予定あわせて、
┏━━━━━━┓
┃在庫受払い  ┃
┃------------┃
┃ID        ┃
┃部品コード  ┃
┃受払い日時  ┃
┃受払い数   ┃
┗━━━━━━┛
に記録しました。

また、別管理の以下の表、
┏━━━━━━┓
┃出荷予定表  ┃
┃------------┃
┃ID        ┃
┃機種コード   ┃
┃出荷予定日時┃
┃出荷数     ┃
┗━━━━━━┛
( 別の担当者がEXCELで管理 )
を、アクセスクエリを数段かませ、
列が在庫受払いと同じになるように変換しました。

196 :NAME IS NULL:04/12/27 18:29:42 ID:???
在庫受払いと変換済み出荷予定表を、
ユニオンクエリで結合しました。
これにさらに、
子部品があるかどうかの判定列 RESOLVABLE を
加えたものが、QRY_INV_IO_CALC_SOURCE です。

(1)
QRY_INV_IO_CALC_SOURCE を、
子部品持ちが無くなるまで展開したい。
現状のSQL文(QRY_UNION_INV_IO)だと、
もちろん5段階までしか展開できていません。。

(2)
各部品ごと、出入庫がある時点ごとに集計したい。
現状のSQL文だと、定義域集計関数DSumを使用しているので、
途中経過を一時テーブルに書き出してもいますが、
恐ろしく処理に時間がかかります。

(3)
出荷予定表で、
出荷後一定期間を過ぎたレコードは別表に移動されてしまうため、
矛盾が出てしまう。

(3)
以上の手段自体に間違いがあるような気がする。


データの件数自体は、
まだ自分の担当の範囲内でやっているだけというのもあり、
いまのところ、

部品:約1400件
品目-品目_再帰:約1300件
在庫受払い:100件強(はじめたばかり)
出荷予定表:約800件

です。

197 :NAME IS NULL:04/12/27 18:45:20 ID:???
ちなみに、出荷予定表からの製品出荷ですが、
製造にかかる日数をうまく格納・計算する方法が思いつかないので、
とりあえす展開1階層ごとに長めの標準日数を設定し、
部品展開時に、出荷予定日から遡った日に部品が出庫(消費)する、
というふうになるよう、受払い日時を設定しました。

198 :NAME IS NULL:04/12/27 19:19:44 ID:???
すみません、
出荷予定表:100件強
(済のものを含めると7〜800件)
でした。

199 :NAME IS NULL:05/01/14 00:57:27 ID:???
>>195-198
これは SQL99の「再帰的SQL」を使う以外にないだろう.
http://www.atmarkit.co.jp/fnetwork/tokusyuu/01sql99/sql99_1b.html

つまり,現行のほとんどの DBMS では,手続き型の言語で書いた再帰構造に
短い SQL を大量に埋め込むしか方法がないと思われる.

それにしても,なぜ今まで,SQL に再帰が導入されなかったのだろうか.
SQL とおなじ宣言型言語である Prolog では,再帰は不可欠なのに.

200 :NAME IS NULL:05/01/17 11:13:03 ID:???
>>199
レスありがとうございました。

201 :NAME IS NULL:05/01/18 01:25:16 ID:dY4jJ9fs
>>195-198

 渡辺幸三さんの生産管理のモデリングの本を読んでください。
 LLC(ローレベルコード)について詳しく書いてあります。
 私の知っている限り生産管理のモデリングの最良の本です。

 在庫推移のモデルに関しても詳しく書いてあります

 いいところまで行ってるので頑張って


202 :東浩紀:05/01/18 18:39:56 ID:O7G91VlX
大きな物語が失墜し、人々はデータベース(大きな非物語)を消費するようになった
つまり人は物語に感動してるのではなくデータベースから抽出された物に反応しているにすぎない
つまり世界はこういう仕組みになってる

203 :NAME IS NULL:05/01/18 19:50:06 ID:???
>>201
アドバイスありがとうございます。
実は、その本はたびたび読み返して手本にしています。
モデリング自体も問題大有りですが、
再帰SQLの代わりになるコーディングが思いつかない段階です。

204 :NAME IS NULL:05/01/20 03:13:45 ID:TW1nlZVf
>>203

 なぜスクリプトで組まないの?

205 :NAME IS NULL:05/01/20 22:59:44 ID:TW1nlZVf
>>203

 孤軍奮闘しているようですね。渡辺さんの本の愛読者だと
いうことで、アドバイスしましょう。VBAが使えないときついかも

 LLCを良く理解されていないようです。こういう自体を避ける
魔法のコードです。ステップを以下のように3つに分けて、それ
ぞれの中で細かい処理を悩めば道は開けると思います。

 ★問題が解けそうにない時は小問題に分割するのが定石です

 以下簡単にモデルを提示してみます

206 :NAME IS NULL:05/01/20 23:01:36 ID:TW1nlZVf
【簡易MRP(在庫推移のみを一括計算するシステム)】

モデル:
[部品] {部品C}、品名、現在庫数、製造LT、LLC
[部品構成] {親部品C、子部品C}、員数
[日次受払] {部品C、日付}、入庫数、製造数、出庫数、在庫数

計算手順:
(1)[日次受払]の内容をクリアしたうえ、いろいろなテーブルに
 散らばっている現在の入出庫予定(出荷予定、製造予定、
 入荷予定)を[日次受払]に集計する
(2)LLCの小さい部品順に、[日次受払]の製造数を[部品構成]
 を使って(製造LTで日付をずらしながら)シングルレベル展
 開して、下位部品の出庫数として[日次受払]に反映させる
(3)部品毎に、[部品]の現在庫を起点として[日次受払]の日付
 順に入出庫数を加減計算しながら在庫数を更新する
(4)最初の欠品日が早い品目順に対策を検討する

欠点:
このバッチ処理を走らせないと最新の状況に応じた在庫
推移がわからない。状況にリアルタイムに反応する「在庫
推移監視方式」が渡辺本(生産管理・原価管理システムの
ためのデータモデリング)で紹介されているので、参考に
してください


207 :NAME IS NULL:05/01/21 15:25:20 ID:???
>>205
>>206
ありがとうございます!!
LLCの小さい順に展開することで、階層を最後まで展開しきることが出来るというわけですか!
目からうろこが落ちた思いです。
これから渡辺さんの本を再び読み返して理解していきたいと思います。

208 :NAME IS NULL:05/01/22 01:08:18 ID://zf7D53
>>207

 お役に立ててよかったです。渡辺本の3冊の中で私は
生産管理が最高だと思ってます。この他にもノウハウが
惜しげもなく載っていて驚くほどです。
 ※ところが一番売れてないと噂で聞きました

 確かに難しいですが、あれだけSQLを書けるのですから
必ず理解出来ます。頑張ってください。

 基本的な方針をお教えしただけですので、まだまだ
悩まれるところは豊富でしょうが、悩み甲斐ありますよ

 もしこれで利益を得る事が出来れば、コンサルフィーと
していくらでも結構ですからスマトラ募金して下さいね

209 :NAME IS NULL:05/01/23 20:56:09 ID:+1Ab9Bdi
2項モデルに拘ってる方っていらっしゃいますか。



210 :NAME IS NULL:05/01/27 09:36:44 ID:Z5JcZ2YJ
運送料と手数料を請求するとする。
この場合、運送料と手数料はテーブルを分けるべきか分けざるべきか。
どうですか皆さん?

(分ける場合)
[請求] 請求ID・顧客ID・金額
[運送料]請求ID
[手数料]請求ID

(分けない場合)
[請求] 請求ID・顧客ID・金額・区分コード

211 :NAME IS NULL:05/01/27 12:29:02 ID:Ff4IZNHF
[請求書] 請求ID・請求書ID
[請求顧客] 請求ID・顧客ID
[請求金額] 請求ID・金額
[運送料] 請求ID
[手数料] 請求ID
ならあるかな。


212 :NAME IS NULL:05/01/27 13:17:27 ID:???
>>210
請求IDと運送料、手数料はそれぞれ一対一の関係なんでしょ?

だったら
[請求] 請求ID・顧客ID・金額・運送料・手数料
でいいんじゃない?

213 :NAME IS NULL:05/01/27 13:22:42 ID:Ff4IZNHF
>211 は顧客IDから請求書を出す時苦労するな。自分で書いたのだが。
もっともPrologで書くと、
請求書(_顧客ID,_請求書ID)
 :-
  請求書(_請求ID,_請求書ID),
  請求顧客(_請求ID,_顧客ID),
  (  運送料(_請求ID),
    請求金額(_請求書ID,_金額),
    write_formatted('運送料 %t\n',[_金額]);
    手数料(_請求ID),
    請求金額(_請求ID,_金額),
    write_formatted('手数料 %t\n',[_金額])
  ),
  fail;
  true.
でどうってことないが。


214 :NAME IS NULL:05/01/27 13:39:52 ID:Ff4IZNHF
大変だ。上のプログラムは最初のSubGoalでループして終了しない。
請求書発行(_顧客ID,_請求書ID)
 :-
  請求書(_顧客ID,_請求書ID),
 <<以下略>>
にしないとね。


215 :210:05/01/27 14:41:00 ID:???
すみません、請求における運送料と手数料は排他です。
請求が10件あったとして、運送料の請求が5件で手数料の
請求が5件かもしれないし、運送料の請求が10件で手数料の
請求が0件かもしれないといった感じです。

216 :NAME IS NULL:05/01/27 15:02:24 ID:???
>>215
[請求] 請求ID・顧客ID・金額・運送料・手数料・合計金額
運送料・手数料どちらかをゼロにしとけばいいんじゃない。

217 :NAME IS NULL:05/01/27 18:01:12 ID:Ff4IZNHF
<分けた場合>は209にでてくるバイナリーモデル的なものになるが、
IDが必須でうるさくなる。ただ、Prologとの相性はいいなあ。
うんと小さな規模のデータベースではデータの結びつきについて
敏感になれて面白いかもしれない。
<分けない場合>はRDBそのものだが、行の中の列の結びつきが「以前的」で
ちょっと強すぎる。なんらかの「契機」によって結びついていると考えられるが、
やはり、神様がいる感じ。


218 :NAME IS NULL:05/01/28 00:09:12 ID:GLvUf9Af
>>217
 prologなんてまだ生きてたのか。うざいね

> やはり、神様がいる感じ

 電波受けてる?

219 :NAME IS NULL:05/01/28 03:58:05 ID:???
[発注見出]と[発注明細]があって、それに対応する[支払予定]があります。
[支払予定]は、見出単位で決定する場合と、明細単位で決定する場合の
2通りあるんですが、この場合のテーブル設計はどうすればよいだろう?

[発注見出] 発注NO、支払予定NO
[発注明細] 発注NO、行番、支払予定NO
[支払予定] 支払予定NO

こんな感じでいんだろうか?
なんかすっきりしないんだけど・・・・・・もう、まる一日以上なやんでます .... orz

220 :NAME IS NULL:05/01/28 07:49:44 ID:???
>>219
発注と支払いの間に、債務とかなんかのテーブルを一つはさんだらどうかな?

221 :NAME IS NULL:05/01/28 09:13:10 ID:???
>>219
[発注見出].支払予定NO≠[発注明細].支払予定NOの場合があるから、
[発注見出] は発注NOだけでいいんじゃない。


222 :NAME IS NULL:05/01/28 13:18:05 ID:???
>>220
債務を挟むって具体的にどんな感じになるんでしょう?

>>221
これも考えたんですが、結局はプログラム側でちゃんと整合
取れるように制御しなきゃだめですよね〜。



223 :NAME IS NULL:05/01/28 18:13:41 ID:???
[仕入見出し]+---≡[仕入明細]

[発注見出し]+---≡[発注明細]+---≡[入荷明細]

[入荷見出し]+---…[入荷明細]+---…[仕入明細]


[支払見出し]+---≡[支払明細]+--・+[仕入明細] (ここ自信無し)


明細単位で決定する場合、支払に明細行が1行、
見出し単位で決定する場合、支払に発注と同じ複数の行、
でいいのかな…?

勘定とかも絡んできそうな気がしてますます複雑に… ○| ̄|_

224 :NAME IS NULL:05/01/29 03:03:56 ID:iJcNI0vI
>>219

 業務モデルによるでしょう。[支払予定]が何をしたいのか、
支払予定NOがどのタイミングで発生するかなどを示さないと
勝手に解釈したレスになりますよ。

 一番汎用的なのはこんな感じかな

[発注見出]     {発注NO}、取引先CD、発注日、納品希望日
[発注明細]     {発注NO、行番}、品番、単価、数量
[支払発注対照表] {支払予定NO、(,発注NO)}
[支払予定]     {支払予定NO}、支払い予定日、取引先CD

 発注先のCDと支払先のCDが違うことは良くあるので[支払予定] 
にも取引先CDを入れました。もし単に締日単位に1つの番号を振る
のならこれは不要

 ただ、実務で使うなら納品(検品)のデータと関連させないと
納品されていないものまで支払う可能性があります。
-------------------
 渡辺幸三さんの「業務別データベース設計のためのデータ
モデリング入門」の購買管理にはもっと実用的なモデルが示
されていたと思います(今手元にないので曖昧です)

225 :NAME IS NULL:05/02/01 11:58:45 ID:???
>>ときどき Prolog の話を書いてる人

これからもちょくちょくご登場キボンヌ.

俺はへぼい Lisper(Schemer) で,最近データモデリングを
かじり始めたのだけど,どうにもDB の世界は,閉鎖的で
息苦しくてかなわん.他のプログラミング言語との比較という
視点が全く欠けていると思う.

SQL は Prolog の親戚みたいなものなんだから,並べて
語れば,視野がぐっと広がると思うんである.


226 :NAME IS NULL:05/02/02 23:11:26 ID:???
>>201

渡辺幸三さん、XEAD。いいです。
これがフリーソフト。信じられない。

http://homepage2.nifty.com/dbc/index.html

227 :NAME IS NULL:05/02/03 01:17:55 ID:???
>>226
本当に凄いフリーソフトですね。open sourceにして英訳すれば世界中の人が使いそう。

228 :NAME IS NULL:05/02/03 02:51:03 ID:???
これで渡辺上流工程本にあった感じのフォーマットで
ドキュメントまでそのまんま落ちたら最高なんだけど
それは望みすぎだわなー、すばらしいですよこれわ。

229 :NAME IS NULL:05/02/03 20:15:41 ID:???
>>104
DBDesigner 4はC:\Program Files\fabFORCE\Data下の
DBDesigner4_Translations.txtとDBDesigner4_Translations.iniを訳せば日本語化
できそうな希ガス。

開発元(GNU GPL)
ttp://www.fabforce.net/dbdesigner4/
DBDesginer4マニュアル(日本語)
ttp://www.aglabo.com/agl/proevo/fabforce/

230 :NAME IS NULL:05/02/03 20:34:28 ID:???
T字形ER手法の特徴の「ネスト化された条件分岐やNull値の判断を
プログラム・ロジックから排除する」とは、たとえばどういう事ですか?
ttp://www.doaplus.com/html/doc/bun01_20041206.pdf

231 :NAME IS NULL:05/02/04 00:35:00 ID:EU+jfE/i
>>230
 そのままの意味

 T字形を使うと「4,800ステップのプログラムが(「nested-IF」のない)800ステップに軽減された」
って実績もある。マスコミには出ない魔法の手法。
ttp://www.sdi-net.co.jp/ter-home.htm


232 :NAME IS NULL:05/02/04 11:35:10 ID:???
なんか、こわい。

233 :NAME IS NULL:05/02/04 16:56:20 ID:???
>>231
なんか表現がいちいちドラスティックだなあ。

そのサイトの段位表にでてくる
● 従業員のデータのなかに、部門コードが定義されていても疑問に感じない。
● 「データの一意性」を保証するために、複合キーを使ってデータ設計をする。
これが全然ピンと来ない。
特に前者、T字形ではどういう風に表現するんだろう?


234 :NAME IS NULL:05/02/04 19:45:38 ID:???
[部門]+───≡[部門-従業員_対応表(日時を入れて「配属」)]≡───+[従業員]
のようなことが書いてあったような気がします。

235 :NAME IS NULL:05/02/05 01:48:17 ID:Kdyo+DVN
>>233
 T字形を単なるデータモデリング手法だと思うと
火傷をします。これは哲学です。

 ビジネスを定義するにあたって
1.企業として共通の認識にあるものは何か?
 →番号がついているもの=識別子
  (それがユニークかは関係ない=>複合キー)

2.イベントとリソースの峻別
 →イベントとは企業活動の中で日付があるもの

3.エンティティ間の関係(4つのルール)

4.エンティティの属性(項目)としてホノニム(同音多義)や
 シノニム(異音同義)、nullになる可能性があるかを考え、
 データ分析する
 →サブセット(クラス概念は否定)

 この4を真剣に考えると、従業員のデータとして例えば
社長なら部門はnullになるし兼務者が定義できない事に
気付くはず

 ここまで分析してはじめて業務分析ができ、しかも
プログラムからロジックが消える(らしい)

236 :NAME IS NULL:05/02/07 18:37:02 ID:???
XEADはJava1.4.2が要るみたいですね…

237 :NAME IS NULL:05/02/07 22:26:05 ID:UdrSQ9Qj
>>236
1.4.1_03でも漏れは動いたよ
まあ全部の機能を試したわけじゃないが

238 :NAME IS NULL:05/02/25 17:14:43 ID:???
こんなとこ見つけました。

データモデルパターン
http://www.jsys-products.com/iwaken/data_model_patterns.html

239 :NAME IS NULL:05/02/25 21:12:10 ID:???
俺ERスタディオ使ってる

240 :NAME IS NULL:05/03/01 17:08:53 ID:???
ある機械が、機種ごとに仕様の項目数が違うとして、
これらをサブタイプとして登録したとき、実装上はどう処理するのでしょうか?

たとえば、ある複数機種の機械の納品リストを考えます。

機種A
 ノズル1からジュースが出せます。 原液タンクには4/10gタンクが使えますがボトルは使えません。
 ノズル2からジュースが出せます。 原液タンクには1.8/4gボトルが使えますがタンクは使えません。
 ノズル3からは水だけが出せます

機種B
 ノズル1からジュースが出せます。 原液タンクには4/10gタンクが使えますがボトルは使えません。
 ノズル2からジュースが出せます。 原液タンクには4/10gタンクが使えますがボトルは使えません。
 ノズル3からジュースが出せます。 原液タンクには1.8/4gボトルが使えますがタンクは使えません。
 ノズル4からは水だけが出せます
オプションとしてOPT1,OPT2,OPT3が付加できます。(重複可)

機種C
 ノズル1からジュースが出せます。 原液タンクには4/10gタンクが使えますがボトルは使えません。
 ノズル2からジュースが出せます。 原液タンクには1.8/4gボトルが使えますがタンクは使えません。
 ノズル3からジュースが出せます。 原液タンクには1.8/4gボトルが使えますがタンクは使えません。
 水は基本的に出せませんが、機種に関係なく使用できるオプション機材Wを付加することにより水も出せます。
オプションとしてOPT1,OPT2,OPT3が付加できます。(2つまで重複可能、3つ重複不可)

ジュースX1〜X9の原液は4gボトルと10gタンクのどちらかが選べます。
ジュースY1〜Y9の原液は1.8gボトルと4gタンクのどちらかが選べます。

出荷前に顧客のオーダーに合わせ、各ノズルからジュースX1〜Y9を出せるように調整し、オプションを付加します。

出荷する実際の機器には機番が一台一台についており、トレーサビリティを保証したい。

納品後も、一台一台の機番から、出荷先および、ノズルに割り当てたジュースの種類やオプションの情報を管理しなければならない。

出荷と一口に言っても、設置工事を行う場合もあり、機械を発送するだけの場合もある。 出荷先でオプションを
追加・変更する改造工事もありえる。移設・撤去工事もある。それらの工事イベントについても管理しなければならない。

1出荷先に複数機種を複数台納品する場合もあれば、移設などにより履歴として納品先が複数になる場合もある。

以上のような条件があったとします。


241 :NAME IS NULL:05/03/01 17:09:58 ID:???
(1)
機種の仕様マスタとしては、

┌ +[機種基本仕様] (スーパータイプ)

├・+[機種A特有仕様](サブタイプ)

├・+[機種B特有仕様](サブタイプ)

└・+[機種C特有仕様](サブタイプ)

のように持つのが正しいのでしょうか?
正しいとして、マスタはそれでいいとして、
出荷する一台一台の情報は、このマスタを利用してどう保存すればいいのでしょうか?

(2)
出荷先と工事と機番との関係は、

 [機材]
  +
  └─≡[工事]
  ┌─≡
  +
 [出荷先]

のようになるのでしょうか?


この辺で長いこと悩んでいます。
上に紹介のあった本にも、
似たケースのモデル例は見つかりませんでした。
何かしらアドバイスいただけると助かります。

242 :NAME IS NULL:05/03/02 00:08:35 ID:???
>>240

機種−機種ID、最大ノズル数、オプションタイプ可/不可
ノズル−機種ID、ノズルID、タイプ(ジュース/水)、ボトルタイプ(タンク/ボトル)、タンクタイプ(1.8、4、10)・・・
ジュース−ジュースID、ボトルタイプ(タンク/ボトル)、タンクタイプ(1.8、4、10)・・・

設置した機器−機番、機種ID、出荷先・・・
設置したノズル−機番、ノズル番号、ノズルID、ジュースID・・・

出荷するジュース−出荷日、出荷先、機番、ノズル番号、ジュースID・・・


こんな感じ?

243 :NAME IS NULL:05/03/02 18:18:10 ID:???
>>242
レスありがとうございます。

なるほど。

>設置した機器−機番、機種ID、出荷先・・・
>設置したノズル−機番、ノズル番号、ノズルID、ジュースID・・・
たしかにこれで機番ごとのデータが持てますね。

設置した機器−機番、機種ID、出荷先ID、出荷日時、・・・
           ̄ ̄
ノズルIDが固有機種の固有位置についているノズルを特定し、
ノズル番号は明細のために振った番号だとすると、

設置したノズル−機番、ノズル番号、設定日時、(機種ID)、ノズルID、ジュースID、容器ID、・・・
            ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
           01001 001     04/9/1  LP-100  ノズル01  ジュースX2  タンク01
           01001 002     04/9/1  LP-100  ノズル02  ジュースX3  タンク02
           01001 003     05/3/1  LP-100  ノズル02  ジュースY2  ボトル05

そうすると、オプションは

設置オプション−機番、オプション番号、設定日時、オプションID、・・・
            ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
ノズル数やその他の制限は、判断材料となるデータを保存しておくまでにとどめ、
実際の判断はデータベースの制約ではなくアプリケーションが都度判断する、
というのが正解になるんでしょうか…。

また、項目が、ノズル・オプションなど限られていれば良いのですが、
他にも例えば、左正面パネルの色・本体高さ・右サブテーブルの幅・左サイドレバーの位置・中央受皿の種類…など、
機種によって管理する項目が全然バラバラのとき、
新機種がでるたびアプリケーション側で機種固有に判断するルーチンを都度追加など、
アプリケーション側の負担が際限なく大きくなりメンテ困難にならないか不安です。

履歴として出荷先が複数になる点もサポートするためには、
過去の出荷先(現在は移設等で機材が無い)の履歴データは
アプリ側で別テーブルに持つのが良いのか、
あるいは設置した機器と出荷先を多対多にするべきなのか…
アプリ側で判断してしまえばどちらでも可能そうなので余計悩んでしまいます。



244 :NAME IS NULL:05/03/02 19:55:10 ID:???
こんなんは?細かくしすぎかもしれんが。。
実際のオプション内容は別テーブルにして、機種との対応表を別表に作る
(パフォーマンス度外視)。
ものによっては >>242のとおり機種の属性に持った方が適切。
この辺りの判断は要件とかも絡んでくるし、一概には言えないと思う。

> 他にも例えば、左正面パネルの色・本体高さ・右サブテーブルの幅・
> 左サイドレバーの位置・中央受皿の種類…など、機種によって管理する項目が
> 全然バラバラのとき、
本当にバラバラなら機種テーブルそのものを分割する。
親子関係を持たせるとかは自由。

履歴は開始、終了時間で管理(一応、受付時間も)。設置場所だけが変わったら
終了時間が設定されて、開始時間、出荷先が変更された行が追加される、てな具合。

[マスタ]
機種 - 機種ID、(全機種共通情報)
ノズル機能 - ノズル機能ID、ノズル機能(ジュース、水)、タンクID
タンク - タンクID、タンク容量
オプション - オプションID、オプション内容
機種ノズル - 機種ID、ノズル番号、ノズル機能ID
機種オプション - 機種名、オプションID
ジュース - ジュースID、(ジュースの情報)
ジュースタンク - ジュースID、タンクID
出荷先 - 出荷先ID、(出荷先の情報)

[履歴]
設置機種 - 機番、機種名、出荷先ID、受付時間、
設定開始時間、設定終了時間、設定状態(自社設定、客先設置、設置済み etc)
設置ノズル - 機番、ノズル番号、ジュースID
設置オプション - 機番、オプションID

※出荷数量は設置機種により導出可
※2つまでの重複可とかははアプリで。

長文スマソ

245 :NAME IS NULL:05/03/03 01:27:26 ID:8HW4Dnff
年月日は、date型使いますが、年月ってどうしてますか?
char(6) にしますか?それとも date型で、必ず1日とかにします?




246 :NAME IS NULL:05/03/03 01:46:48 ID:1vRnt2on
高橋友城 は 殺された

247 :NAME IS NULL:05/03/03 18:17:51 ID:???
>>245
俺はdate方にする。(月初又は月末しか入らないように制約をつけて)
後に必要な項目が年月が年月日に拡張されてもいいようにね。
まぁ、余計なもの(日)がはいるしChar型に比べてDate型のほうが
サイズが大きいデータベースがほとんどなんで、その辺りがきになるのであれば
Char型もいいんじゃない?
まぁ、結局はおこのみで

248 :NAME IS NULL:05/03/03 21:41:11 ID:???
>244
ありがとうございます。
頂いたアドバイスを元にただいま苦悩中。
何か形になったら報告に参ります〜

249 :NAME IS NULL:05/03/03 22:21:33 ID:???
んー…
機種の仕様により選択不可能なオプションを設定しようとすると、
リレーションシップの制約によりエラーがでて設定できないような成果を期待していましたが、
いわゆるビジネスロジック層ですべき判定をデータベース層にやらせようとしている、
というような気がしてきました…
データベース層は、あくまでビジネスロジック層での判定根拠となる設定情報を保持するだけ、
が正解なのかな…
せっかく機種の仕様制限をマスターのリレーションシップで表現しても、
今のままでは履歴テーブルで機種仕様制限に反する設定値を入力できてしまう…

250 :NAME IS NULL:05/03/04 13:05:47 ID:???
>>241
> 上に紹介のあった本にも、
> 似たケースのモデル例は見つかりませんでした。

なんだかデジャヴを感じるモデルだったので家に帰ってから調べてみたけど
「業務別データベース設計のためのデータモデリング」の"フィーチャオプション"
あたりをじっくり読んでみると幸せになれるかもしれない。

251 :NAME IS NULL:05/03/04 14:54:04 ID:???
>>250
ありがとうございます。

フィーチャーオプション、
オーダーメイド的な面のあるものに、
どうもしっくり来ない感があるんです。
フィーチャーCが繰り返し項目っぽくなってしまうし、
オプションの付き方に構造がある場合にその構造が表現しにくい…

ためしにちょっと書いてみました。

機種フィーチャコード  フィーチャ明細               フィーチャ別オプション明細
           フィーチャ行No. 桁数 フィーチャ名    オプションC  オプション名
-----------------------------------------------------------------------
LP-100      1         2   ノズル1液種 X1    ジュースX1
.                                 X5    ジュースX5
                                 ・     ・
                                 ・     ・
                                 ・     ・
.                                 Y8    ジュースY8
           2         3   ノズル1容器 .T04    .タンク4g
                                 .T10    .タンク10g
           ・                     ・     ・
           ・                     ・     ・
           ・                     ・     ・
.           8         2   ノズル4液種  X1    ジュースX1
                                 .X5    ジュースX5
                                 ・     ・
                                 ・     ・
                                 ・     ・
                                 .Y8    ジュースY8
           9         3   ノズル4容器  .T04    タンク4g
                                . T10    タンク10g
           10       . 3  オプションA    OPT1   .オプション1
                                 .OPT2   オプション2
                                 .OPT3   オプション3
           11        .3  オプションB    OPT1   .オプション1
                                 .OPT2   オプション2
                                 .OPT3   オプション3
           12        .2  左正面パネル色 BL    .青
                                . BK    黒
                                . RD    赤
           ・                     ・     ・
           ・                     ・     ・
           ・                     ・     ・
           18        .4  中央受皿種類 SUS0  .ステンレス
                                .PLBK   プラスチック黒
                                .PLWH  .プラスチック白
                                .NA00   なし

機種基本属性
機種C    機種名 ・・・ 機種フィーチャC
----------------------------------------
LP-100    LP-100     LP-100


派生機種明細
機種C    フィーチャオプションC
-----------------------------------------------------------
LP-100    X1T04X5T04X6T10Y8T10OPT2OPT3BKXXYYZZQQQGGSUS0

252 :NAME IS NULL:05/03/04 15:38:54 ID:???
上で、引用元と違ってフィーチャ体系という体系をとらなかったのは、
今回のケースでは、
複数の機種が全く同じフィーチャー体系をとることはまれであるためです。

上のモデルでは、
派生機種明細にマスタとして設定可能な全ての組み合わせを
予め持っておくみたいなのですが、
ノズルに割り当て可能なジュースを見ると、
ジュースの種類が非常に多く、新商品と販売終了の移り変わりが激しいなどの場合、
組み合わせ数がいたずらに多くなった上、マスタメンテの手間も大変そうです。

ところで、
オプションで例えば、キャスターっていうのを考えてみますと、
(アジャスター:高さ調整可能な機械の足
 キャスター :小さな車がついて移動可能な機械の足)
機種側の制約としては、
キャスターには耐荷重があるので、
機種の基本属性に稼動時最大重量というのを持って、
これで適用可能かどうか判断しなくてはいけません。
また、重量をクリアしても、
標準でついているアジャスターの取付方式と互換性のあるキャスターしか使えません。
機械の性質上、絶対揺らしてはいけないものは、
ロック時にアジャスターが降りてくるアジャスター一体型のキャスターしか
使えないかもしれません。
本体が縦長な場合、キャスターによる移動が不安定で極めて倒れやすいので不可、
という場合もあります。
単価が安くて手間をかけたくない機種などで、
営業上の判断でオプションを適用不可にしたい場合もあります。
こういった類の制限を表現するためにはもう、
オプションのマスターで制限を文章表記した上、
適用可能かどうかを判定する、機種×オプションの表に、
予めTrue/Falseで持っておいて、
その根拠として、
その判断を下した責任者、判断日、有効期限、判断理由、特記事項などを
持たないといけない気がします。

253 :NAME IS NULL:05/03/04 15:47:29 ID:???
キャスターの例で書き忘れましたが、
機械の使用環境がわの制限もありました。
勾配が何度以上だと使用不可とか、
大理石の床に硬いキャスターは不可とか、
あるキャスターの高さ調整範囲だと機械の高さがオーダーどおりに設定できないなど…
こちらも管理しないと、
たとえば機種Aを現場Aに設置した後、
現場Aでは不要になったので現場Bに移設するようオーナーからオーダーがあった場合に、
移設可能かどうか判断が出来なくなります。
従来だと、
・下見にコストがかかる。
 下見に行っても制約条件を網羅しきれず無駄になる場合もある。
・とりあえず移設しようとしたが出来なかったので、
 納期に間に合わない上に後出しで追加料金発生もやむなし。
だとおもいます。

254 :NAME IS NULL:05/03/04 19:24:44 ID:???
難しい・・・。
やはり、最終段のこれかなぁ
ttp://www.jsys-products.com/iwaken/data_model_patterns/lower.html#13

モノ(クラス)→機種、アジャスタ、ジュース、ボトル、ノズル
モノ(インスタンス)→機種A、高さ調節式アジャスタ、オレンジジュース
関係
 機種A−ノズルA(可能)
 機種A−ノズルB(ダメ)
 ノズルA−ボトルXX
 ノズルA−ボトルYY
 機種A−高さ調節式アジャスタ(ダメ、高さが合わないから)
関係タイプ
 取り付ノズル
 接続アジャスタ
属性
 サイズ
 容量
 高さ
属性割り当て
 ボトル−容量
 ボトル−サイズ
変数
 4g
 10g

なかんじ。


255 :NAME IS NULL:05/03/04 19:41:13 ID:???
>>254
うわ、改めてみるとすごいモデルですね、これ…
週末使って考えてみます。 ありがとうございます。

256 : :05/03/04 23:18:03 ID:???
>>255

 DOA+コンソーシアムってところでメーリングリストがスタート
したみたいです。
ttp://www.doaplus.com/html/topics_20050303.html

 本当に悩んでるならそこで聞いてみてはどうでしょう?
DOAの錚々たるメンバが参加されているようです。

257 :NAME IS NULL:05/03/13 14:37:10 ID:???
>>256
とりあえず入会してみましたがメーリングリスト届きません…

(´・ω・`)

(´・ω:;.:...

(´:;....::;.:. :::;.. .....

258 :NAME IS NULL:05/03/15 02:51:06 ID:???
>>257
来ましたがな

259 :NAME IS NULL:05/03/18 09:42:19 ID:???
有名本の著者らしき方や、その筋の本職の方などが発言してますね…

260 :NAME IS NULL:05/03/19 22:52:31 ID:pW3Ejy8n
>>259

 えっそうなの! 無料だから入ってみるか

261 :NAME IS NULL:05/03/20 00:10:27 ID:???
「オブジェクト指向の幻想について」で盛り上がってます。


262 :NAME IS NULL:2005/04/12(火) 15:08:28 ID:c/VE92X6
現在使用しているデータモデルの表記法の投票

http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=13241&forum=26&showpollresult=1&showpollresult=1

263 :NAME IS NULL:2005/04/16(土) 17:28:01 ID:SaaWDc/a
今投票サイトを作っているのですが、データモデリングで迷っています。
DBには各ユーザー名と回答を格納します。
回答の値はintの0〜10ぐらい(選択肢の数だけ)と予想され、
設問の数はどんどん増えていくことが予想されます。

今下記のような二つの方法を考えています。

A)設問ごとにフィールドを作る。
回答1 回答2 回答3 ・・・
0   1   5   ・・・

B)回答用フィールドは一つにし、カンマ区切りなどで格納する。
回答
0,1,5,,,,

Aは設問が増えるたびにフィールドを追加しなければならないし、
Bは集計のたびに分割して値を抜き出す作業が必要。

どちらが良いでしょうか?

264 :NAME IS NULL:2005/04/16(土) 18:41:34 ID:???
何で各回答ごとにレコードを持つという発想にならない?

265 :NAME IS NULL:2005/04/16(土) 20:21:25 ID:??? ?#
>>263
ユーザID、設問ID、回答 をフィールドに持つテーブルを作ればいい。



266 :NAME IS NULL:2005/04/16(土) 21:46:23 ID:SaaWDc/a
あーわかった!
264さん265さんありがとう。

ちなみにメールアドレスをユーザーIDにしようと考えているのですが、
それを主キーにして良いでしょうか?
それともオートインクリメントで主キー用のフィールドを
別に作ったほうが良いでしょうか?

267 :NAME IS NULL:2005/04/17(日) 00:33:06 ID:???
kaba@prolog.com,設問1,2
kaba@prolog.com,設問2,1
kaba@prolog.com,設問3,1

とかなりますが、kaba@prolog.comのユーザーIDを主キーにするので
よいとお考えですか。

268 :NAME IS NULL:2005/04/17(日) 01:09:06 ID:R6dX5cU6
いや、ユーザー情報テーブルとは別に投票結果テーブルを作りますので、
主キーは前者だけに設定するつもりです。

こんな感じ

ユーザー情報テーブル
ID(主キー)メルアド パスワード他
001 a@a.a pass1
002 b@b.b pass2

投票結果テーブル
ID 設問ID 回答NO
001 01 9
001 02 5
002 01 1
002 02 4

それで知りたいのは主キーを簡単な数字にした場合とメルアドのような
複雑な文字列にした場合とで検索速度に違いが出るかということです。

269 :263:2005/04/19(火) 11:14:49 ID:4C71pzmp
みなさん、ありがとうございました。
おかげで投票サイトが完成しました。
http://www.kiminari.info/kokumin/

なお、不具合報告等のスレッドを作りましたので、
ご協力いただける方は、よろしくお願いします。
http://pc8.2ch.net/test/read.cgi/php/1113871597/

270 :NAME IS NULL:2005/04/19(火) 11:57:10 ID:8GDQE5S+
>268
検索速度については単表検索なら、簡単なコードのほうがいいと思います。
ただ、この設計だと投票結果テーブル検索時はユーザ情報テーブルをJOINするオーバヘッドが発生しますよね。
インデックス容量を考えると、コード有利です。
メールアドレスが変更される可能性があり、かつ変更後も同一人物として扱う必要があるならコード化です。
なければ、メールアドレスがキーのほうがアプリ工数は少ないかもしれません。(JOINの必要なし)
業務特性、システム特性を考えてトレードオフで考え、最良の設計を。



271 :NAME IS NULL:2005/04/19(火) 19:34:30 ID:???
>>270
> メールアドレスが変更される可能性があり、かつ変更後も同一人物として扱う必要があるならコード化です。
実は私もこの問題で>>268を見てモヤモヤしていました。ユーザー情報テーブルですが、
001 a@a.a pass1
001 a_new@a.a pass1_new
002 b@b.b pass2
となり、ID(主キー)を維持できなくなると思うのですが。

272 :271:2005/04/19(火) 20:00:55 ID:???
うーん。投票されて、その時点での実際上のIDはメールアドレスですよね。
投票者はID { 001,002...}は知らない。
それで、既に投票されているかチェックに行く。そのための主キー。
とするとメールアドレス以外に主キーは考えられない。

273 :NAME IS NULL:2005/04/19(火) 21:17:19 ID:???
ER図から3NFまで自動変換するソフトウェアを探しています

274 :NAME IS NULL:2005/04/20(水) 02:54:10 ID:eImDdv+2
>270
いえいえ、違いますよ。
001は絶対に1レコードのままです。
変更情報は、
@「メールアドレス変更履歴エンティティ」を抽出する
A「変更前メールアドレス」項目を追加する
あたりで表現します。
純粋なデータモデルとしては@が正解とされますが
業務要件が「直近1世代の変更前アドレスだけの保持でよい」などであれば
Aも現実的です。



275 :NAME IS NULL:2005/04/20(水) 06:50:59 ID:???
メールアドレスを外部キーにもつ列全部に UPDATE CASCADE をつけれ

276 :NAME IS NULL:2005/04/20(水) 06:53:21 ID:???
メールアドレスを外部キーにもつ列全部に UPDATE CASCADE をつけれ。

277 :NAME IS NULL:2005/04/20(水) 08:24:29 ID:???
>>273 @が正解ですね。無理に>>268の枠組の中で解を求めたのが
いけなかった。

278 :NAME IS NULL:2005/05/25(水) 01:18:49 ID:???
個人や組織や会社もろもろに
「パーティ」ってスーパーセット設けるのって実際どうなんでしょう。
よくやるのでしょうか?

279 :NAME IS NULL:2005/05/28(土) 23:14:32 ID:rxg+K8Bf
コードに意味(何桁目が年式をあらわすなど)を持たせないで
全くの連番だと、コードを見ただけでは全然類推ができないし
使いにくいと思うのですが、コードに意味を持たせないメリットは何。
コードに意味を持たせても、切り出して判断に使わなければOK?
連番は採番しやすくていいのだけれど。両方満足させる方法があれば。




280 :NAME IS NULL:2005/05/29(日) 09:41:43 ID:???
ただの連番ならDBMSが勝手に作ってくれるからラクじゃん。

281 :NAME IS NULL:2005/06/01(水) 01:20:28 ID:???
>>279
伝票番号だって、車のナンバーだって、出席番号だって、電話番号だって、意味を持たないだろ。
(言葉遊びの語呂合わせなどは別として)

単に個別を識別するためのものだ。
世の中の仕組みがそうなっていることに気が付けよ。

282 :NAME IS NULL:2005/06/01(水) 11:04:24 ID:???
>>281
電話番号は意味あるよ。
地域コード - 連番
じゃん。
伝票番号も会社によって
YYYYMMDDXXXXX
とか当たり前にある。

283 :NAME IS NULL:2005/06/01(水) 16:46:09 ID:???
>>282は世の中の仕組みがわかってない

284 :NAME IS NULL:2005/06/01(水) 18:37:20 ID:???
シデー世ですこと

285 :NAME IS NULL:2005/06/01(水) 19:01:57 ID:???
>>281
出席番号は連番だが名前の読みの50音順に並んでたりするから
そんな場合は意味を持っている、名前の読みについて少しは類推ができる、と
言えると思うがどうか。類推する側が50音順って決まりをわかってないといけないが。
転入生があると転入生は連番の最後で我慢してねとか、誰か転校しちゃうと欠番とかはあるんだろうが。

出席番号をつけるのにくじ引きで名前を引いてその順番に連番をつけるような
場合は、意味を持っていない、といえるかも。
連番であっても意味がある場合とない場合があるということではないのか。


286 :NAME IS NULL:2005/06/03(金) 12:15:18 ID:???
性別コードは0が女で1が男だよな!

287 :NAME IS NULL:2005/06/03(金) 12:19:30 ID:???
象形文字ですか?

288 :NAME IS NULL:2005/06/03(金) 16:02:04 ID:???
性器化

289 :NAME IS NULL:2005/06/03(金) 16:04:13 ID:???
自己記述的なコードとゆーやつかしら

290 :NAME IS NULL:2005/06/03(金) 19:24:36 ID:???
>>278
>「パーティ」ってスーパーセット設けるのって実際どうなんでしょう。

OOのやり方。DOAでは積極的にはやらない(と思う)。

291 :NAME IS NULL:2005/06/05(日) 12:42:42 ID:???
>>285
それは、出席番号順というのではなくて、50音順という、別の意味だろ。
出席番号順のデータを作成する際に、イニシャルデータを作る手順として、
たまたま50音順にデータを投入したと言うだけだ。
だから転校生は、一番後ろになるわけで。
入学受付順、背の順、という学校もあるし、それはたまたま50音の学校が多いと言うだけ。

292 :NAME IS NULL:2005/06/06(月) 10:19:45 ID:???
>>291
そういや転校生って、後ろにpushだったなあ・・・。
なんか懐かしくて胸キュンだ。

293 :NAME IS NULL:2005/06/06(月) 14:46:53 ID:???
>>292
俺の学校では違ったなぁ・・・

小・中学校では出席番号は生年月日の早い順。
高校での出席番号は五十音順だった。

ただ、転校生やらが入ってきた場合はその都度、出席番号が変わっていた。
つまり、再度、生年月日やら五十音で並べ替えられる。

294 :NAME IS NULL:2005/06/06(月) 15:07:48 ID:???
>>293
健康カードとか、下駄箱とか、出席番号を記入して1年間使う物があるのに、
えらく不便なシステムだな。

295 :NAME IS NULL:2005/06/06(月) 15:07:54 ID:???
えー!都度再ソートもびっくりだが、生年月日順ってのは凄いなー。

やばい、このまま果てしなく脱線しそうだ。

296 :NAME IS NULL:2005/06/06(月) 15:13:06 ID:???
つまりだ、実際の業務では
>293のような事態がままあるので
識別子と業務上使われる出席番号などは
別に構えるのが吉って事ですね。

健康カードテーブルと下駄箱テーブルも
これで迅速な対応が出来ると。

ただお客さんとのモデリングセッションなどで
作っていく概念レベルではIDじゃなくて
出席番号を識別子とした方がいいでしょうね。
お客さんにシステム要件はなるたけ考えさせたくないし。
実装時に生徒IDでもなんでもシーケンスでふっちゃえばいい。

297 :296:2005/06/06(月) 15:24:04 ID:???
とか書いてたら、そもそも発端の
ちゃんと>279へのレスになったな。

IDは、意味の無い連番。
出席番号は、業務ルール(五十音順など)の意味がある番号。
とすると。

出席番号は出席簿や健康カードといった
プレゼンテーション部で、ユーザーの認識容易性が得られる。
ただ変更の可能性がある場合に大変。

IDは意味が無い分、業務ルール変更に関係なく
行の識別子として機能する事が出来る。

出席番号はプレゼンテーションの要件なんだから必要だが
識別子としては不安なので、それはIDを採用。
結局両方持っとけって事ですね。

298 :NAME IS NULL:2005/06/06(月) 21:59:03 ID:???
>>297
ほかのテーブルから外部キーとして参照する場合は
ID?出席番号?


299 :NAME IS NULL:2005/06/06(月) 23:26:34 ID:???
>293は
出席番号は出欠名簿リストの左端についてる番号ぐらいの利用しかなくて、
いつもは学籍番号ばっかり使ってるってことはないのか。


300 :NAME IS NULL:2005/06/06(月) 23:44:49 ID:???
>生年月日順

千葉?

301 :NAME IS NULL:2005/06/06(月) 23:58:33 ID:???
>>298
IDじゃないと、297で言ってるメリットが得られないです。
途中で転校生の分、出席番号振りなおしても
下駄箱テーブルはID参照してれば影響なし。

物理的な下駄箱については、頑張って貰おう。

302 :NAME IS NULL:2005/06/07(火) 01:39:29 ID:???
最初から出席番号を 10, 20, 30 と、10おきにつけておけばいい。
転校生が来たら 25 などを割り振ればいいだけだ。

303 :NAME IS NULL:2005/06/07(火) 04:43:41 ID:???

      \∧_ヘ     / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ,,、,、,,, / \〇ノゝ∩ < 転入合戦、いくぞゴルァ!! 
    /三√ ´∀`) /  \____________  ,,、,、,,,
     /三/| ゚U゚|\      ,,、,、,,,                       ,,、,、,,,
 ,,、,、,,, U (:::::::::::)  ,,、,、,,,\ワショーイ!!/ \ワショーイ!!/  \ワッショーイ!!/
      //三/|三|\     /■\/■\ /■\ /■\  /■\ /■\
      ∪  ∪       ( ´∀` )´∀` )´∀` ) ´∀`  ( ´∀` ) ´∀` )
 ,,、,、,,,       ,,、,、,,,  /■\/■\ /■\ /■\  /■\ /■\
      ,,、,、,,,       ( ´∀` )´∀` )´∀` ) ´∀`  ( ´∀` ) ´∀` )
             (( (つ  ノ(つ 丿(つ  つ(つ  ノ(つ  丿(つ  つ
                ヽ  ( ノ( ヽノ ) ) ) ヽ  ( ノ ( ヽノ   ) ) )
               (_)し' し(_) (_)_)(_)し' し(_)   (_)_)


304 :NAME IS NULL:2005/06/07(火) 08:55:18 ID:???
昔のBASICの行番号かいw

305 :NAME IS NULL:2005/06/07(火) 10:35:19 ID:???
なつかしいね!
と思ったけど、表示順みたいなカラムでは
今もやってるなー。

306 :NAME IS NULL:2005/06/07(火) 18:27:35 ID:???
>>303
来るのは9人までにしてね

307 :NAME IS NULL:2005/06/07(火) 21:28:29 ID:???
年度中に学区内に団地できたら終わりだな。

308 :NAME IS NULL:2005/06/07(火) 22:07:15 ID:???
総数より同じ隙間に集中した時がまずいのでは…

       / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
       | 転校生の織田です
       \
          ̄∨ ̄ ̄ ̄ ̄ ̄ ̄
                   ∧_∧      / ̄ ̄ ̄ ̄ ̄ ̄ ̄
         ∧_∧     ( ´Д` )    <   小田です
         ( ´Д` )   /⌒    ⌒ヽ    \_______
        /,  /   /_/|     へ \
       (ぃ9  |  (ぃ9 ./    /   \ \.∧_∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄
        /    /、    /    ./     ヽ ( ´Д` )<  尾田です
       /   ∧_二つ (    /      ∪ ,  /   \_______
       /   /      \ .\\     (ぃ9  |
      /    \       \ .\\    /    /  ,、    ((( )))  / ̄ ̄ ̄ ̄ ̄ ̄ ̄
     /  /~\ \        >  ) )  ./   ∧_二∃    ( ´Д` ) < 緒多です
     /  /   >  )      / //   ./     ̄ ̄ ヽ    (ぃ9  )  \_______
   / ノ    / /      / / /  ._/  /~ ̄ ̄/ /   /    ∧つ
  / /   .  / ./.      / / / )⌒ _ ノ     / ./    /    \   (゚д゚)オダデス
  / ./     ( ヽ、     ( ヽ ヽ | /       ( ヽ、   / /⌒>  )  ゚(  )−
(  _)      \__つ    \__つ).し          \__つ (_)  \_つ   / >

309 :NAME IS NULL:2005/06/07(火) 22:16:05 ID:???
意味なし連番IDと認識容易番号の2本立てでいくのがベストと考えて
いいでしょうか。この方法の問題点注意点が何かあれば。

確かに意味なし連番IDを後から変更しようとは思わない。
認識容易番号では何桁目が何を表すかという意味自体が古くなったりする。
電話番号も市町村合併で市町村の枠が違ってしまえば
番号の体系と合わなくなってしまう。
新しい市町村の体系に合わせて電話番号を直して
すっきりしたいと思ってしまうようなものなのだろう。



310 :NAME IS NULL:2005/06/08(水) 07:34:54 ID:???
>>309
随分前のWEB+DBプレスのデータモデリングの記事に
にそこらへんの事がかいてあった。
今なら全部のバックナンバーのPDFが売ってるから
読んでみるといいよ。面白かった。

意味無し連番こそ、データの識別子であって、
業務上使うコードは、ユーザーさんが使う際の便利な
アクセスパスにすぎないので、ごっちゃにしちゃ
いかんですうんぬんてな事が書いてありました。


311 :NAME IS NULL:2005/06/08(水) 07:51:15 ID:???
>>308
べつに?

312 :NAME IS NULL:2005/06/08(水) 10:15:30 ID:???
310の続き

じゃあOracleのRowIDやPostgreのOIDを
使えばいいじゃんって話しになりそうですが
そうすると、ひょんな事からエクスポート・インポートなど
する事になったりすると変わっちゃうのでだめですねー
てな事も書いてあった。

313 :NAME IS NULL:2005/06/08(水) 11:35:13 ID:???
>>310
WEB+DB PRESS特別総集編ってやつですね。
読んでみます。


314 :NAME IS NULL:2005/06/08(水) 22:43:34 ID:???
>>302

出席番号はどうせ生徒を特定する識別キーにはならないのだから、
再割り振り・ケツに追加のどちらでも良い。

>>310

学籍番号で言えば、全く意味のない連番より、入学年度+連番のほうが見やすい。
見やすいだけで、意味なし連番と違わないのだが、
違いがないのなら見やすい方が良い。



315 :NAME IS NULL:2005/06/09(木) 00:38:03 ID:???
>>314
勿論、学籍番号は見やすいほうがいいでしょう。
ただ、学籍番号ってのは業務で用いるコード、
特定のデータへのアクセスパスな訳です。

便利なアクセスパスってだけなので、
業務要件の変化によってどうなるもんか判らんので
データをアイデンティファイする識別子とは別にした方がよい、
と言うのが主旨。
意味無し連番ってのが、その識別子にあたります。

316 :NAME IS NULL:2005/06/12(日) 11:13:50 ID:???
WEB+DB PRESS特別総集編みました。
関係箇所がVol.11とVol.21に出てました。
どちらも著者は羽生彰洋さん。

少し説明すると、この中では、
意味無し連番->アイデンティファイア=ID=識別子=FKで使用JOIN用
認識容易番号->ビジネス上のコード体系=アクセスパス
としており、一見さんに対する顧客コードのつけ方や、
商品開発で開発の最初でコードが決まりにくい場合の例などで、
意味無し連番と認識容易番号を分けて考えて両方採用する
ことが大事である、と。詳しくは本文を。T字形の影響も
形を変えて入っているように感じました。
(ただ、Vol.11では主キーという言葉を認識容易番号の意味で使っていて、
使い方が間違ってないかな。Vol.21では直ってると思う。)

結構詳しく説明されてます。これに反論するのは難しいか。
意味無し連番の今までの違和感が少しはなくなりました。

317 :NAME IS NULL:2005/06/12(日) 23:52:13 ID:???
>>316
俺も意味無しID、使ってはいたし
コードの洗替が楽ってのも判ってたけど
どうしても違和感があって、
それ読んで、識別子とアクセスパスって言い方で
すっきりしました。

はぶさん、この路線で本書くのかなと思ったけど
SQLドリルってのは、やられた。

318 :NAME IS NULL:2005/08/11(木) 09:34:00 ID:u6wEnJIp
age

319 :NAME IS NULL:2005/08/16(火) 11:18:49 ID:wzipZbWi
>>316
このスレみてWEB+DB PRESS特別総集編買ってきてました。
なるほどなぁ〜と読みすすめてたのですが、一つ疑問が。

商品に対する品種。
商品に対する単位。

いままでこれらは商品マスタに品種や単位のコードを参照するように
カラムを追加していました。
しかし、Vol21p112にあるように各関係に対して交差エンティティを作成するほうが
後のためによいのでしょうか?

ちなみに作るとしたら以下のような交差エンティティを作成するのかな?
品種構造 構造ID,品種ID,商品ID 現在は1:m
単位構造 構造ID,単位ID,商品ID 現在は1:m

320 :NAME IS NULL:2005/08/16(火) 13:19:07 ID:???
>>319
ここで聞いてみよう
http://d.hatena.ne.jp/habuakihiro/

でもまあ、システムの規模や顧客の業務内容などなどで
最適解は色々ってのが答えなんじゃないかな。
正論かつ優等生ちゃんな答えでつまんないけどさ。

321 :NAME IS NULL:2005/08/17(水) 05:35:09 ID:???
>>320
サイト紹介してくれてありがとう。

みてみると交差エンティティはm:mの時、定義するように書いてありますね。
WEB+DB PRESS特別総集編によると、1:mでもとりあえず定義しとけとあったので
ちょっと疑問に思っていました。

私が担当するプロジェクトはそこまで大規模なものでもないので
今回は交差エンティティを定義しない方向で進めて行きたいと思います。

322 :NAME IS NULL:2005/08/17(水) 10:39:17 ID:???
>>321
いえいえどういたしまして。
なんか偶然だけど、凄いタイミングよかったね。

規模もそうだけど、
1:mって関連がどれだけ確かなものかってのを
お客さんにしっかり聞いておくのが一番だと思います。

業界でしっかりと規格化されてるものだったり
物理的にそれい以外考えられないとかだったら
カラムにしちゃった方がいいだろうし
「今までそうだったから」とかだと変わる可能性あるから
関連エンティティにした方が良いかも知れない。

323 :NAME IS NULL:2005/08/20(土) 22:14:02 ID:UVFT2kPn
スレ違いかもしれないけど、相互参照(交差エンティティ)のテーブルって
日本語が使えない時はどんな名前にしてますか?
〜マスタだと「〜MST」
〜のログだと「〜TRN」
〜と〜の相互参照だと「〜???」
私と似た様な命名規則を適用されている方、どうかお知恵をお貸し下さい。

324 :NAME IS NULL:2005/08/22(月) 09:41:01 ID:???
自分ルールなんだから、自分で決めろよそれぐらい。
そもそもサフックスにするところから議論になるぞ。

まず、プレでも何でもつけるか否か、つける場合の分類、そして略称。
そこの末端だけのことなんだから、開発者は小脇に辞書を抱えて即引きするのが常識。
命名で悩んでる時間がもったいない。

325 :NAME IS NULL:2005/08/22(月) 13:32:34 ID:???
>>324
議論ではなく、同様ので命名規則を適用している方で
サフィックスだけでもどうやってるのかと意見をもらいたくて・・・。
何にせよ、スレ汚しごめ。

326 :NAME IS NULL:2005/08/22(月) 23:01:53 ID:???
Crsってサフィックスを見た事があるよ。
設計・命名者はメインフレーム出身の割と古い人。

327 :NAME IS NULL:2005/08/23(火) 00:11:07 ID:???
>>326
貴重な情報、ありがとうございます。
早速、関係するテーブル名を連結+CRSで命名したいと思います。

328 :NAME IS NULL:2005/08/23(火) 08:35:13 ID:???
でも英語としてあってるかどうか知らんよ。
あとで保守する人にだせーとか言われるかもよ。

329 :NAME IS NULL:2005/08/25(木) 01:16:39 ID:???
データウェアハウスの論理設計に関していい書籍やネット上の情報があったら教えてください。


330 :U ◆CZtFsGiu0c :2005/08/25(木) 13:43:32 ID:???
>>323
相互参照の略ならXREFなんてどうだろう。

331 :NAME IS NULL:2005/08/26(金) 09:50:12 ID:???
>>330
あんた、センス良いね。

332 :NAME IS NULL:2005/08/27(土) 00:08:36 ID:???
>>330
m:m確定ならそれいいね!
1:m, m:1かm:mのどちらかわからないときは"REF"だけでもよさそうだね。

333 :NAME IS NULL:2005/08/28(日) 15:30:31 ID:???
>>329
DWHは書籍とかネットとかの情報は少ないよ。

というかね、そもそもモデリングとか正規化とか無縁の世界。
どういう切り口でデータを分析するかが目的だから、
正規化とかを ”しない” のが普通。
どうすれば必要なデータをだせるのかを最優先に考え、
その為ならば、データベースの構造がどうであってもOK。

だから、通常は業務でデータを蓄積してる、ちゃんとモデリングや正規化されたDBとは別に
DWH用のDBを別に構築して、そこへ必要なデータを夜間バッチとかで流し込む。

334 :NAME IS NULL:2005/08/29(月) 17:39:42 ID:???
>>329
M$のSQL鯖に付いてる。
使ってみると分かるとおもうし、
MSDNにも資料落ちてるんじゃないかな。

要は、どんな分析をしたいのかをある程度
見極めとくことだと思う。

335 :NAME IS NULL:2005/09/01(木) 22:49:42 ID:3lCOPcx7
アドバイスお願いします。

現在、商品のテーブルに商品区分のフィールドがあります。
商品区分が'1'の時、計算で使用する項目は標準単価のみ(数量x標準単価=金額)。
商品区分が'2'の時、計算で使用する項目は重量、重量当りの単価。(数量x重量x重量当りの単価=金額)
商品区分が'3'の時、計算で使用する項目は縦、横、奥行、サイズ当りの単価。(縦x横x奥行xサイズ当りの単価=金額)
このような時、商品のテーブルには標準単価、重量、重量当りの単価、縦、横、奥行、サイズ当りの単価のフィールドを設けるべきでしょうか?
それとも商品区分毎に各テーブルを設けるべきでしょうか?

このシステムの前担当者は商品テーブルに全てのフィールドを設けているようですが、
ちょっとひっかかるところがあって、質問しました。

以上よろしくおねがいします。

336 :NAME IS NULL:2005/09/02(金) 04:00:25 ID:???
なぜ2に数量があって3には無いんです?

標準単価は例外なく全ての商品に入りません?
商品テーブルに単位(1:個 2:kg 3:cm^3 など)が入ってれば・・・

重量 2kg と 5kg 、あるいはサイズ 1m×2m×0.4m と 0.2mm×0.5m×0.05m とで、
商品名(商品コード)は同じですか?異なるんですか?
重量やサイズは注文ごとに計量加工して出荷するんですか?定重量・定サイズのもので在庫してるんですか?

その辺の業態の違いで変わってくるように思いますが…

337 :NAME IS NULL:2005/09/02(金) 05:25:44 ID:???
>>336
>なぜ2に数量があって3には無いんです?
申し訳ありません。私のミスです。
仰るとおり3は数量x縦x横x奥行xサイズ当りの単価=金額となります。

>標準単価は例外なく全ての商品に入りません?
この点なのですが、各商品区分によって標準単価の少数以下の有効桁数が微妙に違うのです。
例えば1の時は少数以下無し、2の時は少数第二位等・・・。
汎用性を考えFloatやDouble等で定義すれば解決なのですが、
仕様通りの型に何とか当てはめれないかと悩んでおります。

>重量 2kg と 5kg 、あるいはサイズ 1m×2m×0.4m と 0.2mm×0.5m×0.05m とで、
>商品名(商品コード)は同じですか?異なるんですか?
重量に関しては、2kg,5kg等というような複数の重量は無いとのことです。
サイズは複数のタイプがあるようで、そのときは商品コードはそれぞれ違います。

データの有り方としては商品+標準単価又は、
商品+重量+重量あたりの単価(標準単価)又は、
商品+縦+横+奥行+サイズ当りの単価(標準単価)のようになっており、
同じ商品で重量と縦+横+奥行等が含まれることはありません。

>重量やサイズは注文ごとに計量加工して出荷するんですか?
>定重量・定サイズのもので在庫してるんですか?
この当たりは商品毎に違うようで現場の人が
重量で請求するのか計量で請求するのかを決めるようで
単に個数x単価の時もあれば、個数x重量で金額を算出したり、
サイズで算出したりとまちまちのようです。

以上宜しくお願いします。

338 :NAME IS NULL:2005/09/02(金) 08:11:56 ID:???
>>337
数量もCurrencyで問題ないかと思いますが・・・
浮動小数点じゃ誤差が出てしまうのではないかと

339 :NAME IS NULL:2005/09/02(金) 16:12:47 ID:???
>>338
>数量もCurrencyで問題ないかと思いますが・・・
>浮動小数点じゃ誤差が出てしまうのではないかと
商品のテーブルには数量は含めない予定です。
数量はあくまで伝票入力時に入力するものとし、標準では常に1とするからです。

>>335
>このような時、商品のテーブルには標準単価、重量、重量当りの単価、縦、横、奥行、サイズ当りの単価のフィールドを設けるべきでしょうか?
>それとも商品区分毎に各テーブルを設けるべきでしょうか?
この点はどのように考えると良いのでしょうか?
設計1
商品のテーブル
 商品コード
 商品名
 商品区分
 標準単価
 重量
 縦
 横
 奥行

設計2
商品のテーブル
 商品コード(PK)
 商品名
 商品区分
 標準単価
商品単価1テーブル
 商品コード(FK)
 重量
商品単価2テーブル
 商品コード(FK)
 縦
 横
 奥行

う〜ん、どっちのほうがいいんだろ?

340 :NAME IS NULL:2005/09/02(金) 21:53:32 ID:???
だれが数量を商品マスタに入れようと思うかよ
複数の重量にしてもそんなこと聞いてないと思うが

341 :NAME IS NULL:2005/09/03(土) 02:22:57 ID:???
>>337
> 汎用性を考えFloatやDouble等で定義すれば解決
> 重量に関しては、2kg,5kg等というような複数の重量は無いとのことです
>>339
> 商品のテーブルには数量は含めない予定です。
> 数量はあくまで伝票入力時に入力するものとし、標準では常に1とするからです

342 :NAME IS NULL:2005/09/03(土) 02:26:28 ID:???
 重量
 縦
 横
 奥行

って数量ですよ?
お客さんから寸法や重量を指定されるたびに商品を追加するとか?

343 :NAME IS NULL:2005/09/03(土) 02:47:23 ID:???
洗剤10kgタンクを10本
洗剤500gビンを200本
洗剤50kg特大タンクを2個
コレが同じ値段。
じゃあ重量73gと指定して1370本下さいと言ったら
計量してビンに入れて同じ値段で売ってくれる?

アクリル板 500×200×0.2
アクリル板 400×125×0.4
アクリル板 1000×400×0.05
コレも同じ値段。
じゃあ今度は半端な数は言わない。
8000×5×0.5と指定します。
折ったら返品します。

こういう極端な例を出さないと
要求仕様をちゃんと考えてくれないのでしょうか。

344 :NAME IS NULL:2005/09/04(日) 04:09:33 ID:hkkDWCwF
>>335
これはRDBMS(ER図)の限界として、とてもよく出てくる典型的な問題ではないかな?
商品をオブジェクトとして保存できるのであれば、
商品基礎クラスを継承した3つの商品クラスを別途用意してしまえばいい。

でも、RDB使ってるなら当然そんなことは出来ないので、解決策としては
(1)1つの商品テーブルを作って、そこに全部の項目を用意する
(2)3つの商品テーブルを別に作る
のどちらかを採用することになる。

これらはどっちが正しいということは無くて、状況に応じて使い分ける。
テーブルを分けると後で検索にjoinを多用しないといけなくなるので、
(1)のアプローチを採用することのほうが経験的には多い

345 :NAME IS NULL:2005/09/04(日) 18:53:02 ID:???
>>344
自分は商品基礎情報テーブルと個別商品テーブル×3を作ることが多いけど。


346 :NAME IS NULL:2005/09/04(日) 19:13:35 ID:???
>>344
10個くらいが境界かな。
さすがにsubclass tableを100個tableを作る気はしない。

ちなみに(1)は正規化違反なんだっけ?

347 :NAME IS NULL:2005/09/05(月) 08:51:17 ID:???
ORACLE Designer vs ERwin
比較したメリットデメリットをあげてください。
使用するデータベースはOracle 10g


348 :NAME IS NULL:2005/09/05(月) 11:23:23 ID:Kv8Ouo/7
両方使い込んでる奴なんて居ない。

349 :NAME IS NULL:2005/09/05(月) 12:03:55 ID:???
>>344
この問題、そもそもの現実のものを、どのように扱ってるかが主眼だと思う。
その3つの商品群が混在して扱われているのであれば、テーブルは1つ。
部署違いでまったく別の群をたまたま同じように扱っているのであればテーブル3つ。
データベースってのはあくまで現実の記録だから、そこを主眼にすることは大事だと思う。

で、システム上の扱いで1つにまとまってたり3つに割れてたりして困るならば、そこはViewでカバーする。
1つのテーブルをあるコードで3つそれぞれに分けて表示したり、逆に結合したり。

あと、理想論・原則論からいけば、NULLフィールドやダミー値のフィールドを設けるのは良くない。
同一テーブルでどっかのフラグがこれなら、このフィールドは何とか。
なので、本来は3テーブル分割でまとめてみるViewを提供でよいと思う。

350 :NAME IS NULL:2005/09/05(月) 20:57:11 ID:???
>>349
>>346も言ってるが、もし3個でなくて100個だったら?

351 :NAME IS NULL:2005/09/05(月) 21:27:48 ID:???
商品マスタ・部品マスタはあくまで一元化しないとヤバいとおもうが…
縦横高さなんて仕様情報を、基本マスタに、要素ごとに列を与えて載せるべきなのか?

352 :NAME IS NULL:2005/09/05(月) 23:22:00 ID:???
DB設計の場合、パフォーマンス用件がどうしたって重要になってくるからね。
多少汚くても一個のテーブルで収まってくれると嬉しい

353 :NAME IS NULL:2005/09/07(水) 21:00:08 ID:???
上であがってるWEB+DB PRESS特別総集編Vol.11とVol.21では
ハードウエアも進化してるので理想論をもう少し追求してもよいのでは?とありますね。
なので分割したテーブル数が10未満程度なら、テーブルを分割したほうがよいのかもしれません。

354 :NAME IS NULL:2005/09/07(水) 23:24:35 ID:???
分けるといってもサブセットですよね?

355 :NAME IS NULL:2005/09/19(月) 20:50:45 ID:KI/vbbTM
範囲が断続していて、なおかつ重複しないデータは、
どのようにモデリングしたらよいのでしょうか?

例えば、次のような形のデータです。

材質,最小値,最大値
SPC270D,100,200
SPC270D,250,330
SPC270D,360,380

渡辺幸三さんが書かれた
「業務別データベース設計のためのデータモデリング入門」は読みました。
(他の2冊も読みました)

この本の中には、連続して重複しない場合の例は載っていましたが、
連続せず、重複しない例が載っていませんでした・・・。

初心者っぽい質問ですみません。
いきなりオフコンからの移行プロジェクトを
押し付けられてしまいました・・・。

356 :NAME IS NULL:2005/09/20(火) 00:19:17 ID:???
ID,材質,最小値,最大値
プライマリキーはID
Uniqueキーは材質,最小値,最大値でいいんじゃない?
順序が必要なら各材質毎にNo.振って材質,No.にUniqueキーを設定するとか。

>この本の中には、連続して重複しない場合の例は載っていましたが、
>連続せず、重複しない例が載っていませんでした・・・。

この部分がよくわかりません。
データの並びを見ると、連続して重複(材質が)しているようにみえます。

外してたらすまそ。

357 :NAME IS NULL:2005/09/20(火) 02:19:56 ID:???
>>356
お回答ありがとうございます。

俺の言う重複ってのは、例えばこんな感じです。

材質,最小値,最大値
SPC270D,100,200
SPC270D,180,330
SPC270D,300,380

どう言う事が具体的に説明してみます。

板厚ごとに単価が変ります。

材料メーカーさんの都合で、
サイズの範囲が決まっています。

例えば355の例で言いますと、
200-250ってサイズは存在し得ないんです。

俺なりには検討してみたんですが、
RDBMSの制約では実現できないんでしょうか・・・。

358 :NAME IS NULL:2005/09/20(火) 05:41:11 ID:???
>>357
構造は>>356のような感じで作る。
その後制約したいテーブルをビューでラップ。
追加、更新時にトリガーをかませ、制約テーブルを読み取り違反していれば
クライアントに例外を投げる。

俺だったらこんな感じにする。

359 :NAME IS NULL:2005/09/20(火) 10:09:33 ID:???
テーブル制約では不可能でしょ。
358さんのいうように、アプリ(ストアド・トリガー)の範疇だと思います。

360 :NAME IS NULL:2005/09/20(火) 10:25:52 ID:???
参考になりました。ありがとうございます。

361 :NAME IS NULL:2005/09/29(木) 15:32:26 ID:gDAO8DBJ
日付のついた取引の表示順序を、その日の中で任意に設定したいのですが、
定石的な方法をご教示ください。

各取引から次の取引に外部キーをもたせて連結リストっぽくすると、
挿入や削除でいじる箇所が少なくてすみますが、
リストが切れた場合の危険があるからよくないですよね?

各取引の表示順序を1からの連番としてもたせるとすると、
挿入や削除が発生したときに手間がかかります。
10おきとかの番号をつけて、足りなくなったら番号つけかえるのが
現実的でしょうか?


362 :NAME IS NULL:2005/09/29(木) 16:03:04 ID:???
追記式で追加しながら順序も決めるならば、普通にリスト構造にすればいいんじゃないの?
又は、順序カラムを数値で持っておいて、差し込み先より大きい列に対して、+1するUPDATEで割り込み完了。

そもそもで、そういう仕様は蹴飛ばすような・・・。
順序が任意ならば表示側のソートで勝手にしてってするか、
ソートした最終結果だけ受け取ってがらがらぽんする。


363 :NAME IS NULL:2005/11/30(水) 14:22:09 ID:???
販売管理の売上データなどで売上伝票番号がキーとなる
データがあるのですが、この番号は意味のない連番なんですが
(但し、その番号を入力して該当すれば売上伝票を表示します。)
別途、意味なしキーを追加したほうがいいのでしょうか?

また、マスタに業務上のキー以外に意味なし連番を作成した場合に
売上データなどにマスタ値としていれるのは業務上のキーでOK?
業務上のキーを入力されたら、マスタを参照してわざわざ意味なし
連番をセットするのが面倒っていわれたんだけど・・・



364 :NAME IS NULL:2005/12/01(木) 01:07:01 ID:???
>>363
> 販売管理の売上データなどで売上伝票番号がキーとなる
> データがあるのですが、この番号は意味のない連番なんですが
> (但し、その番号を入力して該当すれば売上伝票を表示します。)
> 別途、意味なしキーを追加したほうがいいのでしょうか?

どちらでもよい。
俺はシンプルなのが好きだから、必要ないときは
意味なしキーは作らない。

ただ、最近はRubyOnRailsやHibernateなど、
アプリ側のアーキテクチャの都合で意味なし連番が
効果を発揮する場合がある。

基本的には好みの問題だけど、意味なし連番をつける
メリットが明らかにあるときはつける、なければつけない
という方針が分かりやすいかもしれない

> また、マスタに業務上のキー以外に意味なし連番を作成した場合に
> 売上データなどにマスタ値としていれるのは業務上のキーでOK?
> 業務上のキーを入力されたら、マスタを参照してわざわざ意味なし
> 連番をセットするのが面倒っていわれたんだけど・・・

俺なら業務上のキーをそのままセットさせる。
一応ユニーク制約はつけておいて。
はっきりとメリットを説明できないことはやらない

365 :363:2005/12/02(金) 20:53:58 ID:???
>>364
webアプリなどでは有効ということですね。

>俺なら業務上のキーをそのままセットさせる。
マスタのキーが変更になるとデータまで変更しなければ
ならなくなると思うのですが・・・・
でもデータを見たときにわかりやすいというメリットはあります。
どちらがいいのでしょうか。

366 :NAME IS NULL:2005/12/03(土) 01:36:35 ID:???
>>316
このへん読んでみなはい。

367 :NAME IS NULL:2005/12/03(土) 01:52:24 ID:???
つか、マスタのキーってのはそういう変更が起きないように慎重に設計するんだよ。
コード体系とか適当に作って、後で泣きを見るってのはよくある話だ

368 :NAME IS NULL:2005/12/12(月) 11:39:12 ID:???
設計時にうまくできてても、使ってるうちに使い方も変わって、なんだか最適から外れてきそう。
現場の使い方の詳細な知識が有れば、余裕もって作り込み出来るかも知れないけど、現実は与えられた情報でヤマかけて作り込むしか無いな。

項目増えたらまた設計し直しって言うのも面倒だな。
業種別の汎用的なモデリング例とか共通化してしまえば楽だと思うけど、モデリングで飯喰ってる香具師には営業妨害かな。

369 :NAME IS NULL:2005/12/13(火) 00:48:14 ID:???
それっていわゆる「アプリケーション」。SAPとかOracleとかの。
でもいくら汎用的にって言っても顧客のビジネスルールは千差万別だから、
業務をシステムに合わせるためにコンサルが出てきたりカスタマイズが
必要だったり、ってことになるんだけどね。

370 :NAME IS NULL:2005/12/13(火) 11:52:17 ID:???
そしていつのまにか原型をとどめないほどのカスタマイズの嵐で
結局イチから作ったほうがよかったんじゃねーかという罠。l

371 :NAME IS NULL:2005/12/17(土) 15:20:22 ID:???
カスタマイズはあんまりせずに、汎用性の枠の中で解決した方が生産性は上がると思うけどね。
顧客のビジネスルールごとに似たような設計を繰り返すのは無駄だと思う。

ISOでもJISでもいいから定義しないかなあ。

372 :NAME IS NULL:2005/12/17(土) 17:17:01 ID:???
まぁ、そういうのは何度も試みられているがな。
カスタマイズが減ると仕事も減りそうw

373 :NAME IS NULL:2005/12/18(日) 00:16:39 ID:5chxNrki
Len Silverston の Data Model Resource Book って本を参考に、
設計に反映できたらいいなと思っています。
できれば日本語だとありがたいのですが、日本語訳の計画などないでしょうか。
日本でデータモデル系の本を書かれてる方の一部にとっては気になる本(種本?)に
なっている傾向もあると思うし、モデル自体のいい悪いは別にして、
素人考えでは結構売れると思う(一冊は手元に置きたいという需要もあるだろうし)。

例えば、この本の中で、相手先の管理(顧客マスター)で履歴管理が必要な場合などの
データモデルなどモデルで提示されていると参考にしたくなる。個人名の
履歴管理として、刑務所の囚人の名前として偽名やあだ名の管理などにも言及
していたりして面白いと思う。(ある人物が名前や住所をいくつも持つという状態)

提示されているモデルを盲信しないようにということもあるかもと思ってしまうが、実際、
この本の評価(モデルの有用度)はどんなものでしょうか。



374 :NAME IS NULL:2005/12/19(月) 02:11:17 ID:???
日本の場合は、役所納入用の標準仕様をJISで定義してくれれば普及しそうな気がする。

375 :NAME IS NULL:2005/12/22(木) 01:02:21 ID:???
本屋でひととおり見て来たが、いまいちこれだって本には巡り会えなかった。orz

376 :373:2006/01/09(月) 12:12:34 ID:???
Data Model Resouce Book Volume1について補足。
この書籍内のER図の表現では、FKは(自明として)省略され、
またサブセットの表現が箱の中の箱(入れ子構造)で表現されていたりと
いまいちなじみにくい。その点、付属のCD-ROMからER図を別ツールで
リバース作成すればFKも全て表現されておりサブセットも別な箱として
表現されるのでなじみやすく、さらに全体像も把握しやすい。

但し、付属のCD-ROMはUnlockCodeを購入しないと、サンプルしか参照できない。
以下のサイトからUnlockCodeを購入してUnlockすると、書籍内の参照制約などを
含んだデータモデル全部のDDLが得られる。UnlockCodeの購入は値段が高いのだが
勇気を持って購入手続きして損はないと個人的には思う。

ttp://silverston.wiley.com/
-[Unlock your Volume 1 CD]

ODBC用,Oracle用,SQLServer用の3種類のDDLがあるので、
そのDDLを使用してDBを作成し、ERWinやSIObjectBrowserERの体験版などで
ER図をリバース作成すれば、リレーションもきれいに描画されると思う。
論理モデル用ってのでは全部で501個のテーブルが作成される。
Oracle用のDDLを試してみたところうまく行った(Oracle817)。
ODBCとSQLServerは試してない。


377 :NAME IS NULL:2006/01/10(火) 09:58:29 ID:???
おまいがその経験を元にもっと分かりやすく書いた物を出版すると良書に成る悪寒。
暇ならがんがれ。

378 :NAME IS NULL:2006/01/25(水) 02:11:14 ID:???
>>376
俺もタネ本として買ったよ。
読むたびに、なにがしかを得られる本だよな。




379 :NAME IS NULL:2006/01/27(金) 11:28:43 ID:???
:378 s/なにがしか/なにかしら/

380 :NAME IS NULL:2006/02/26(日) 10:11:56 ID:hHkdb9kS
すいません、DBDesigner4を使用してMySQLからER図をリバースしようと思っているのですが、
localhostのMySQL4.1.13に接続しようとすると

dbExpress Error: Invalid Username/Password

というダイアログが出てしまい接続できません。
どなたかこの現象の回避方法をご存知の方いたら教えて下さい。
お願いします。

381 :NAME IS NULL:2006/02/26(日) 10:32:58 ID:???
>>380
ヒント:英語の辞書


382 :NAME IS NULL:2006/02/26(日) 10:41:01 ID:hHkdb9kS
>>381
ダイアログの内容を読め、といった意味であればそれくらいはさすがに分かっています。^^;
UsernameもPasswordも一致しているのにこのメッセージが出ているから困っているのですが・・・。
root以外のユーザもいくつか作成して試しましたが同じでした。

それとも海外にこの現象について解説したサイトがあるって事でしょうか?
う〜む・・・。

383 :NAME IS NULL:2006/02/26(日) 15:27:07 ID:???
MySQLは4.1から認証方式が変わってるから、そのせいではないかい?
OLD_PASSWORD関数つかってみれ
例:
UPDATE mysql.user SET Password = OLD_PASSWORD('hogehoge') WHERE User = 'foo';
FLUSH PRIVILEGES;


384 :380:2006/02/26(日) 17:43:32 ID:hHkdb9kS
>>383
ありがとうございます!
教えて頂いた通りやってみたところ、エラーは消えて無事接続できました!

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

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

でもお陰で勉強になりました。
本当にありがとうございました!

385 :NAME IS NULL:2006/02/27(月) 01:44:31 ID:???
ふーん、リバースなんて機能あったんだ。
でも、もともと不安定なツールだからね>DBDesigner4

386 :NAME IS NULL:2006/03/04(土) 14:33:11 ID:DNs0MEkq
MySQLに対応してるモデリングツールで
論理・物理名を切り替え、同時表示できるのありますか?

387 :NAME IS NULL:2006/03/10(金) 08:45:13 ID:pPH8uClm
最近?でも無いのかも知れないけど、IDとCDの使い分けを
推奨する読み物を見掛ける事があるのですが実際の所どう思います?

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

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

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

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

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

その辺のバランスが、私の経験だとヤリスギと感じるのですが、
どう思いますかね?

388 :NAME IS NULL:2006/03/10(金) 09:55:44 ID:???
(1) joinするときに便利(複合主キーの場合)
(2) 変更履歴を管理しやすい(コード変更時は直接変更ではなく古いコードに削除フラグを立てる、という感じ)
(3) 最近のアプリケーションフレームワークにシステムidを前提にしたものが増えてきている(Hibernate,RoRなど)

389 :NAME IS NULL:2006/03/10(金) 12:49:21 ID:???
仕様変更とか柔軟になるし
要求側には出来る限り押し通す

390 :NAME IS NULL:2006/03/10(金) 12:57:26 ID:???
モデリングする段階ではCDを主キーとして、IDは実装段階で
主キーにするのでは。

391 :387:2006/03/12(日) 03:12:21 ID:???
>>388
>(1) joinするときに便利(複合主キーの場合)
4階層目のテーブルなどで、主キーの項目数が、やむえず増えた場合に
代替となるIDを振る事には、同意です。
気になっているのは、1:1でCDとIDを作成する事が、どうなのかなぁと。。

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


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

立てる、という感じ)

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

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


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

る(Hibernate,RoRなど)
な〜るほど、それには従った方がよさそうですね。


392 :387:2006/03/12(日) 03:14:03 ID:???
>>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



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

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

ちなみに、ON UPDATE CASCADEのサポート状態を、ざっと調べてみた所、
使用可:SQLServer2000 , Access97 , MySQL4.0.8 ,pgsqlでも使えるっぽい。
使用不可:Oracle(Oracleで使えんのは問題か。。?)


394 :NAME IS NULL:2006/03/13(月) 12:46:46 ID:???
自分は主キーは更新しないって前提で組むな。
主キーに整合性とってないデータも有ったりだし。
別に外部キー更新したい訳じゃないし。

395 :NAME IS NULL:2006/03/13(月) 20:08:01 ID:???
履歴をどうするかなあと考えていたが、削除フラグねえ。仕様としては前回履歴のみ?
無限履歴とか、ラスト5回履歴とか、便利では有るが、ディスク容量喰うよなあ。
年度毎あたりでダンプして履歴リセットって仕様にすると、継続サポートコスト発生で開発側はウマーかな?

396 :387:2006/03/13(月) 20:57:29 ID:???
>自分は主キーは更新しないって前提で組むな。
私も基本は、主キーは変更しないという考えです。

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

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


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

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

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

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

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

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


他には、IDとCDを分けた場合、履歴系はデータを登録しすぐに削除し
また同じCDで登録した時に関連が切れるという点をユーザーに理解
してもらう必要があると。(たいした問題ではない。)


397 :NAME IS NULL:2006/03/26(日) 12:56:39 ID:???
T字型書けるツールってない?visioじゃないみたいだし・・

398 :NAME IS NULL:2006/03/27(月) 17:42:12 ID:???
EXCEL

399 :NAME IS NULL:2006/03/32(土) 00:02:21 ID:???
>>397
T字型は表記法と正規化における規則であって、正規化そのものじゃないと思うけど。
ER 図なら Visio や ER Studio などで十分。

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

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

これは、表記法がT字型であろうとなかろうと、結果は一緒になる罠。
理由は70、71が言ってるとおり。

400 :NAME IS NULL:2006/03/32(土) 17:00:56 ID:uNjChBox
>>397
DynamicDraw(ttp://www.molips.com/jp/)

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

EXCELとかWORDは矢印線の先端スタイルが限られているから
いまいち使えないね。「ファイルが開けないよ〜」って人には
WORD or EXCELにクリップボード経由でメタファイル形式で貼り
付けて渡せばいいし。
(再編集はできないけど。)

401 :NAME IS NULL:2006/04/02(日) 01:56:16 ID:???
>>400
ありがとう。結構よさげだね

402 :NAME IS NULL:2006/04/05(水) 22:46:40 ID:5UG0+3IT
ER図のサンプルが沢山見られるサイトとかってありますか?
勉強用にいろいろ見てみたいのですが・・・。


403 :NAME IS NULL:2006/04/22(土) 05:31:29 ID:pFb3dyuH
最近、モデリングの勉強はじめました。
下記以外にお勧めの書籍ありましたら、お教え願えませんでしょうか。

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

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


「T字形ER」は新しいのを読んだので、ほか2冊は読まなくて良いかなと
思ってるんですがどうでしょう?
(店頭で見つからないので、内容確認できないんです)

404 :NAME IS NULL:2006/04/22(土) 07:26:55 ID:???
たくさん読めばよいというものでもないと思うが・・・

405 :NAME IS NULL:2006/04/22(土) 13:18:55 ID:pFb3dyuH
モデラーが10人いれば10通りのモデリングがあるって聞いたので。
実際、著者により主張が違うところがあるので自分で比較検討してみたいんです。
>>402 さんみたいに、サンプルを沢山見てみたい、てのもあります。

406 :NAME IS NULL:2006/04/24(月) 04:43:21 ID:???
T字型ってモデルの属人性を排除するんじゃなかったけ?

407 :NAME IS NULL:2006/04/25(火) 00:55:55 ID:???
そういう問題ではないだろう。
いろいろ勉強すればT字型ってダサいなぁと気付いたりするわけよ

408 :NAME IS NULL:2006/04/25(火) 10:26:47 ID:???
あのダサさがいい

409 :NAME IS NULL:2006/04/25(火) 13:26:45 ID:???
>>407
じゃあ、ナウでヤングなモデリングを教えてくだされ。

410 :NAME IS NULL:2006/04/28(金) 01:15:02 ID:???
T字形って、認知番号重視なのは解るけど、
わざわざ主キーを非明示にする理由がわからん。


411 :NAME IS NULL:2006/04/30(日) 10:51:28 ID:???
ヒント:馬鹿避け

412 :NAME IS NULL:2006/05/07(日) 13:07:50 ID:???
データモデリングはどのような書籍で勉強しましたか?

413 :NAME IS NULL:2006/05/07(日) 21:18:58 ID:???
OJT

414 :NAME IS NULL:2006/05/11(木) 00:42:24 ID:???
>>411
えー。
DB屋以外の関係者との会話に使えないような記法はどうかと思うけど。

415 :NAME IS NULL:2006/05/11(木) 00:59:09 ID:???
うん、だから流行らない

416 :NAME IS NULL:2006/05/11(木) 07:29:29 ID:???
>>414
哲学者とは会話できるようになるぞw

417 :NAME IS NULL:2006/05/14(日) 01:28:50 ID:???
T字形の新しい本を読んで思ったのは...
あの理論編の哲学議論がまさに「言語ゲーム」。

418 :NAME IS NULL:2006/05/14(日) 01:42:07 ID:???
ヲウムと同じだよね。
悟り開いて宙に浮く様になれば尊師の教えが分かるよって感じ。

傍から見てるとDQNにしか見えない罠。

419 :NAME IS NULL:2006/05/14(日) 13:29:08 ID:???
理論編だけ読み飛ばせばモーマンタイ

420 :NAME IS NULL:2006/05/15(月) 00:55:43 ID:???
そうはいかんよ。

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

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

あの理論編は、ぜんぜん「理論」になってなくて、いろんな哲学のオイシイ結論を寄せ集めただけに見える。
だってボク、クリプキ好きなんだもん、とか言われても困っちゃう。

421 :NAME IS NULL:2006/05/15(月) 04:32:07 ID:???
実践編、かなり有用と思うよ
でも、たしかに理論書としては、ちゃんと筋道たてて説明してない感じがする。
論理の飛躍がある、というより、断片を継接ぎした結果みたいな。

モデリングって学問としてあるわけじゃないのかな・・
奥が深いし、博士号取得した哲学者や数学者がもっと研究してほしい

422 :NAME IS NULL:2006/05/16(火) 19:37:34 ID:???
計算量の上界値、下界値ってどういうことなんですか?
上界値=計算量が最大と思われる値?

423 :NAME IS NULL:2006/05/16(火) 23:01:00 ID:???
それより大きいことはありえないと保証できる値
てか板ちがい

424 :NAME IS NULL:2006/05/16(火) 23:20:39 ID:???
>>423
レスありがとうございます。
では、これはどこの板行けばいいんですかね?プログラム板ですか?

425 :NAME IS NULL:2006/06/29(木) 00:28:29 ID:s69NJyt8
Visioって作ったモデルからCreate文生成したり,DBに直接テーブル作成したりできるん?

426 :NAME IS NULL:2006/06/30(金) 12:54:48 ID:5MdCXCSh
新しい職場で、設計がやたら縦持ちになってるんですが、縦持ちってポピュラーな方法なんですか?
扱いにくくってしょうがないんですが。

427 :NAME IS NULL:2006/06/30(金) 13:03:31 ID:???
>>425
VisioのProfessional版を使っていて、できそうだったのでちょっとやってみたら
「Enterprise Editionを使え( ゚Д゚)ゴルァ!」と言ってきました。インスコしてないので試せないが、
Enterprise版を使えばできると思われ。MSDNにはついてきていると思う。


428 :NAME IS NULL:2006/06/30(金) 23:23:03 ID:???
Create分まで作りたいんなら、VisioよりDBDesigner4を勧めたい

429 :NAME IS NULL:2006/07/01(土) 11:42:35 ID:???
>>428
理由等わかればkwsk


430 :NAME IS NULL:2006/07/01(土) 15:00:38 ID:???
タダだから

431 :NAME IS NULL:2006/07/02(日) 07:56:49 ID:???
仕様書作る時にはvisioのほうが便利。
実装と文書化の二度手間のほうが苦痛。

432 :NAME IS NULL:2006/07/02(日) 09:59:38 ID:???
仕様書ってどういうレベルのもの言ってんだ?
DBDesignerでもER図やDB定義書くらい作れるぞ

433 :NAME IS NULL:2006/07/02(日) 15:46:50 ID:???
客と下請けに提出する清書レベルだよ。
手書き程度ならチラシの裏に落書きで十分だし。

434 :425:2006/07/05(水) 22:25:25 ID:???
レスくれた方ありがとうございました。Visio for Enterprise Architects
というバージョンで出来ました。

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

  AAABBCC

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

こんな感じです。AとBとCは親−子−孫の関係にあるのですが
この親−子−孫を表せるようにモデリングするにはどうしたらよいでしょうか・・・・

435 :NAME IS NULL:2006/07/06(木) 18:28:47 ID:???
>>434
親=PK:|AAA|
子=PK:|AAA|1-n|BB|
孫=PK:|AAA|1-n|BB|1-n|CC|
かな?

んで。気になるのは。各コードは固定長でなく可変長なんですか??

436 :NAME IS NULL:2006/07/06(木) 22:26:39 ID:???
>>435
あ、固定長です。

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

これは、まさしくこんな関係です。

437 :NAME IS NULL:2006/07/10(月) 23:41:46 ID:2umW5dHJ
あるリソースエンティティ同士の関係を表すのに
交差エンティティを作成するという例はよく見かけるのですが、
イベントエンティティ同士の関係についても交差エンティティを作成するという
事はあるのでしょうか?
たとえばある複数の勘定科目から出金して、出金した額を別の種類の複数の
科目へ入金するといった作業があるとして、出金エンティティと入金エンティティ
との関係はどう表したらよいのでしょうか。

438 :NAME IS NULL:2006/07/10(月) 23:45:40 ID:EbhJ+Fw+
yhSEfIF00

439 :NAME IS NULL:2006/07/11(火) 02:01:08 ID:???
>>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


440 :NAME IS NULL:2006/07/11(火) 14:42:29 ID:???
DB作る前に簿記の勉強したほうがいいね。
帳票をそのままDBにすればおk。

441 :NAME IS NULL:2006/07/15(土) 15:39:26 ID:???
簿記検定受験後の今その言葉の重みが良くわかる

442 :NAME IS NULL:2006/08/27(日) 18:38:29 ID:7FPwEeLv
つまらない質問で申し訳ないのですが、
顧客IDなどのコードの作成方法は
決まっているのでしょうか。
社員番号なら入社年月日+連番
などでいいと思うのですが、
何か指針はあるのでしょうか。

443 :NAME IS NULL:2006/08/28(月) 01:10:22 ID:???
連番も何桁取るとか有るよ。2桁じゃ100人入ったら終わり。
総務や人事と打ち合わせて決めたほうがいいよ。
全社的に統一しないと意味がない。

顧客コードなら営業とかと打ち合わせて決めるべき。
営業上、顧客の元に自社の顧客番号が付いたものが送られるし、「ああ、うちって100社目なんだな」って推測されちゃうような顧客IDは恥ずかしい。

444 :NAME IS NULL:2006/09/01(金) 01:41:11 ID:???
設計するのに使ってるツールとか教えて!
XEADとかJude、ObjectBrowserERあたりがよさげなんですが!!
今試そうと思ってるのがOracle JDeveloper10g!!!

445 :NAME IS NULL:2006/09/01(金) 17:52:21 ID:???
DBDesigner4最強。
XEADだけは勘弁

446 :NAME IS NULL:2006/09/02(土) 23:04:56 ID:???
>>445 さんへ
XEADは、どこら辺が駄目だと思いますか?

447 :NAME IS NULL:2006/09/16(土) 01:13:27 ID:???
ナチュラルキーとサロゲートキーって使い分けどうしてますか?
顧客マスタとか商品マスタみたいなのはナチュラルキー、
受注TRとか売上TRはサロゲートキー、
仕様変更が多そうならサロゲートキー多め、
ERモデリングツール使うならナチュラルキー、
ORマッピング使うならサロゲートキー、
こなかじ?

448 :NAME IS NULL:2006/09/16(土) 01:23:02 ID:???
知るか。何でもいいよ。
あれもアホな議論だったな

449 :NAME IS NULL:2006/09/17(日) 01:56:26 ID:???
佐藤 正美氏が提唱する「T字形ER」ってどうなんでしょ。会社の上司が
信者(?)で何が何でも導入したいみたいで。。。本を読んでみたけど
文章表現は下手(だと思った)だし理論にしても判り辛いような。。。
数千人規模の会社の基幹業務構築のモデリングには大丈夫なのかな〜?
と思ってます(例えば数年後には理論自体廃れてるとか・・・)。

450 :NAME IS NULL:2006/09/17(日) 02:41:45 ID:???
>>449
いいところはresource概念とevent概念云々のところぐらいか
あとはちょっと・・・。identifierの扱いがアレなんで、あの理論をそのまま適用するのは
実際的ではないと思う

451 :NAME IS NULL:2006/09/17(日) 04:11:40 ID:???
データモデリングなんて勘でやるのが一番いい。
主キーと関連だけしっかり抑えとけば大概上手くいく。

大事なのは、間違ったモデリングなんてないと知っておくこと

452 :NAME IS NULL:2006/09/17(日) 16:38:22 ID:???
勘でやる時点でだめだめな悪寒。

いろんなモデリングのシミュレーションソフトとかあれば設計時に検証しやすくて便利なのにな。

453 :NAME IS NULL:2006/09/18(月) 11:28:44 ID:???
>>449
基幹ではないが、大手での採用例はあり。
和光市の某自動車メーカとか、麹町の某信販会社とか。
ただ、T字型を使ったプロジェクトで試行錯誤した経験者がいない状態で
本読んだだけでいきなり実地の大規模システムに適用しようとすると
多大な困難が待ち受けていそうな悪寒が…

454 :TM使ってるよ:2006/09/20(水) 14:17:52 ID:6C6LnzZC
TM(T字形ER手法)は、CoddのRDBMに始まって、正規化だけでは解決しない問題を検討している間に、
業務系のシステムでは「コード体系」を使って分析するのが便利って便法を思いついたりしながら発展して
きましたが、根っこの部分ではオブジェクト指向におけるドメインモデリングと繋がっています。
なので、#453 の方が言われる様に、本を読んだだけで見よう見真似で始めるのは、少し辛いでしょう。
できれば、本人から習うことが可能なので、それが一番だと思います。
http://www.sdi-net.co.jp/ に行ってみましょう。

455 :NAME IS NULL:2006/09/23(土) 17:10:07 ID:???

HP見てみたけど、本当大丈夫なの?かなり素人っぽいHPで
すが。コンサルとかやってるんんだったらもうちょっとマシな
HPにした方がいいような。。。
それに実績も書いてないし。>>453 の和光や麹町の会社ではどれだけ
TMにより実績がでたのかな?
コンサルやるなら会社(?)の規模も知りたいなー

456 :NAME IS NULL:2006/09/24(日) 12:10:14 ID:???
麹町では使ってはいるが「お絵かきソフト」程度の使われ方。
「Visioの方が書きやすいじゃん」ってノリだから「TMを
導入してビジネスの強み・弱み・・・」なんて程遠い状態。

457 :NAME IS NULL:2006/09/24(日) 20:16:59 ID:???
>>455
WebPages見てそういう感想抱いたのなら、TMとは出会わなかったことにした方が多分幸せになれる。
いや、煽りや皮肉ではなく、本音ベースの話。
感覚的な「合う」「合わない」っていうのは結構重要な要素かと。

458 :NAME IS NULL:2006/09/25(月) 00:31:01 ID:???
HP見たけど「1,000,000 ステッフ゜ 規模の システム であれば、10数名で、6 ヶ月以内に導入する。」
ってのは凄いなー。
事例とかあるといいけどね。

459 :NAME IS NULL:2006/09/25(月) 01:10:08 ID:???
優秀なエンジニアが集まればとか、そのための費用を出せるならとか前提条件いっぱいだろ?
まあ優秀なエンジニア集めれば、別に何でも短納期でできそうな悪寒。
そういう論点のすり替えをして一儲けするのがコンサルと言えばそうだけど。

460 :NAME IS NULL:2006/09/25(月) 10:26:51 ID:???
>>458
ステップってコード量だよねぇ?
でコンサルが開発するわけじゃないだろうし、有効なメトリクスなのかね?
コンサルとしてはそういうところ大事だと思うんだが。

461 :NAME IS NULL:2006/09/26(火) 00:04:22 ID:???
画面数とかテーブル数とかユースケース数とかでないとピンと来ない

462 :yossy:2006/09/26(火) 00:38:05 ID:3/C3qjqe
皆様始めまして。
DBDesigner4の使い勝手が良かったので日本語化してみました(需要アルカナ・・・)
http://dbdesigner.iimp.jp/
使ってみてご意見いただければと存じ上げます。
Delphiはあまり使ったことがないので安定度が下がっているかもしれません。。
あと、、まだWindows版しかコンパイルしていないです・・・。
Linuxはあまり慣れていないもので。。すみません。。。

463 :NAME IS NULL:2006/10/02(月) 23:45:41 ID:???
>447

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

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

なんて言い訳でサロゲートキーにしてる。

464 :NAME IS NULL:2006/10/02(月) 23:56:56 ID:???
>>463
>候補キー自体が安定していることが前提なのに、変わることあるから・・・
間違えた。
候補キー -> 主キー

172 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)