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:???
「オブジェクト指向の幻想について」で盛り上がってます。


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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)