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画像を閲覧するためのプラグイン


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
■ このスレッドは過去ログ倉庫に格納されています

>>1
  し'∪   |   |   |   ∪ /  電波〜   電波〜    \毎日何処かの板で糞スレを立てる>>1
          ̄ ̄ ̄ ̄     /  .∧__∧      ∧__∧      \糞スレを立てる事しかできない白痴。
      ガッキーン       /  ( ゚∀゚ )    ( ゚∀゚ )          vetx/1060350786/1" target="_blank">>>1 @顏/test/read.cgi/db/1057509675/">★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)