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

**名無しさん＠お腹いっぱい。** · 03/07/07 01:41

データベース構築の上流工程であるモデリングについて語らうスレッドです。
モデル作成に関する質問、質問に対する回答、
作ったモデルの自慢、自慢されたモデルの批評など、
モデリングに関すること全般を扱います。

ソフトの使い方に関する話題、物理的なモデルの話題はご遠慮ください。
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画像を閲覧するためのプラグイン

**NAME IS NULL** · 04/02/21 19:49

TH法がマイナーっていわれると時代を感じるな
椿さんの本を買って読め

**NAME IS NULL** · 04/02/22 13:50

　amazonで調べると、椿正明って人ですか？

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

04/02/26 02:00

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

こういう学術的な（？）会と２ｃｈは無縁でしょうか
どなたか参加されてます？

04/02/26 08:20

*現代の* DOA を学ぶのによい一冊を教えてください。
600ページくらいまで、洋書でもまったく構いません。

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

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

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

**124** · 04/02/26 08:21

【自分の考える対比】
・機能要求、非機能要求を項目として列挙する。
→ 要求定義だから変わらないと思う。

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

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

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

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

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

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

**NAME IS NULL** · 04/02/27 00:37

DOAでUMLは重要ですか？またどの図を使いますか？

**NAME IS NULL** · 04/02/27 22:42

>>124
>600ページくらいまで、洋書でもまったく構いません。

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

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

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

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

**NAME IS NULL** · 04/02/29 16:02

>>112
商品名の履歴が必要なシステムで、

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

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

04/03/04 00:46

>>128
　無視されてるのじゃなくて、答える必要を感じてないんですよ

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

**128** · 04/03/04 08:49

勘違いしてました。
全然問題ないですね、問い合わせ年月日が１年前でも。
失礼しますた。

04/03/04 21:25

>>130

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

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

**(゜Jし゜)** · 04/03/04 23:28

昔、我が社で開発した前年度比計算プログラムでは、
うるう年のチェックをしてなかったので、先月末に大パニックになったらしい。

04/03/05 08:08

>>132

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

　２／２９が日曜だったので大きな混乱がなくてよかった

**NAME IS NULL** · 04/03/11 16:00

>>131
各年の基準日をテーブルに入れておけば
基準日からの日数を計算してSQLで処理できそうだけど
そんなに甘いもんじゃない?

**NAME IS NULL** · 04/03/25 00:07

age

**NAME IS NULL** · 04/05/23 22:43

ＥＲすたでぃおのライセンス高すぎ

**NAME IS NULL** · 04/06/29 00:24

総勘定元帳のテーブル作ってみたら凄い横長になっちまったんですが、どうしたもんでしょう・・・

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

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

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

**NAME IS NULL** · 04/06/29 07:07

>137
データの発生元が異なる物を同じテーブルに入れない方が良い.

**137** · 04/06/29 20:40

すると例えば、こうでしょうか

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

**NAME IS NULL** · 04/06/30 01:09

>139
借方金額、貸方金額は別テーブルから導出できない？
導出可能なデータはViewでもってもテーブルにもたない方が良い.
よほど速度を気にする場合は別だが.

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

**137** · 04/06/30 03:14

うーん、そうすると仕訳の明細を持ってるテーブルから算出する形になるかな？
いちいち計算させるのはどうかと思ったのでテーブルに持たせた方がいいかなあと

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

**NAME IS NULL** · 04/06/30 06:21

>141
>> いちいち計算させるのはどうかと思ったのでテーブルに持たせた方がいいかなあ

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

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

**NAME IS NULL** · 04/06/30 07:04

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

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

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

**137** · 04/07/01 21:55

>>142-143
ありがとうございます
大変、参考になりました

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

**NAME IS NULL** · 04/07/04 01:59

クラスタ表って、どのくらい使われてるのだろう。
とりあえず、俺が設計するなら一生使いたくないのだが。

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

**NAME IS NULL** · 04/07/08 22:31

Ｔ字型ＥＲってどうですか？

**NAME IS NULL** · 04/07/08 23:59

>145
>> 俺が設計するなら一生使いたくないのだが。
なぜ？

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

>146
使い用.

**NAME IS NULL** · 04/07/09 00:09

途中で送信してしまった.

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

**NAME IS NULL** · 04/07/23 10:53

>>146

　　　　　　r;ｧ'N;:::::::::::::,ｨ／　　　　　 >::::::::::ヽ
.　　　　〃　　ヽﾙ1'´　　　　　 ∠:::::::::::::::::i
　　　　 i′　　___,　-　,. = -一　￣ｌ:::::::::::::::ｌ
.　　　　　 ! , -＝=､´r'　　　　　　　　 l::::::/,ﾆ.ヽ
　　　　　　ｌ　　　　　　　　_,, -‐''二ゝ　ｌ::::l fﾞヽ |、ここはお前のER図じゃねえんだ
　　　　　ﾚー-- ､ヽヾﾆ-ｧ,ﾆ;＝、_　　 !:::l ） } ト
　　　　　　ヾ¨'７"ry､｀　ｰﾞ='ニ,,,｀　　 }::ヽ(ノ　「ラピュタ」の中にでも書いてろ
:ｰゝヽ､　　 !´ "￣ 'l,;;;;,,,.、　　　　　　　,i:::::::ﾐ
::::::::::::::::ヽ.-‐ ﾄ、　r'_{　　 __)｀ニゝ、　 ,,iﾘ::::::::ﾐ　　　
::::::::::::::::::::Vi／l:::V'´;ｯ`ﾆ´ｰ-ｯ-,､:::::`"::::::::::::::;ﾞ　, 　な！
:::::::::::::::::::::::::N. ﾞ､::::ヾ,.｀二ﾆ´∠,,.i::::::::::::::::::::/／／
:::::::::::::::::::::::::::::l　ヽ;:::::::::::::::::::::::::::::::::::::::::::／　／
::::::::::::::::::::::::::::::!　:|.＼;::::::::::::::::::::::::::::::／　／

**NAME IS NULL** · 04/09/10 21:46:17

>>98
新作マダー？

**NAME IS NULL** · 04/09/20 19:27:25

visio2003なんですが、データベースのER図で
ただの矢印でなくリレーションの種類によって
蛸足とか丸印とか付いてるのを見かけます。
あれはどうやったら出せるのでしょうか？

**NAME IS NULL** · 04/09/22 12:16:06

2000しか知らないけど、線のプロパティで始点と終点の形状を弄れば出てくるぞ。

**NAME IS NULL** · 04/09/24 16:52:16

たとえば顧客マスタで、顧客には最大５人まで担当者がいる場合に、

顧客コード・顧客名・担当１・担当２・・・担当５
とするか、

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

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

**NAME IS NULL** · 04/09/24 17:40:43

迷うならとりあえず正規化しとけ。
プログラミング局面では、最大値が決まっていようがいまいが正規化されてるほうが楽な事が多いよ。
担当者が3人以上いる顧客を抽出・・・ってな要件が出たとき、横に長いテーブルだとﾏﾝﾄﾞｸｻ
あくまで例えだけど。

**151** · 04/09/25 00:26:24

>>152
ありがトン!

**NAME IS NULL** · 04/09/25 01:29:10

>>154
でも担当者を横一列に並べようとする時に
正規化するとめんどくさいですね。

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

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

**NAME IS NULL** · 04/09/26 00:57:28

>>156
出力する局面で正規化するしないを判断するなんて論外。

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

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

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

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

**156** · 04/09/26 10:22:16

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

**156** · 04/09/27 10:26:37

>>157
うーんそうか、流石に5人ともなると前詰とか考えなきゃいかんわけか。
実は俺がやったシステムは担当者は2名だったんで
正規化してませんでした（設計は別の人）。

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

**NAME IS NULL** · 04/10/08 07:13:32

担当1・担当2のようになるなら繰り返し。
最大値が決まってるというのは幻想で、実は今だけってのが現実

**NAME IS NULL** · 04/10/08 07:15:55

最大値を制限するのはプログラム側でなくDBのトリガや制約等の機能を利用し
て制限するのが普通

**NAME IS NULL** · 04/10/08 07:16:48

とにかくやつらにプログラムさせるな、が基本

**NAME IS NULL** · 04/10/08 07:52:30

>>161
ユーザーにやさしくエラーを返してあげるためにプログラム側での工夫も必要？

**NAME IS NULL** · 04/10/08 10:05:34

>>163
それはこっちでちょっと話題になったな
↓
制約っていらなくね？
http://pc5.2ch.net/test/read.cgi/db/1087483786/l50

悩みどころだね。

**NAME IS NULL** · 04/10/09 01:08:08

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

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

**NAME IS NULL** · 04/10/09 14:07:44

>>165
C/Sの業務アプリなんかだとそう理想どおりいかないんですわ。

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

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

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

**NAME IS NULL** · 04/10/09 16:04:43

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

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

**NAME IS NULL** · 04/10/09 16:12:21

ユーザーに返すエラーメッセージを「不正な処理を行ったため停止します」に統一
すればいいんじゃない？

**NAME IS NULL** · 04/10/10 13:02:37

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

**NAME IS NULL** · 04/10/10 14:11:41

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

SAPとかそんな感じだよね

**165** · 04/10/10 19:39:45

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

**NAME IS NULL** · 04/10/17 20:38:10

DB設計ビギナーです。
相談に乗ってください。

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

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

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

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

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

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

**NAME IS NULL** · 04/10/18 01:10:05

合併した部署は、新しいIDを振ればいいのでは？

**NAME IS NULL** · 04/10/18 09:55:59

>>172
一般的な方法として、やるとしたら(2)だけど、本当にそこまでする必要が
あるのかどうかって所が一番大事だと思われ

**NAME IS NULL** · 04/10/18 16:18:02

先生
名前・メールアドレス・パスワード・他色々

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

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

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

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

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

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

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

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

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

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

(4)その他

**NAME IS NULL** · 04/10/18 16:19:18

(3)間違えたので修正
人
人id(主キー),名前,メールアドレス・パスワード,他色々

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

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

**175** · 04/10/18 16:19:55

すいませんがageさせて頂きます。

**NAME IS NULL** · 04/10/18 16:53:31

>>175
(4)

**NAME IS NULL** · 04/10/18 18:17:57

>>178
具体的にはどんな感じですか？

**NAME IS NULL** · 04/10/18 22:19:10

>>179
その前に他色々を具体的にしてくれ。

**NAME IS NULL** · 04/10/19 06:30:22

>172
所属履歴IDって必要か？
まあそれは良いとして、部署の統廃合を管理するだけなら部署expire期間を入れるのはどうか
実質173と同じ意見だけどIDは同じにできる
# 良いかどうかは別

**NAME IS NULL** · 04/10/19 08:44:54

>>175
要件次第でどれが適切かは変わってくると思われ。

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

**NAME IS NULL** · 04/10/25 23:05:28

すいません、ありきたりな質問なのですが、
データモデリングって何ですか？

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

**NAME IS NULL** · 04/10/26 00:49:47

>>183
データベースのテーブルとカラムを考える事。

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

**NAME IS NULL** · 04/10/26 01:10:00

まあアレだ。
顧客の業務を視姦して丸裸にしてヌードデッサンする行為の事。

**NAME IS NULL** · 04/10/26 01:25:51

おっ、かっこいいな。悪魔の辞典みたいだな。

**NAME IS NULL** · 04/10/26 14:10:28

>>185
わりと死姦だったりするがな。

**NAME IS NULL** · 04/10/26 17:08:53

なんだここは上手い事いうスレなのか。

**NAME IS NULL** · 04/10/27 00:51:41

ヌードだからといって素直に喜べない。
異様にデブだったり極端にガリガリだったり、それ以前に
奇形なモデルだったりする事がおおいからなｗ

**NAME IS NULL** · 04/10/27 15:12:50

きょうせらは人間じゃなくて単細胞生物らしいし。

**NAME IS NULL** · 04/11/18 19:46:59

ＥＲＷinのトライアル版の制約事項ってありますか？
作成出来るエンティティ数とか？

**NAME IS NULL** · 04/12/15 10:40:56

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 …;

**NAME IS NULL** · 04/12/15 10:41:12

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

**NAME IS NULL** · 04/12/25 22:54:27

もう解決したのかな？
いいクリスマスを迎えることができてるといいのだが。

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

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

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

**NAME IS NULL** · 04/12/27 18:29:20

レスありがとうございます。
（レスを頂けた事に、正直驚いています）

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

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

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

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

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

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

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

**NAME IS NULL** · 04/12/27 18:29:42

在庫受払いと変換済み出荷予定表を、
ユニオンクエリで結合しました。
これにさらに、
子部品があるかどうかの判定列 RESOLVABLE を
加えたものが、QRY_INV_IO_CALC_SOURCE です。

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

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

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

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

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

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

です。

**NAME IS NULL** · 04/12/27 18:45:20

ちなみに、出荷予定表からの製品出荷ですが、
製造にかかる日数をうまく格納・計算する方法が思いつかないので、
とりあえす展開１階層ごとに長めの標準日数を設定し、
部品展開時に、出荷予定日から遡った日に部品が出庫（消費）する、
というふうになるよう、受払い日時を設定しました。

**NAME IS NULL** · 04/12/27 19:19:44

すみません、
出荷予定表：100件強
（済のものを含めると7～800件）
でした。

**NAME IS NULL** · 05/01/14 00:57:27

>>195-198
これは SQL99の「再帰的SQL」を使う以外にないだろう．
http://www.atmarkit.co.jp/fnetwork/tokusyuu/01sql99/sql99_1b.html

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

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

**NAME IS NULL** · 05/01/17 11:13:03

>>199
レスありがとうございました。

**NAME IS NULL** · 05/01/18 01:25:16

>>195-198

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

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

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

**東浩紀** · 05/01/18 18:39:56

大きな物語が失墜し、人々はデータベース（大きな非物語）を消費するようになった
つまり人は物語に感動してるのではなくデータベースから抽出された物に反応しているにすぎない
つまり世界はこういう仕組みになってる

**NAME IS NULL** · 05/01/18 19:50:06

>>201
アドバイスありがとうございます。
実は、その本はたびたび読み返して手本にしています。
モデリング自体も問題大有りですが、
再帰ＳＱＬの代わりになるコーディングが思いつかない段階です。

**NAME IS NULL** · 05/01/20 03:13:45

>>203

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

**NAME IS NULL** · 05/01/20 22:59:44

>>203

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

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

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

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

**NAME IS NULL** · 05/01/20 23:01:36

【簡易ＭＲＰ（在庫推移のみを一括計算するシステム）】

モデル：
[部品] {部品Ｃ}、品名、現在庫数、製造ＬＴ、ＬＬＣ
[部品構成] {親部品Ｃ、子部品Ｃ}、員数
[日次受払] {部品Ｃ、日付}、入庫数、製造数、出庫数、在庫数

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

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

**NAME IS NULL** · 05/01/21 15:25:20

>>205
>>206
ありがとうございます！！
ＬＬＣの小さい順に展開することで、階層を最後まで展開しきることが出来るというわけですか！
目からうろこが落ちた思いです。
これから渡辺さんの本を再び読み返して理解していきたいと思います。

**NAME IS NULL** · 05/01/22 01:08:18

>>207

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

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

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

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

**NAME IS NULL** · 05/01/23 20:56:09

2項モデルに拘ってる方っていらっしゃいますか。

**NAME IS NULL** · 05/01/27 09:36:44

運送料と手数料を請求するとする。
この場合、運送料と手数料はテーブルを分けるべきか分けざるべきか。
どうですか皆さん？

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

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

**NAME IS NULL** · 05/01/27 12:29:02

[請求書] 請求ID・請求書ID
[請求顧客] 請求ID・顧客ID
[請求金額] 請求ID・金額
[運送料] 請求ID
[手数料] 請求ID
ならあるかな。

**NAME IS NULL** · 05/01/27 13:17:27

>>210
請求IDと運送料、手数料はそれぞれ一対一の関係なんでしょ?

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

**NAME IS NULL** · 05/01/27 13:22:42

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

**NAME IS NULL** · 05/01/27 13:39:52

大変だ。上のプログラムは最初のSubGoalでループして終了しない。
請求書発行(_顧客ID,_請求書ID)
　:-
　　請求書(_顧客ID,_請求書ID),
　<<以下略>>
にしないとね。

**210** · 05/01/27 14:41:00

すみません、請求における運送料と手数料は排他です。
請求が10件あったとして、運送料の請求が5件で手数料の
請求が5件かもしれないし、運送料の請求が10件で手数料の
請求が0件かもしれないといった感じです。

**NAME IS NULL** · 05/01/27 15:02:24

>>215
[請求]　請求ID・顧客ID・金額・運送料・手数料・合計金額
運送料・手数料どちらかをゼロにしとけばいいんじゃない。

**NAME IS NULL** · 05/01/27 18:01:12

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

**NAME IS NULL** · 05/01/28 00:09:12

>>217
　prologなんてまだ生きてたのか。うざいね

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

　電波受けてる？

**NAME IS NULL** · 05/01/28 03:58:05

[発注見出]と[発注明細]があって、それに対応する[支払予定]があります。
[支払予定]は、見出単位で決定する場合と、明細単位で決定する場合の
２通りあるんですが、この場合のテーブル設計はどうすればよいだろう？

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

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

**NAME IS NULL** · 05/01/28 07:49:44

>>219
発注と支払いの間に、債務とかなんかのテーブルを一つはさんだらどうかな？