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

**NAME IS NULL** · 04/01/22 19:44

>>98

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

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

04/01/25 23:31

　渡辺幸三ってひとの本がすごいっておもうんですがどう？

**NAME IS NULL** · 04/01/27 11:18

ウルトラマンとガンダムどっちが強いかって喧嘩してる子供と同じだな

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

**NAME IS NULL** · 04/01/27 23:50

>>102
探しているのは銀の弾ではなくガンド・ロアクラスの兵器かと。

**NAME IS NULL** · 04/01/31 03:52

DBDesigner使ってる人少ないのか？オープンソースの良ツール
なんだが。
http://fabforce.net/dbdesigner4/

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

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

**NAME IS NULL** · 04/01/31 04:51

日本語使いたきゃ別のツール使うんじゃない？
SIとかさ。

04/02/12 22:56

シンプルな商品マスタはこんなのでしょう

〔商品Ｍ〕　　　商品Ｃ　　販売単価　　仕入単価
　　　　　　　　　~~~~~~
　　　　　　　　　ABC　　　　\300　　　　　\200

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

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

－－－－－－－－－－－－－

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

**NAME IS NULL** · 04/02/13 00:00

まずは、なぜ徹夜作業が必要なのか考えてみ。

**NAME IS NULL** · 04/02/13 17:07

>>106
長年の疑問だが、商品マスタの単価の扱いは、どうするのがベストなのだろう。

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

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

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

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

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

>この場合、適用年月日の判断が入るため、SQL一発で単価を取得できない。

なんで？

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

>>108
>厳密に正規化すれば、単価は、商品マスタとは別に、
>商品単価マスタ｛商品コード、適用年月日、単価｝を作ることになるけど、

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

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

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

**108** · 04/02/14 00:32

>>109
え、できるの？
できるなら、ぜひそのSQLを教えて欲しい。

>>110

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

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

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

**NAME IS NULL** · 04/02/14 09:17

>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.適用年月日
)

**108** · 04/02/14 16:02

>>112
Thanks！！！

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

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

**108** · 04/02/14 16:51

直積表を書いてみて、やっと理解できた。

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

重ね重ねThanks>>112

**NAME IS NULL** · 04/02/15 00:59

>>111
>「eventの定義は、「DATE」が帰属するentityである、とする。」だそうだ。

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

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

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

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

**NAME IS NULL** · 04/02/15 22:14

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

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

**NAME IS NULL** · 04/02/15 22:58

>>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 が使える。

**NAME IS NULL** · 04/02/16 00:35

>>101
どのへんが？

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

>>117
1票

04/02/17 00:22

>>117
> >>112
> こっちのほうがシンプルでよさそうな気がするけど、、、ダメ？

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

**NAME IS NULL** · 04/02/21 02:48

　ＴＨ法ってのを聞いたのですが、
メリット・デメリットとかご存知ですか？

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

**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
発注と支払いの間に、債務とかなんかのテーブルを一つはさんだらどうかな？

**NAME IS NULL** · 05/01/28 09:13:10

>>219
[発注見出].支払予定NO≠[発注明細].支払予定NOの場合があるから、
[発注見出] は発注NOだけでいいんじゃない。

**NAME IS NULL** · 05/01/28 13:18:05

>>220
債務を挟むって具体的にどんな感じになるんでしょう？

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

**NAME IS NULL** · 05/01/28 18:13:41

[仕入見出し]+---≡[仕入明細]

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

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

[支払見出し]+---≡[支払明細]+--･+[仕入明細]　（ここ自信無し）

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

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

**NAME IS NULL** · 05/01/29 03:03:56

>>219

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

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

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

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

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

**NAME IS NULL** · 05/02/01 11:58:45

>>ときどき Prolog の話を書いてる人

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

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

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

**NAME IS NULL** · 05/02/02 23:11:26

>>201

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

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

**NAME IS NULL** · 05/02/03 01:17:55

>>226
本当に凄いフリーソフトですね。open sourceにして英訳すれば世界中の人が使いそう。

**NAME IS NULL** · 05/02/03 02:51:03

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

**NAME IS NULL** · 05/02/03 20:15:41

>>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/

**NAME IS NULL** · 05/02/03 20:34:28

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

**NAME IS NULL** · 05/02/04 00:35:00

>>230
　そのままの意味

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

**NAME IS NULL** · 05/02/04 11:35:10

なんか、こわい。

**NAME IS NULL** · 05/02/04 16:56:20

>>231
なんか表現がいちいちドラスティックだなあ。

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

**NAME IS NULL** · 05/02/04 19:45:38

[部門]＋───≡[部門-従業員_対応表（日時を入れて「配属」）]≡───＋[従業員]
のようなことが書いてあったような気がします。

**NAME IS NULL** · 05/02/05 01:48:17

>>233
　Ｔ字形を単なるデータモデリング手法だと思うと
火傷をします。これは哲学です。

　ビジネスを定義するにあたって
１．企業として共通の認識にあるものは何か？
　→番号がついているもの＝識別子
　　（それがユニークかは関係ない＝＞複合キー）

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

３．エンティティ間の関係（４つのルール）

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

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

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

**NAME IS NULL** · 05/02/07 18:37:02

XEADはJava1.4.2が要るみたいですね…

**NAME IS NULL** · 05/02/07 22:26:05

>>236
1.4.1_03でも漏れは動いたよ
まあ全部の機能を試したわけじゃないが

**NAME IS NULL** · 05/02/25 17:14:43

こんなとこ見つけました。

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

**NAME IS NULL** · 05/02/25 21:12:10

俺ERスタディオ使ってる

**NAME IS NULL** · 05/03/01 17:08:53

ある機械が、機種ごとに仕様の項目数が違うとして、
これらをサブタイプとして登録したとき、実装上はどう処理するのでしょうか？

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

機種Ａ
　ノズル１からジュースが出せます。　原液タンクには４／10㍑タンクが使えますがボトルは使えません。
　ノズル２からジュースが出せます。　原液タンクには1.8／４㍑ボトルが使えますがタンクは使えません。
　ノズル３からは水だけが出せます

機種Ｂ
　ノズル１からジュースが出せます。　原液タンクには４／10㍑タンクが使えますがボトルは使えません。
　ノズル２からジュースが出せます。　原液タンクには４／10㍑タンクが使えますがボトルは使えません。
　ノズル３からジュースが出せます。　原液タンクには1.8／４㍑ボトルが使えますがタンクは使えません。
　ノズル４からは水だけが出せます
オプションとしてOPT1,OPT2,OPT3が付加できます。（重複可）

機種Ｃ
　ノズル１からジュースが出せます。　原液タンクには４／10㍑タンクが使えますがボトルは使えません。
　ノズル２からジュースが出せます。　原液タンクには1.8／４㍑ボトルが使えますがタンクは使えません。
　ノズル３からジュースが出せます。　原液タンクには1.8／４㍑ボトルが使えますがタンクは使えません。
　水は基本的に出せませんが、機種に関係なく使用できるオプション機材Ｗを付加することにより水も出せます。
オプションとしてOPT1,OPT2,OPT3が付加できます。（２つまで重複可能、３つ重複不可）

ジュースＸ１～Ｘ９の原液は４㍑ボトルと10㍑タンクのどちらかが選べます。
ジュースＹ１～Ｙ９の原液は1.8㍑ボトルと４㍑タンクのどちらかが選べます。

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

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

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

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

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

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

**NAME IS NULL** · 05/03/01 17:09:58

（１）
機種の仕様マスタとしては、

┌　＋[機種基本仕様]　（スーパータイプ）
│
├・＋[機種Ａ特有仕様]（サブタイプ）
│
├・＋[機種Ｂ特有仕様]（サブタイプ）
│
└・＋[機種Ｃ特有仕様]（サブタイプ）

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

（２）
出荷先と工事と機番との関係は、

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

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

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

**NAME IS NULL** · 05/03/02 00:08:35

>>240

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

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

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

こんな感じ？

**NAME IS NULL** · 05/03/02 18:18:10

>>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、・・・
　　　　　　　　　　￣￣￣￣￣￣￣￣￣
ノズル数やその他の制限は、判断材料となるデータを保存しておくまでにとどめ、
実際の判断はデータベースの制約ではなくアプリケーションが都度判断する、
というのが正解になるんでしょうか…。

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

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

**NAME IS NULL** · 05/03/02 19:55:10

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

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

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

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

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

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

長文ｽﾏｿ

**NAME IS NULL** · 05/03/03 01:27:26

年月日は、date型使いますが、年月ってどうしてますか？
char(6) にしますか？それとも date型で、必ず１日とかにします？

**NAME IS NULL** · 05/03/03 01:46:48

高橋友城　は　殺された

**NAME IS NULL** · 05/03/03 18:17:51

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

**NAME IS NULL** · 05/03/03 21:41:11

>244
ありがとうございます。
頂いたアドバイスを元にただいま苦悩中。
何か形になったら報告に参ります～

**NAME IS NULL** · 05/03/03 22:21:33

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

**NAME IS NULL** · 05/03/04 13:05:47

>>241
> 上に紹介のあった本にも、
> 似たケースのモデル例は見つかりませんでした。

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

**NAME IS NULL** · 05/03/04 14:54:04

>>250
ありがとうございます。

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

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

機種ﾌｨｰﾁｬｺｰﾄﾞ　ﾌｨｰﾁｬ明細　　　　　　　　　　　　　　　ﾌｨｰﾁｬ別ｵﾌﾟｼｮﾝ明細
　　　　　　　　　　　ﾌｨｰﾁｬ行No.　桁数　ﾌｨｰﾁｬ名　　　　ｵﾌﾟｼｮﾝC　ｵﾌﾟｼｮﾝ名
-----------------------------------------------------------------------
LP-100　　　　　　1 　　　　　　　　２　　　ノズル１液種　X1　　　　ジュースX1
.　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 X5　　　　ジュースX5
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・　　　　　・
.　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 Y8　　　　ジュースY8
　　　　　　　　　　　2 　　　　　　　　３　　ノズル１容器　.T04 　　 .タンク４㍑
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 .T10 　　 .タンク10㍑
　　　　　　　　　　　・　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　・　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　・　　　　　　　　　　　　　　　　　　　　　・　　　　　・
.　　　　　　　　　　 8 　　　　　　　　２　　ノズル４液種　 X1　　　　ジュースX1
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 .X5　　　　ジュースX5
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 .Y8　　　　ジュースY8
　　　　　　　　　　 9 　　　　　　　　３　　ノズル４容器　 .T04 　　　タンク４㍑
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　. T10 　　　タンク10㍑
　　　　　　　　　　 10　　　　　　　. ３　　オプションA　　 OPT1　　 .オプション１
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 .OPT2　　オプション２
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 .OPT3　　オプション３
　　　　　　　　　　 11　　　　　　　 .３　　オプションB　　 OPT1　　 .オプション１
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 .OPT2　　オプション２
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 .OPT3　　オプション３
　　　　　　　　　　 12　　　　　　　 .２　　左正面ﾊﾟﾈﾙ色　BL　　　　.青
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　. BK　　　　黒
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　. RD　　　　赤
　　　　　　　　　　　・　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　・　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　・　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　 18　　　　　　　 .４　　中央受皿種類　SUS0　　.ステンレス
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　.PLBK　　プラスチック黒
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　.PLWH　　.プラスチック白
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　.NA00　　なし

機種基本属性
機種C　　　　機種名　・・・　機種ﾌｨｰﾁｬC
----------------------------------------
LP-100　　　 LP-100　　　　　LP-100

派生機種明細
機種C　　　　ﾌｨｰﾁｬｵﾌﾟｼｮﾝC
-----------------------------------------------------------
LP-100　　　 X1T04X5T04X6T10Y8T10OPT2OPT3BKXXYYZZQQQGGSUS0

**NAME IS NULL** · 05/03/04 15:38:54

上で、引用元と違ってﾌｨｰﾁｬ体系という体系をとらなかったのは、
今回のケースでは、
複数の機種が全く同じﾌｨｰﾁｬｰ体系をとることはまれであるためです。

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

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

**NAME IS NULL** · 05/03/04 15:47:29

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

**NAME IS NULL** · 05/03/04 19:24:44

難しい・・・。
やはり、最終段のこれかなぁ
ttp://www.jsys-products.com/iwaken/data_model_patterns/lower.html#13

モノ（クラス）→機種、アジャスタ、ジュース、ボトル、ノズル
モノ（インスタンス）→機種Ａ、高さ調節式アジャスタ、オレンジジュース
関係
　機種Ａ－ノズルＡ(可能)
　機種Ａ－ノズルＢ(ダメ)
　ノズルＡ－ボトルＸＸ
　ノズルＡ－ボトルＹＹ
　機種Ａ－高さ調節式アジャスタ(ダメ、高さが合わないから)
関係タイプ
　取り付ノズル
　接続アジャスタ
属性
　サイズ
　容量
　高さ
属性割り当て
　ボトル－容量
　ボトル－サイズ
変数
　４㍑
　１０㍑

なかんじ。

**NAME IS NULL** · 05/03/04 19:41:13

>>254
うわ、改めてみるとすごいモデルですね、これ…
週末使って考えてみます。　ありがとうございます。

05/03/04 23:18:03

>>255

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

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

**NAME IS NULL** · 05/03/13 14:37:10

>>256
とりあえず入会してみましたがメーリングリスト届きません…

（´・ω・｀）

（´・ω:;.:...

（´:;....::;.:. :::;.. .....

**NAME IS NULL** · 05/03/15 02:51:06

>>257
来ましたがな

**NAME IS NULL** · 05/03/18 09:42:19

有名本の著者らしき方や、その筋の本職の方などが発言してますね…

**NAME IS NULL** · 05/03/19 22:52:31

>>259

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

**NAME IS NULL** · 05/03/20 00:10:27

「オブジェクト指向の幻想について」で盛り上がってます。

**NAME IS NULL** · 2005/04/12(火) 15:08:28

現在使用しているデータモデルの表記法の投票

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

**NAME IS NULL** · 2005/04/16(土) 17:28:01

今投票サイトを作っているのですが、データモデリングで迷っています。
DBには各ユーザー名と回答を格納します。
回答の値はintの0～10ぐらい（選択肢の数だけ）と予想され、
設問の数はどんどん増えていくことが予想されます。

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

A)設問ごとにフィールドを作る。
回答１　回答２　回答３　・・・
０　　　１　　　５　　　・・・

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

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

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

**NAME IS NULL** · 2005/04/16(土) 18:41:34

何で各回答ごとにレコードを持つという発想にならない？

**NAME IS NULL** · NG

>>263
ユーザID、設問ID、回答　をフィールドに持つテーブルを作ればいい。

**NAME IS NULL** · 2005/04/16(土) 21:46:23

あーわかった！
264さん265さんありがとう。

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

**NAME IS NULL** · 2005/04/17(日) 00:33:06

kaba@prolog.com,設問1,2
kaba@prolog.com,設問2,1
kaba@prolog.com,設問3,1

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

**NAME IS NULL** · 2005/04/17(日) 01:09:06

いや、ユーザー情報テーブルとは別に投票結果テーブルを作りますので、
主キーは前者だけに設定するつもりです。

こんな感じ

ユーザー情報テーブル
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

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

**263** · 2005/04/19(火) 11:14:49

みなさん、ありがとうございました。
おかげで投票サイトが完成しました。
http://www.kiminari.info/kokumin/

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

**NAME IS NULL** · 2005/04/19(火) 11:57:10

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

**NAME IS NULL** · 2005/04/19(火) 19:34:30

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

**271** · 2005/04/19(火) 20:00:55

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

**NAME IS NULL** · 2005/04/19(火) 21:17:19

ER図から3NFまで自動変換するソフトウェアを探しています

**NAME IS NULL** · 2005/04/20(水) 02:54:10

>270
いえいえ、違いますよ。
001は絶対に1レコードのままです。
変更情報は、
①「メールアドレス変更履歴エンティティ」を抽出する
②「変更前メールアドレス」項目を追加する
あたりで表現します。
純粋なデータモデルとしては①が正解とされますが
業務要件が「直近1世代の変更前アドレスだけの保持でよい」などであれば
②も現実的です。

**NAME IS NULL** · 2005/04/20(水) 06:50:59

メールアドレスを外部キーにもつ列全部に UPDATE CASCADE をつけれ

**NAME IS NULL** · 2005/04/20(水) 06:53:21

メールアドレスを外部キーにもつ列全部に UPDATE CASCADE をつけれ。

**NAME IS NULL** · 2005/04/20(水) 08:24:29

>>273 ①が正解ですね。無理に>>268の枠組の中で解を求めたのが
いけなかった。

**NAME IS NULL** · 2005/05/25(水) 01:18:49

個人や組織や会社もろもろに
「パーティ」ってスーパーセット設けるのって実際どうなんでしょう。
よくやるのでしょうか?

**NAME IS NULL** · 2005/05/28(土) 23:14:32

コードに意味（何桁目が年式をあらわすなど）を持たせないで
全くの連番だと、コードを見ただけでは全然類推ができないし
使いにくいと思うのですが、コードに意味を持たせないメリットは何。
コードに意味を持たせても、切り出して判断に使わなければＯＫ？
連番は採番しやすくていいのだけれど。両方満足させる方法があれば。

**NAME IS NULL** · 2005/05/29(日) 09:41:43

ただの連番ならDBMSが勝手に作ってくれるからラクじゃん。

**NAME IS NULL** · 2005/06/01(水) 01:20:28

>>279
伝票番号だって、車のナンバーだって、出席番号だって、電話番号だって、意味を持たないだろ。
(言葉遊びの語呂合わせなどは別として)

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

**NAME IS NULL** · 2005/06/01(水) 11:04:24

>>281
電話番号は意味あるよ。
地域コード - 連番
じゃん。
伝票番号も会社によって
YYYYMMDDXXXXX
とか当たり前にある。

**NAME IS NULL** · 2005/06/01(水) 16:46:09

>>282は世の中の仕組みがわかってない

**NAME IS NULL** · 2005/06/01(水) 18:37:20

シデー世ですこと

**NAME IS NULL** · 2005/06/01(水) 19:01:57

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

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

**NAME IS NULL** · 2005/06/03(金) 12:15:18

性別コードは0が女で1が男だよな！

**NAME IS NULL** · 2005/06/03(金) 12:19:30

象形文字ですか？

**NAME IS NULL** · 2005/06/03(金) 16:02:04

性器化

**NAME IS NULL** · 2005/06/03(金) 16:04:13

自己記述的なコードとゆーやつかしら

**NAME IS NULL** · 2005/06/03(金) 19:24:36

>>278
＞「パーティ」ってスーパーセット設けるのって実際どうなんでしょう。

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

**NAME IS NULL** · 2005/06/05(日) 12:42:42

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

**NAME IS NULL** · 2005/06/06(月) 10:19:45

>>291
そういや転校生って、後ろにpushだったなあ・・・。
なんか懐かしくて胸キュンだ。

**NAME IS NULL** · 2005/06/06(月) 14:46:53

>>292
俺の学校では違ったなぁ・・・

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

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

**NAME IS NULL** · 2005/06/06(月) 15:07:48

>>293
健康カードとか、下駄箱とか、出席番号を記入して1年間使う物があるのに、
えらく不便なシステムだな。

**NAME IS NULL** · 2005/06/06(月) 15:07:54

えー！都度再ソートもびっくりだが、生年月日順ってのは凄いなー。

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

**NAME IS NULL** · 2005/06/06(月) 15:13:06

つまりだ、実際の業務では
>293のような事態がままあるので
識別子と業務上使われる出席番号などは
別に構えるのが吉って事ですね。

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

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

**296** · 2005/06/06(月) 15:24:04

とか書いてたら、そもそも発端の
ちゃんと>279へのレスになったな。

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

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

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

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

**NAME IS NULL** · 2005/06/06(月) 21:59:03

>>297
ほかのテーブルから外部キーとして参照する場合は
ID？出席番号？

**NAME IS NULL** · 2005/06/06(月) 23:26:34

>293は
出席番号は出欠名簿リストの左端についてる番号ぐらいの利用しかなくて、
いつもは学籍番号ばっかり使ってるってことはないのか。