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

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

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

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

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

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

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

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

テーブル定義のフォーマルな表記方法はわからないのですが、
部品とその構成情報は、
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　┏━━━━━┓　 ┏━━━━━━━━┓　　　　　　　　　　
　┃部品　　　　 ┃　 ┃品目- 品目_ 再帰 ┃ 　 ┏━━━━━┓　
　┃----------┃　 ┃----------------┃ 　 ┃部品_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で管理 ）
を、アクセスクエリを数段かませ、
列が在庫受払いと同じになるように変換しました。

在庫受払いと変換済み出荷予定表を、
ユニオンクエリで結合しました。
これにさらに、
子部品があるかどうかの判定列 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件

です。

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

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

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

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

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

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

>>195-198

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

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

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

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

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

>>203

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

>>203

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

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

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

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

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

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

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

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

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

>>207

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　電波受けてる？

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

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

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

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

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

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

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

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

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

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


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


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

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

>>219

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

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

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

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

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

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

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

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

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

>>201

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

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

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

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

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

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

>>230
　そのままの意味

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

なんか、こわい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

俺ERスタディオ使ってる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

>>240

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

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

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

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

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

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

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

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

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

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

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

長文ｽﾏｿ

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

高橋友城　は　殺された

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

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

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

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

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

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

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

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

機種ﾌｨｰﾁｬｺｰﾄﾞ　 ﾌｨｰﾁｬ明細　　　　　　　　　　　　　　　ﾌｨｰﾁｬ別ｵﾌﾟｼｮﾝ明細
　　　　　　　　　　　ﾌｨｰﾁｬ行No.　桁数　ﾌｨｰﾁｬ名　　　　ｵﾌﾟｼｮﾝC　 ｵﾌﾟｼｮﾝ名
-----------------------------------------------------------------------
LP-100　　　　　　1 　　　　　　　　２　　　ノズル１液種　X1　　　　ジュースX1
.　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 X5　　　　ジュースX5
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・　　　　　・
.　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 Y8　　　　ジュースY8
　　　　　　　　　　　2 　　　　　　　　３　　 ノズル１容器　.T04 　　 .タンク４�g
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 .T10 　　 .タンク10�g
　　　　　　　　　　　・　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　・　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　・　　　　　　　　　　　　　　　　　　　　　・　　　　　・
.　　　　　　　　　　 8 　　　　　　　　２　　 ノズル４液種　 X1　　　　ジュースX1
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 .X5　　　　ジュースX5
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・　　　　　・
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 .Y8　　　　ジュースY8
　　　　　　　　　　 9 　　　　　　　　３　　 ノズル４容器　 .T04 　　　タンク４�g
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　. T10 　　　タンク10�g
　　　　　　　　　　 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

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

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

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

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

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

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

なかんじ。

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

>>255

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

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

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

（´・ω・｀）

（´・ω:;.:...

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

>>257
来ましたがな

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

>>259

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[email protected],設問1,2
[email protected],設問2,1
[email protected],設問3,1

とかなりますが、[email protected]のユーザーIDを主キーにするので
よいとお考えですか。

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

こんな感じ

ユーザー情報テーブル
ID（主キー）メルアド パスワード他
001 [email protected] pass1
002 [email protected] pass2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

シデー世ですこと

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

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

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

象形文字ですか？

性器化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>生年月日順

千葉？

>>298
IDじゃないと、297で言ってるメリットが得られないです。
途中で転校生の分、出席番号振りなおしても
下駄箱テーブルはID参照してれば影響なし。

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

最初から出席番号を 10, 20, 30 と、10おきにつけておけばいい。
転校生が来たら 25 などを割り振ればいいだけだ。

　 　 　 ＼∧＿ﾍ　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　,,､,､,,,　/ ＼〇ノゝ∩ ＜　転入合戦、いくぞｺﾞﾙｧ！！　
　　　　/三√ ´∀｀)　/　 ＼＿＿＿＿＿＿＿＿＿＿＿＿　　,,､,､,,,
　　 　　/三/| ﾟＵﾟ|＼　　　　　　,,､,､,,,　　　　　　　　　　　　　　　　　　　　　　　,,､,､,,,
　,,､,､,,,　Ｕ （:::::::::::）　　,,､,､,,,＼ﾜｼｮｰｲ！！／　＼ﾜｼｮｰｲ！！／ 　＼ﾜｯｼｮｰｲ！！／
　　 　 　//三/|三|＼　　　　　／■＼／■＼ ／■＼　／■＼　 ／■＼　／■＼
　　　　　　∪　 ∪　　　　　　 （ ´∀｀　）´∀｀　）´∀｀　） ´∀｀　 （ ´∀｀　） ´∀｀　）
　,,､,､,,,　　　　　　　,,､,､,,,　　／■＼／■＼ ／■＼　／■＼　 ／■＼　／■＼
　　　　　　,,､,､,,,　　　　　　 （ ´∀｀　）´∀｀　）´∀｀　） ´∀｀　 （ ´∀｀　） ´∀｀　）
　　　　　　　　　　　　　（(　（つ　　ノ（つ　丿（つ　　つ（つ　　ノ（つ　　丿（つ　　つ
　　　　　　　　　　　　　　　 ヽ　 （　ﾉ（　ヽノ　）　）　） ヽ　 （　ﾉ （　ヽノ　　 ）　）　）
　　　　　　　　　　　　　　　（＿）し'　し（＿） （＿）＿）（＿）し'　し（＿） 　 （＿）＿）

昔のBASICの行番号かいｗ

なつかしいね！
と思ったけど、表示順みたいなカラムでは
今もやってるなー。

>>303
来るのは9人までにしてね

年度中に学区内に団地できたら終わりだな。

総数より同じ隙間に集中した時がまずいのでは…

　　　　　　　／￣￣￣￣￣￣￣￣
　　　　　　　|　転校生の織田です
　　　　　　　＼
　　　　　　　　 ￣∨￣￣￣￣￣￣
　　　　　　　　　　　　　 　　　　　∧＿∧ 　　　　　／￣￣￣￣￣￣￣
　　　　　　　　　∧＿∧　　　　 （ ´Д｀ ） 　　　＜　 　小田です
　　　　　　　　 （ ´Д｀ ） 　 ／⌒　　　　⌒ヽ 　　 ＼＿＿＿＿＿＿＿
　　　　　　　　／,　　/ 　 ／_／|　　　　　へ　＼
　　　　　　　(ぃ９　　| 　（ぃ９ ./　　　　/　　 ＼ ＼.∧＿∧　 ／￣￣￣￣￣￣￣
　　　　　 　 /　　　 /、 　　　/　　　 ./　 　　　ヽ　（ ´Д｀ ）＜　 尾田です
　　　　　　 /　　　∧_二つ （　　　　/　　　　　　∪ ,　　/　　　＼＿＿＿＿＿＿＿
　　　　 　 /　　　/ 　　　　　＼　.＼＼　　　　　(ぃ９　　|
　　　　　 /　　　 ＼ 　　 　　　＼　.＼＼　　　 /　　　 /　　,、　　 　（（（　））） 　／￣￣￣￣￣￣￣
　　　　　/　 /~＼　＼ 　 　　　　 >　 ）　）　　./　　　∧_二∃ 　　　（ ´Д｀ ） ＜　緒多です
　　　　 /　 /　　　>　 ） 　 　　 /　／／　　 ./　　　　￣￣　ヽ　 　 (ぃ９　　）　　＼＿＿＿＿＿＿＿
　　　／　ノ　 　 /　／ 　　 　 /　/ /　　.＿/　 /~￣￣/　／　　　/　 　 ∧つ
　　/　／ 　 .　 / ./.　　 　　 /　/ /　)⌒ ＿ ノ　　 　 / ./　　　　/　　　 ＼　　 (ﾟдﾟ)ｵﾀﾞﾃﾞｽ
　 / ./　　　　 （　ヽ､　 　　 （　ヽ ヽ　|　/　　　　　　 （　ヽ､ 　　/　/⌒>　 ）　　ﾟ(　 )−
（　 _)　　　　　 ＼__つ　　　 ＼__つ).し 　　　 　　　　 ＼__つ　（＿)　 ＼_つ　　 /　>

意味なし連番IDと認識容易番号の2本立てでいくのがベストと考えて
いいでしょうか。この方法の問題点注意点が何かあれば。

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

>>309
随分前のWEB+DBプレスのデータモデリングの記事に
にそこらへんの事がかいてあった。
今なら全部のバックナンバーのPDFが売ってるから
読んでみるといいよ。面白かった。

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

>>308
べつに？

310の続き

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

>>310
WEB+DB PRESS特別総集編ってやつですね。
読んでみます。

>>302

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

>>310

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

>>314
勿論、学籍番号は見やすいほうがいいでしょう。
ただ、学籍番号ってのは業務で用いるコード、
特定のデータへのアクセスパスな訳です。

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

WEB+DB PRESS特別総集編みました。
関係箇所がVol.11とVol.21に出てました。
どちらも著者は羽生彰洋さん。

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

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

>>316
俺も意味無しID、使ってはいたし
コードの洗替が楽ってのも判ってたけど
どうしても違和感があって、
それ読んで、識別子とアクセスパスって言い方で
すっきりしました。

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

age

>>316
このスレみてWEB+DB PRESS特別総集編買ってきてました。
なるほどなぁ〜と読みすすめてたのですが、一つ疑問が。

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

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

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

>>319
ここで聞いてみよう
http://d.hatena.ne.jp/habuakihiro/

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

>>320
サイト紹介してくれてありがとう。

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

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

>>321
いえいえどういたしまして。
なんか偶然だけど、凄いタイミングよかったね。

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

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

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

自分ルールなんだから、自分で決めろよそれぐらい。
そもそもサフックスにするところから議論になるぞ。

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

>>324
議論ではなく、同様ので命名規則を適用している方で
サフィックスだけでもどうやってるのかと意見をもらいたくて・・・。
何にせよ、スレ汚しごめ。

Crsってサフィックスを見た事があるよ。
設計・命名者はメインフレーム出身の割と古い人。

>>326
貴重な情報、ありがとうございます。
早速、関係するテーブル名を連結+CRSで命名したいと思います。

でも英語としてあってるかどうか知らんよ。
あとで保守する人にだせーとか言われるかもよ。

データウェアハウスの論理設計に関していい書籍やネット上の情報があったら教えてください。

>>323
相互参照の略ならXREFなんてどうだろう。

>>330
あんた、センス良いね。

>>330
m:m確定ならそれいいね！
1:m, m:1かm:mのどちらかわからないときは"REF"だけでもよさそうだね。

>>329
DWHは書籍とかネットとかの情報は少ないよ。

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

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

>>329
Ｍ＄のＳＱＬ鯖に付いてる。
使ってみると分かるとおもうし、
ＭＳＤＮにも資料落ちてるんじゃないかな。

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

アドバイスお願いします。

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

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

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

なぜ２に数量があって３には無いんです？

標準単価は例外なく全ての商品に入りません？
商品テーブルに単位（１：個　２：kg　３：cm^3　など）が入ってれば・・・

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

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

>>336
>なぜ２に数量があって３には無いんです？
申し訳ありません。私のミスです。
仰るとおり３は数量x縦x横x奥行xサイズ当りの単価=金額となります。

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

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

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

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

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

>>337
数量もCurrencyで問題ないかと思いますが・・・
浮動小数点じゃ誤差が出てしまうのではないかと

>>338
>数量もCurrencyで問題ないかと思いますが・・・
>浮動小数点じゃ誤差が出てしまうのではないかと
商品のテーブルには数量は含めない予定です。
数量はあくまで伝票入力時に入力するものとし、標準では常に１とするからです。

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

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

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

だれが数量を商品マスタに入れようと思うかよ
複数の重量にしてもそんなこと聞いてないと思うが

>>337
> 汎用性を考えFloatやDouble等で定義すれば解決
> 重量に関しては、2kg,5kg等というような複数の重量は無いとのことです
>>339
> 商品のテーブルには数量は含めない予定です。
> 数量はあくまで伝票入力時に入力するものとし、標準では常に１とするからです

　重量
　縦
　横
　奥行

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

洗剤10ｋｇタンクを10本
洗剤500gビンを200本
洗剤50kg特大タンクを2個
コレが同じ値段。
じゃあ重量73gと指定して1370本下さいと言ったら
計量してビンに入れて同じ値段で売ってくれる？

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

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

>>335
これはRDBMS(ER図)の限界として、とてもよく出てくる典型的な問題ではないかな？
商品をオブジェクトとして保存できるのであれば、
商品基礎クラスを継承した３つの商品クラスを別途用意してしまえばいい。

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

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

>>344
自分は商品基礎情報テーブルと個別商品テーブル×３を作ることが多いけど。

>>344
10個くらいが境界かな。
さすがにsubclass tableを100個tableを作る気はしない。

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

ORACLE Designer vs ERwin
比較したメリットデメリットをあげてください。
使用するデータベースはOracle 10g

両方使い込んでる奴なんて居ない。

>>344
この問題、そもそもの現実のものを、どのように扱ってるかが主眼だと思う。
その３つの商品群が混在して扱われているのであれば、テーブルは１つ。
部署違いでまったく別の群をたまたま同じように扱っているのであればテーブル３つ。
データベースってのはあくまで現実の記録だから、そこを主眼にすることは大事だと思う。

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

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

>>349
>>346も言ってるが、もし3個でなくて100個だったら？

商品マスタ・部品マスタはあくまで一元化しないとヤバいとおもうが…
縦横高さなんて仕様情報を、基本マスタに、要素ごとに列を与えて載せるべきなのか？

DB設計の場合、パフォーマンス用件がどうしたって重要になってくるからね。
多少汚くても一個のテーブルで収まってくれると嬉しい

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

分けるといってもサブセットですよね？

範囲が断続していて、なおかつ重複しないデータは、
どのようにモデリングしたらよいのでしょうか？

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

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

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

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

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

ID,材質,最小値,最大値
プライマリキーはID
Uniqueキーは材質,最小値,最大値でいいんじゃない？
順序が必要なら各材質毎にNo.振って材質,No.にUniqueキーを設定するとか。

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

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

外してたらすまそ。

>>356
お回答ありがとうございます。

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

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

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

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

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

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

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

>>357
構造は>>356のような感じで作る。
その後制約したいテーブルをビューでラップ。
追加、更新時にトリガーをかませ、制約テーブルを読み取り違反していれば
クライアントに例外を投げる。

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

テーブル制約では不可能でしょ。
358さんのいうように、アプリ（ストアド・トリガー）の範疇だと思います。

参考になりました。ありがとうございます。

日付のついた取引の表示順序を、その日の中で任意に設定したいのですが、
定石的な方法をご教示ください。

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

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

追記式で追加しながら順序も決めるならば、普通にリスト構造にすればいいんじゃないの？
又は、順序カラムを数値で持っておいて、差し込み先より大きい列に対して、＋１するUPDATEで割り込み完了。

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

販売管理の売上データなどで売上伝票番号がキーとなる
データがあるのですが、この番号は意味のない連番なんですが
(但し、その番号を入力して該当すれば売上伝票を表示します。)
別途、意味なしキーを追加したほうがいいのでしょうか？

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

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

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

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

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

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

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

>>364
webアプリなどでは有効ということですね。

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

>>316
このへん読んでみなはい。

つか、マスタのキーってのはそういう変更が起きないように慎重に設計するんだよ。
コード体系とか適当に作って、後で泣きを見るってのはよくある話だ

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

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

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

そしていつのまにか原型をとどめないほどのカスタマイズの嵐で
結局イチから作ったほうがよかったんじゃねーかという罠。l

カスタマイズはあんまりせずに、汎用性の枠の中で解決した方が生産性は上がると思うけどね。
顧客のビジネスルールごとに似たような設計を繰り返すのは無駄だと思う。

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

まぁ、そういうのは何度も試みられているがな。
カスタマイズが減ると仕事も減りそうw

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

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

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

日本の場合は、役所納入用の標準仕様をJISで定義してくれれば普及しそうな気がする。

本屋でひととおり見て来たが、いまいちこれだって本には巡り会えなかった。orz

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

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

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

ODBC用,Oracle用,SQLServer用の3種類のDDLがあるので、
そのDDLを使用してDBを作成し、ERWinやSIObjectBrowserERの体験版などで
ER図をリバース作成すれば、リレーションもきれいに描画されると思う。
論理モデル用ってのでは全部で501個のテーブルが作成される。
Oracle用のDDLを試してみたところうまく行った(Oracle817)。
ODBCとSQLServerは試してない。

おまいがその経験を元にもっと分かりやすく書いた物を出版すると良書に成る悪寒。
暇ならがんがれ。

>>376
俺もタネ本として買ったよ。
読むたびに、なにがしかを得られる本だよな。

:378 s/なにがしか/なにかしら/

すいません、DBDesigner4を使用してMySQLからER図をリバースしようと思っているのですが、
localhostのMySQL4.1.13に接続しようとすると

dbExpress Error: Invalid Username/Password

というダイアログが出てしまい接続できません。
どなたかこの現象の回避方法をご存知の方いたら教えて下さい。
お願いします。

>>380
ヒント:英語の辞書

>>381
ダイアログの内容を読め、といった意味であればそれくらいはさすがに分かっています。＾＾；
UsernameもPasswordも一致しているのにこのメッセージが出ているから困っているのですが・・・。
root以外のユーザもいくつか作成して試しましたが同じでした。

それとも海外にこの現象について解説したサイトがあるって事でしょうか？
う〜む・・・。

MySQLは4.1から認証方式が変わってるから、そのせいではないかい？
OLD_PASSWORD関数つかってみれ
例：
UPDATE mysql.user SET Password = OLD_PASSWORD('hogehoge') WHERE User = 'foo';
FLUSH PRIVILEGES;

>>383
ありがとうございます！
教えて頂いた通りやってみたところ、エラーは消えて無事接続できました！

・・・が、モデルが開けません・・・orz

DBDesigner4はMySQL4.1以降には対応していないって事でしょうか。
フリーでかなり良さそうなツールだったので残念。

でもお陰で勉強になりました。
本当にありがとうございました！

ふーん、リバースなんて機能あったんだ。
でも、もともと不安定なツールだからね＞DBDesigner4

ＭｙＳＱＬに対応してるモデリングツールで
論理・物理名を切り替え、同時表示できるのありますか？

最近？でも無いのかも知れないけど、IDとCDの使い分けを
推奨する読み物を見掛ける事があるのですが実際の所どう思います？

●定義
ID:ユーザが意識しないシステム上での識別子
CD:ユーザが意識する識別子

この定義までは、同意です。

この後、CDを使う場合は、IDを主キーとし、
CDには、ユニークインデックスを張るという解説がよくみるパターンです。

この通りに進めると確かにCDは変更できるのですが、
モデルが複雑になりアプリの開発工数が確実に増えます。

（昔CDを変更する要件があって同じ実装をしたが
履歴系情報との整合性問題を理解して貰うとか、
CD変更用アプリを別途作るとか面倒ダタヨ）

その辺のバランスが、私の経験だとヤリスギと感じるのですが、
どう思いますかね？

(1) joinするときに便利（複合主キーの場合）
(2) 変更履歴を管理しやすい（コード変更時は直接変更ではなく古いコードに削除フラグを立てる、という感じ）
(3) 最近のアプリケーションフレームワークにシステムidを前提にしたものが増えてきている（Hibernate,RoRなど）

仕様変更とか柔軟になるし
要求側には出来る限り押し通す

モデリングする段階ではCDを主キーとして、IDは実装段階で
主キーにするのでは。

>>388
>(1) joinするときに便利（複合主キーの場合）
４階層目のテーブルなどで、主キーの項目数が、やむえず増えた場合に
代替となるIDを振る事には、同意です。
気になっているのは、1:1でCDとIDを作成する事が、どうなのかなぁと。。

例えば、↓こんなテーブル
取引先テーブル
取引先ID（主キー）
取引先CD（ユニーク制約）
取引先名（単なる属性項目）


>(2) 変更履歴を管理しやすい（コード変更時は直接変更ではなく古いコードに削除フラグを

立てる、という感じ）

削除フラグを使用するという事は、CDにはユニーク制約を
張らないという事ですね。
変更履歴を、作りやすいという点は、分かりました。

この方法で気になる事は、
・CD値の重複チェックをアプリ側で徹底する必要がある。
・変更のたびにレコードが増えて行くのは、
　いたすらに負荷(JOIN等)を増やす事になるのでは？
・CD値の変更を行った場合には、レコードが追加され
　新しいIDが振られると思うのですが、
　子テーブルとの紐付けはどうなるのでしょうか？


>(3) 最近のアプリケーションフレームワークにシステムidを前提にしたものが増えてきてい

る（Hibernate,RoRなど）
な〜るほど、それには従った方がよさそうですね。

>>389
>仕様変更とか柔軟になるし要求側には出来る限り押し通す

う〜ん、本当にそこまでやるメリットがあるのか
私の経験上わからないのですよねぇ。
ちなみに開発してきたのは、中小規模で数人で分析〜リリースし
半年位の規模で、受注だとか会計だとかのシステム。


>>390
>モデリングする段階ではCDを主キーとして、IDは実装段階で
>主キーにするのでは。

そのようですね。
最初に見たのは、WEB+DB Press Vol.21「データベース設計の基礎知識」で
最近見たのは、Developers Summit2006の↓「楽々ERDレッスンLive」
ttp://www.seshop.com/event/dev/2006/data/download/9-E/9-E-3.pdf

IDとCDを分ける、最大のメリットはCD値の柔軟な変更だと
思っているのですが、変更できないといっている原因は、
参照整合性制約が理由ですかねぇ？

だとしたらCD値を主キーとして、参照整合性制約にON UPDATE CASCADEを
付加する方が、シンプルで柔軟性も確保でき負荷軽減という点でもメリットが
大きいと思うんですよねぇ・・・

ちなみに、ON UPDATE CASCADEのサポート状態を、ざっと調べてみた所、
使用可：SQLServer2000 , Access97 , MySQL4.0.8 ,pgsqlでも使えるっぽい。
使用不可：Oracle（Oracleで使えんのは問題か。。？）

自分は主キーは更新しないって前提で組むな。
主キーに整合性とってないデータも有ったりだし。
別に外部キー更新したい訳じゃないし。

履歴をどうするかなあと考えていたが、削除フラグねえ。仕様としては前回履歴のみ？
無限履歴とか、ラスト５回履歴とか、便利では有るが、ディスク容量喰うよなあ。
年度毎あたりでダンプして履歴リセットって仕様にすると、継続サポートコスト発生で開発側はウマーかな？

>自分は主キーは更新しないって前提で組むな。
私も基本は、主キーは変更しないという考えです。

というか、CDだろうがIDだろうが、一度付けた識別子を、
変更するな、という旧い？考えなのです。
ただ、会社として扱うデータ量、種類が増えてきた為に
コード体系を、変更したいといった要望が発生するのは
分かるので、コードを変更する上で効率的なモデリングは、
どんなのかなぁと考えている所です。

まぁ、そんな状況になった場合は、CDだけじゃなくシステム
全面見直しな上、会社として儲かっている可能性が高い訳で、
アプリの修正工数なんて、ちょちょいと出てくるはずなんで
すけどねぇ。。。Ψ(｀▽´)Ψｹｹｹ
その辺のバランス、CDの洗い替えが多発するという状況が
思いつかないのも、疑問に思う一つの理由です。


>主キーに整合性とってないデータも有ったりだし。
整合性が取れない可能性のあるテーブル（参照整合性制約を
張らないテーブル）で、私がよく作るのは、
・トランザクション系テーブル
・履歴系テーブル
・外部からの連携情報テーブル
・汎用的に様々なCDを入れる為の属性

な〜るほど、こう考えるとCD一本でモデリングした場合の
トランザクションが問題で、CD変更時に生きている
トランザクションが存在すると面倒ですねぇ。

みなさんありがとう、納得しました。

IDとCDを分ける事によりシステムの寿命が延びるが、
工数と負荷の面でのデメリットがあるという考えで
使い分るとします。

CD体系の変更が発生する可能性の高いシステムが前提の場合、
トランザクション系システムならば、IDとCDを分けて、
データウェアハウスや、寿命よりも処理速度にシビアなシステム
ならば、分けないといった感じですかね。

工数も少なくCDの変更ないだろう、といった場合は、
やっつけ仕事で、次回に回収すると。。Ψ(｀▽´)Ψｹｹｹ


他には、IDとCDを分けた場合、履歴系はデータを登録しすぐに削除し
また同じCDで登録した時に関連が切れるという点をユーザーに理解
してもらう必要があると。（たいした問題ではない。）

T字型書けるツールってない？visioじゃないみたいだし・・

EXCEL

>>397
T字型は表記法と正規化における規則であって、正規化そのものじゃないと思うけど。
ER 図なら Visio や ER Studio などで十分。

69の言ってことがよく分からん。

> 会社で社員が部門に所属しているのを表すとき、
> 社員（社員コード、氏名）　部門（部門コード、部門名）　所属（社員コード、所属部門コード）
> のようになるようなんですが、T字型でないERの場合は
社員（社員コード、氏名、所属部門コード）　部門（部門コード、部門名）
> となると思うのです。

これは、表記法がT字型であろうとなかろうと、結果は一緒になる罠。
理由は70、71が言ってるとおり。

>>397
DynamicDraw(ttp://www.molips.com/jp/)
に
ttp://groups.yahoo.co.jp/group/molips/files/
のテンプレートを入れて使う。

EXCELとかWORDは矢印線の先端スタイルが限られているから
いまいち使えないね。「ファイルが開けないよ〜」って人には
WORD　or EXCELにクリップボード経由でメタファイル形式で貼り
付けて渡せばいいし。
（再編集はできないけど。）

>>400
ありがとう。結構よさげだね

ER図のサンプルが沢山見られるサイトとかってありますか？
勉強用にいろいろ見てみたいのですが・・・。

最近、モデリングの勉強はじめました。
下記以外にお勧めの書籍ありましたら、お教え願えませんでしょうか。

■ 読んだ
「実践的データモデリング入門」 真野 正
「業務別データベース設計のためのデータモデリング入門」 渡辺 幸三
「データベース設計論 −Ｔ字形ＥＲ」 佐藤 正美
「名人椿正明が教えるデータモデリングの技」 椿正明

■ 読むつもり
「データ中心システムの概念データモデル」 椿正明
「生産管理・原価管理システムのためのデータモデリング」 渡辺 幸三


「Ｔ字形ＥＲ」は新しいのを読んだので、ほか２冊は読まなくて良いかなと
思ってるんですがどうでしょう？
（店頭で見つからないので、内容確認できないんです）

たくさん読めばよいというものでもないと思うが・・・

モデラーが１０人いれば１０通りのモデリングがあるって聞いたので。
実際、著者により主張が違うところがあるので自分で比較検討してみたいんです。
>>402 さんみたいに、サンプルを沢山見てみたい、てのもあります。

T字型ってモデルの属人性を排除するんじゃなかったけ？

そういう問題ではないだろう。
いろいろ勉強すればＴ字型ってダサいなぁと気付いたりするわけよ

あのダサさがいい

>>407
じゃあ、ナウでヤングなモデリングを教えてくだされ。

Ｔ字形って、認知番号重視なのは解るけど、
わざわざ主キーを非明示にする理由がわからん。

ヒント：馬鹿避け

データモデリングはどのような書籍で勉強しましたか？

ＯＪＴ

>>411
えー。
ＤＢ屋以外の関係者との会話に使えないような記法はどうかと思うけど。

うん、だから流行らない

>>414
哲学者とは会話できるようになるぞｗ

Ｔ字形の新しい本を読んで思ったのは．．．
あの理論編の哲学議論がまさに「言語ゲーム」。

ヲウムと同じだよね。
悟り開いて宙に浮く様になれば尊師の教えが分かるよって感じ。

傍から見てるとDQNにしか見えない罠。

理論編だけ読み飛ばせばﾓｰﾏﾝﾀｲ

そうはいかんよ。

従来のＥＲ手法でエンティティとリレーションを同時並列的に検討するのは、
純粋な「実体主義」も、純粋な「関係主義」も、現実的には極端すぎるから両方を同等に扱いましょう、
ていうのが背景にあると思う。（明示的にではないにしろ）

それを“実体主義のほうが本質的で、だからエンティティーを重視するんだ！”って主張するんだったら
そのへんをちゃんと論理的に、かつ皆が納得できるように説明してくれないと．．．

あの理論編は、ぜんぜん「理論」になってなくて、いろんな哲学のオイシイ結論を寄せ集めただけに見える。
だってボク、クリプキ好きなんだもん、とか言われても困っちゃう。

実践編、かなり有用と思うよ
でも、たしかに理論書としては、ちゃんと筋道たてて説明してない感じがする。
論理の飛躍がある、というより、断片を継接ぎした結果みたいな。

モデリングって学問としてあるわけじゃないのかな・・
奥が深いし、博士号取得した哲学者や数学者がもっと研究してほしい

計算量の上界値、下界値ってどういうことなんですか？
上界値＝計算量が最大と思われる値？

それより大きいことはありえないと保証できる値
てか板ちがい

>>423
レスありがとうございます。
では、これはどこの板行けばいいんですかね？プログラム板ですか？

Visioって作ったモデルからCreate文生成したり,DBに直接テーブル作成したりできるん？

新しい職場で、設計がやたら縦持ちになってるんですが、縦持ちってポピュラーな方法なんですか？
扱いにくくってしょうがないんですが。

>>425
VisioのProfessional版を使っていて、できそうだったのでちょっとやってみたら
「Enterprise Editionを使え( ﾟДﾟ)ｺﾞﾙｧ！」と言ってきました｡インスコしてないので試せないが､
Enterprise版を使えばできると思われ。MSDNにはついてきていると思う｡

Create分まで作りたいんなら、VisioよりDBDesigner4を勧めたい

>>428
理由等わかればkwsk

タダだから

仕様書作る時にはvisioのほうが便利。
実装と文書化の二度手間のほうが苦痛。

仕様書ってどういうレベルのもの言ってんだ？
DBDesignerでもER図やDB定義書くらい作れるぞ

客と下請けに提出する清書レベルだよ。
手書き程度ならチラシの裏に落書きで十分だし。

レスくれた方ありがとうございました。Visio for Enterprise Architects
というバージョンで出来ました。

ところで、教えていただきたいことがあるのですが、3種類のコードが組み合わさって
出来ているコードがあるのですが

　　AAABBCC

　　コードA　VARCHAR(3)
　　コードB　VARCHAR(2)
　　コードC　VARCHAR(2)

こんな感じです。AとBとCは親−子−孫の関係にあるのですが
この親−子−孫を表せるようにモデリングするにはどうしたらよいでしょうか・・・・

>>434
親＝PK:|AAA|
子＝PK:|AAA|1-n|BB|
孫＝PK:|AAA|1-n|BB|1-n|CC|
かな？

んで。気になるのは。各コードは固定長でなく可変長なんですか？？

>>435
あ、固定長です。

>親＝PK:|AAA|
>子＝PK:|AAA|1-n|BB|
>孫＝PK:|AAA|1-n|BB|1-n|CC|

これは、まさしくこんな関係です。

あるリソースエンティティ同士の関係を表すのに
交差エンティティを作成するという例はよく見かけるのですが、
イベントエンティティ同士の関係についても交差エンティティを作成するという
事はあるのでしょうか？
たとえばある複数の勘定科目から出金して、出金した額を別の種類の複数の
科目へ入金するといった作業があるとして、出金エンティティと入金エンティティ
との関係はどう表したらよいのでしょうか。

yhSEfIF00

>>437
交差エンティティって呼ぶのかどうかは知らないけど、
そんなようなものは必要に応じて当然作るよ。

○親テーブル
PK1　　　　　　　PK2
入金No.010　　　出金No.101
入金No.011　　　出金No.102

○子テーブル-入金
PK1　　　　　　　PK2
入金No.010　　　勘定科目A　　　1,000
入金No.010　　　勘定科目B　　　2,000
入金No.011　　　勘定科目C　　　　200

○子テーブル-出金
PK1　　　　　　　PK2
出金No.101　　　勘定科目Y　　　2,500
出金No.101　　　勘定科目Z　　　　500
出金No.102　　　勘定科目A　　　　200

DB作る前に簿記の勉強したほうがいいね。
帳票をそのままDBにすればおk。

簿記検定受験後の今その言葉の重みが良くわかる

つまらない質問で申し訳ないのですが、
顧客IDなどのコードの作成方法は
決まっているのでしょうか。
社員番号なら入社年月日＋連番
などでいいと思うのですが、
何か指針はあるのでしょうか。

連番も何桁取るとか有るよ。２桁じゃ１００人入ったら終わり。
総務や人事と打ち合わせて決めたほうがいいよ。
全社的に統一しないと意味がない。

顧客コードなら営業とかと打ち合わせて決めるべき。
営業上、顧客の元に自社の顧客番号が付いたものが送られるし、「ああ、うちって１００社目なんだな」って推測されちゃうような顧客IDは恥ずかしい。

設計するのに使ってるツールとか教えて！
XEADとかJude、ObjectBrowserERあたりがよさげなんですが！！
今試そうと思ってるのがOracle JDeveloper10g！！！

DBDesigner4最強。
XEADだけは勘弁

>>445 さんへ
XEADは、どこら辺が駄目だと思いますか？

ナチュラルキーとサロゲートキーって使い分けどうしてますか？
顧客マスタとか商品マスタみたいなのはナチュラルキー、
受注TRとか売上TRはサロゲートキー、
仕様変更が多そうならサロゲートキー多め、
ERモデリングツール使うならナチュラルキー、
ORマッピング使うならサロゲートキー、
こなかじ？

知るか。何でもいいよ。
あれもアホな議論だったな

佐藤 正美氏が提唱する「Ｔ字形ＥＲ」ってどうなんでしょ。会社の上司が
信者（？）で何が何でも導入したいみたいで。。。本を読んでみたけど
文章表現は下手（だと思った）だし理論にしても判り辛いような。。。
数千人規模の会社の基幹業務構築のモデリングには大丈夫なのかな〜？
と思ってます（例えば数年後には理論自体廃れてるとか・・・）。

>>449
いいところはresource概念とevent概念云々のところぐらいか
あとはちょっと・・・。identifierの扱いがアレなんで、あの理論をそのまま適用するのは
実際的ではないと思う

データモデリングなんて勘でやるのが一番いい。
主キーと関連だけしっかり抑えとけば大概上手くいく。

大事なのは、間違ったモデリングなんてないと知っておくこと

勘でやる時点でだめだめな悪寒。

いろんなモデリングのシミュレーションソフトとかあれば設計時に検証しやすくて便利なのにな。

>>449
基幹ではないが、大手での採用例はあり。
和光市の某自動車メーカとか、麹町の某信販会社とか。
ただ、Ｔ字型を使ったプロジェクトで試行錯誤した経験者がいない状態で
本読んだだけでいきなり実地の大規模システムに適用しようとすると
多大な困難が待ち受けていそうな悪寒が…

ＴＭ（Ｔ字形ＥＲ手法）は、CoddのRDBMに始まって、正規化だけでは解決しない問題を検討している間に、
業務系のシステムでは「コード体系」を使って分析するのが便利って便法を思いついたりしながら発展して
きましたが、根っこの部分ではオブジェクト指向におけるドメインモデリングと繋がっています。
なので、#453 の方が言われる様に、本を読んだだけで見よう見真似で始めるのは、少し辛いでしょう。
できれば、本人から習うことが可能なので、それが一番だと思います。
http://www.sdi-net.co.jp/ に行ってみましょう。

↑
ＨＰ見てみたけど、本当大丈夫なの？かなり素人っぽいＨＰで
すが。コンサルとかやってるんんだったらもうちょっとマシな
ＨＰにした方がいいような。。。
それに実績も書いてないし。>>453 の和光や麹町の会社ではどれだけ
ＴＭにより実績がでたのかな？
コンサルやるなら会社（？）の規模も知りたいなー

麹町では使ってはいるが「お絵かきソフト」程度の使われ方。
「Ｖｉｓｉｏの方が書きやすいじゃん」ってノリだから「ＴＭを
導入してビジネスの強み・弱み・・・」なんて程遠い状態。

>>455
WebPages見てそういう感想抱いたのなら、ＴＭとは出会わなかったことにした方が多分幸せになれる。
いや、煽りや皮肉ではなく、本音ベースの話。
感覚的な「合う」「合わない」っていうのは結構重要な要素かと。

ＨＰ見たけど「1,000,000 ステッフ゜ 規模の システム であれば、10数名で、6 ヶ月以内に導入する。」
ってのは凄いなー。
事例とかあるといいけどね。

優秀なエンジニアが集まればとか、そのための費用を出せるならとか前提条件いっぱいだろ？
まあ優秀なエンジニア集めれば、別に何でも短納期でできそうな悪寒。
そういう論点のすり替えをして一儲けするのがコンサルと言えばそうだけど。

>>458
ステップってコード量だよねぇ？
でコンサルが開発するわけじゃないだろうし、有効なメトリクスなのかね？
コンサルとしてはそういうところ大事だと思うんだが。

画面数とかテーブル数とかユースケース数とかでないとピンと来ない

皆様始めまして。
DBDesigner4の使い勝手が良かったので日本語化してみました（需要アルカナ・・・）
http://dbdesigner.iimp.jp/
使ってみてご意見いただければと存じ上げます。
Delphiはあまり使ったことがないので安定度が下がっているかもしれません。。
あと、、まだWindows版しかコンパイルしていないです・・・。
Linuxはあまり慣れていないもので。。すみません。。。

>447

主キーベースのERDを作成する段階では、ナチュラルキーでモデリングし始め、
全属性ERDを作成する段階で、最終的にサロゲートキーに再設計してる。
（最初はナチュラルキーの方がわかりやすいので・・・）

全部サロゲートキーにしてる理由は、
（１）安定性の確保
　　：将来のシステム改善などでの主キー属性の設計変更を、極力抑える。
　　　（候補キー自体が安定していることが前提なのに、変わることあるから・・・）
（２）データへのアクセスコストを抑えたい
　　：ナチュラルキーだと３つ以上のコンポジットとなってしまう場合がある（特に連関エンティティ）
（３）ポリシーの統一
　　：全エンティティを同じポリシーで設計するため全部サロゲートキー

なんて言い訳でサロゲートキーにしてる。

>>463
>候補キー自体が安定していることが前提なのに、変わることあるから・・・
間違えた。
候補キー　-> 主キー

保守age

FFの武器を管理したいと思っています。
次回のバージョンアップで他のシリーズも同一のテーブルで管理できるようにしたいです。

現在
武器 (武器ID, 攻撃力, 入手場所)

案1
武器テーブルにシリーズNoを追加して、シリーズNo＋武器IDを主キーにする。
シリーズNo | 武器ID
FF1 | 001
FF1 | 002
FF2 | 001
FF3 | 001
...

案2
武器テーブルにシリーズNoを追加して、武器IDは主キーのまま通し番号とする
武器ID | シリーズNo
001 | FF1
002 | FF1
003 | FF2
004 | FF3

案1だと枝番の作成がめんどうなのですが、きれいにナンバリングされる。
案2だとキーの作成は簡単だが、データの入力順を間違えると気持ち悪いナンバリングになってしまう。

どのような場合にどちらがいいか教えてください。

>466
複合キー列への外部キー設定は列が増えてしまって、
子表が増えるほど面倒になるから案2がいいなぁ。どうせ
武器IDなんてもとより意味のあるものじゃないんだし。


もういっそ武器IDは乱数を採番するようにしちゃえば気にならないよ。

1の方がデータ移行は楽そうだな。
最近の流行は2か。アプリケーションフレームワーク的に２のようになってないとあかんものがあるな。

武器リストだと表示順ってのも気にしたいだろうから、
１のテーブルにさらにid列を一つ追加して、
武器IDは表示順的な意味を持たせるのもありかも

MySQLのDBDesignerに相当するpostgresqlのツールってありますか？
それとも、postgresqlをodbcで接続して、DBDesignerを使っても、幸せになれますか？

このスレでも何回か見かけるが、簿記の知識がSEにも要求される場合がある。
独学で簿記を勉強しようとすると、書籍を購入して勉強となりがちだが、
項目が羅列してあり説明は最小限のような簿記の書籍ではなかなか理解は進まない(俺だけか)。
簿記の書籍は不親切であり、そのために資格学校が存続できてる気がする。
資格学校に通わなくても資格学校の通信教育等もあるし、それもそんなに高くはない。

さらに講義形式の勉強で一番手軽なのは、資格学校が出版しているDVDビデオの教材がある。
例えば、以下のような教材がある。

合格テキスト講義DVD日商簿記3級 商業簿記 Ver.4.0(10,500円)
DVD6枚組 TAC出版

俺は本屋で買ったが、amazonにもある。講師は違うが2級もある。
これと対になってる書籍(テキスト)も別に売ってるが、なくても特に困らない。
DVDの講義なので、好きなときに何回でも見れる。
これを見てしまうと、いかに市販の書籍で学ぶことが能率が悪いかということがよく分かる。
おそらく簿記の勉強は書籍ではなくて人の話を聞いて学ぶのが一番よいのでは
ないかと思う。「要はこういうこと」みたいな言葉やくどいぐらいの説明は
なかなか書籍には載りにくい。このDVDのテキストも同じ欠点がある。

例えば減価償却累計額について簿記上の具体例を含めて詳しい説明を書籍で
探そうとすると結構大変だと思う。また、講師がしゃべってくれるわけで漢字の
読み方も問題なくなる。この3級の講師は大変よいと思う。きっちりとよく話してくれている。

スレ違いすまん。

まぁ、SEが片手間に勉強するのにむいた教材は確かに少ないかもしれんけど、
たかが3級レベルで分かりやすいも分かりにくいも無いと思うんだが・・・

まったくその通り。10日でわかるとかそういうので十分、
実際は1週間足らず勉強してケアレスミスで落として
90点代後半取れた。

初心者です。
物理データモデルの「内部スキーマ」とは、具体的にRDBMSで
いうところの、どのようなオブジェクトなのでしょうか？

どなたか御教授ねがいます。

テーブルとかカラムとか

>>473
ANSI/SPARC ３層スキーマのことなら、
概念スキーマ：テーブル
外部スキーマ：VIEW
内部スキーマ：物理ファイル定義（oracleだとセグメントかな）

>>475さん
ありがとうございます。
ANSI/SPARC ３層スキーマに関してですが、SQL Server 2000
について「内部スキーマ」なるものが、どのようなオブジェクトを
指すのかご存知なら教えていただけますか？

宜しくお願いします。

>>476
内部スキーマについて、oracleだとセグメントって書いたけど、
データベース上の特定のオブジェクトや構造を指している
というよりも、索引からセグメントからデータファイルまでの
物理構造のことを指してる。
SQL Serverは詳しくないのだけど、同じようにセグメント
（oracleでは表領域に相当）からデータベースデバイス？までの
物理構造のことを指しているのではないかな。

次のケースの一般的なデータモデルをご教授ください。
長文で申し訳ありませんが宜しくお願いします。

<前提条件>
製造業向けの部品加工を想定(在庫関連の処理は無し）
製品･部品･工程･実績の４つのエンティティがあるとして、、、

製品 … 製品というよりは製造指示Noのようなもの
部品 … 製品を構成する部品です。(※一般的なBOMのような親品目,子品目を再帰で保持するような複雑な構造ではない)
工程 … 部品を加工するための加工工程手順です。(手順1:旋盤, 手順2:マシニング...)
実績 … 加工工程に対する実績(労務費、労務時間)

４つのエンティティの関連は次のような階層構造を考えています。
(※この考え方がおかしい場合はご指摘ください)

　製品 → 部品 → 工程 → 実績
(1:n) (1:n) (1:n)

部品には材料や購入品といった部品区分があり、データ属性が異なるため、
部品をスーパータイプ、材料･購入品をサブタイプで持たせようと思っています。
　製品 → ＋部品(部品id(PK), 部品区分...) → 工程 → 実績
｜
＋材料(部品id(PK), 仕入先cd(FK), 寸法...)
　 ＋購入品(部品id(PK), 仕入先cd(FK), 購入品品番(FK)...)

*** 質問１***
各エンティティの主キー(PK)をどのように設けるのが一般的なのでしょうか？
上記のようなデータ構造の場合の一般的な主キーの設け方をご教授ください。
今考えているのが�@と�Aの方法です。

�@各エンティティに単独の主キー(PK)を設けて、親への参照キー(FK)をそれぞれ持たせる。
製品: 製品id(PK), 製造指示No, 型番...
部品: 部品id(PK), 製品id(FK), 部品区分, 部品cd, 部品数...
材料: 部品id(PK), 製品id(FK), 仕入先cd(FK), 寸法...
購入品: 部品id(PK), 製品id(FK), 仕入先cd(FK), 購入品品番(FK)...
工程: 工程id(PK), 製品id(FK), 部品id(FK), 工程cd, 工程手順No, 標準時間, 数量...
実績: 実績id(PK), 製品id(FK), 部品id(FK), 工程id(FK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...

�A各エンティティの主キー(PK)を複合キーで持たせる。
製品: {製品id}(PK), 製造指示No, 型番...
部品: {製品id, 部品id}(PK), 部品区分, 部品cd, 部品数...
材料: {製品id, 部品id}(PK), 仕入先cd(FK), 寸法...
購入品: {製品id, 部品id}(PK), 仕入先cd(FK), 購入品品番(FK)...
工程: {製品id, 部品id, 工程id}(PK), 工程cd, 工程手順No, 標準時間, 数量...
実績: {製品id, 部品id, 工程id, 実績id}(PK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...

そもそも考え方がおかしい場合はご指摘ください。

続きです。
*** 質問２***
次の原価をリアルタイムで把握したい場合には原価データをどのように保持するのが一般的なのでしょうか？
(※ここでは外注費は無いもとする)

　1.製品別原価(製品別の材料費計＋購入品費計＋労務費計)
　2.部品別原価(部品別の材料費計＋購入品費計＋労務費計)
　3.工程別原価(工程別の労務費計)

考えているのは次のとおりです。

�@製品エンティティに"材料費計", "購入品費計", "労務費計"のデータ項目を持たせる。
�A部品のスーパータイプエンティティに"材料費計", "購入品費計", "労務費計" のデータ項目を持たせる。
�B工程エンティティに"労務費計"のデータ項目を持たせる。

各計データの更新はトリガーやストアドにて行う


そもそも考え方がおかしい場合はご指摘ください。
以上、宜しくお願いします。

質問１

正規化をきちんとするなら、�@の材料と購入品には製品idは入らないはず。
俺なら他のテーブルとの一貫性を保つために

材料: 材料id(PK), 部品id(FK), 仕入先cd(FK), 寸法...
購入品: 購入品id(PK), 部品id(FK), 仕入先cd(FK), 購入品品番(FK)...

とする。でも、部品idにユニーク制約をつけなきゃいけないのでそこを手間と感じるかどうか。

�@か�Aかはどっちでもいいけど、最近は�@が主流。
処理側のフレームワークと言うかプログラムロジックに便利な方を選択。

質問２

集計用のテーブルを別に作るべき。
完全なリアルタイムにせずに、例えば１０分ごとに集計バッチをまわすとか、
Oracleならマテビューを使うとかする

>>480
遅くなりまして申し訳ございません。
レスありがとうございました。

質問１について
なるほど、確かにデータ編集時に、複合主キーより単独主キーでアクセスした方が
SQL文も簡単に記述でき、何かと便利が良さそうですね。

教えて頂いた方法で実装しようと思うのですが、
�@の方法(各エンティティに単独の主キー(PK)を設けて、親への参照キー(FK)をそれぞれ持たせる)で
きちんとした正規化を行う場合、工程の製品id(FK) と 実績の製品id(FK), 部品id(FK)も要らなくなり、
次のようになるはず？(１階層上の親id のみ 持たせる)
この理解で問題ないでしょうか？

製品: 製品id(PK), 製造指示No, 型番...
部品: 部品id(PK), 製品id(FK), 部品区分, 部品cd, 部品数...
材料: 材料id(PK), 部品id(FK), 仕入先cd(FK), 寸法...
購入品: 購入品id(PK), 部品id(FK), 仕入先cd(FK), 購入品品番(FK)...
工程: 工程id(PK), 部品id(FK), 工程cd, 工程手順No, 標準時間, 数量...
実績: 実績id(PK), 工程id(FK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...

もしくは、材料id, 購入品id は持たず、次のようにする。

製品: 製品id(PK), 製造指示No, 型番...
部品: 部品id(PK), 製品id(FK), 部品区分, 部品cd, 部品数...
材料: 部品id(PK), 仕入先cd(FK), 寸法...
購入品: 部品id(PK), 仕入先cd(FK), 購入品品番(FK)...
工程: 工程id(PK), 部品id(FK), 工程cd, 工程手順No, 標準時間, 数量...
実績: 実績id(PK), 工程id(FK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...

続きです。
>>480
遅くなりまして申し訳ございません。
レスありがとうございました。

質問２について
やはり集計用の別テーブルを設けた方がいいのですね。
今回のケースで集計テーブルを用いるとすれば、次のような感じでよろしいですか？
集計元テーブルと集計先テーブルは(１：１の関係）になる。
また本来は集計テーブルに主キーの項目として集計日を含むと思うのですが、
今回は集計日が要らないので外します。

製品: 製品id(PK)... → 製品別原価: 製品id(PK), 材料費計, 購入品費計, 労務費計...
部品: 部品id(PK)... → 部品別原価: 部品id(PK), 材料費計, 購入品費計, 労務費計...
工程: 工程id(PK)... → 工程別原価: 工程id(PK), 労務費計...

もしくは、集計テーブルにも単独主キーを設けて、次のようにする。

製品: 製品id(PK)... → 製品別原価: 製品別原価id(PK), 製品id(FK), 材料費計, 購入品費計, 労務費計...
部品: 部品id(PK)... → 部品別原価: 部品別原価id(PK), 部品id(FK), 材料費計, 購入品費計, 労務費計...
工程: 工程id(PK)... → 工程別原価: 工程別原価id(PK), 工程id(FK), 労務費計...


以上、質問ばかりで申し訳ございませんが
宜しくお願いします。

パソコンショップならここ！！
http://want-pc.com

6ehkeP <a href="http://dphojlgmqyum.com/">dphojlgmqyum</a>, [url=http://dciuxyoglilw.com/]dciuxyoglilw[/url], [link=http://jupungwigput.com/]jupungwigput[/link], http://tltjzxqojqqo.com/

aVR2l3 <a href="http://mxmpbpvmprfm.com/">mxmpbpvmprfm</a>, [url=http://yrgjgiqgeori.com/]yrgjgiqgeori[/url], [link=http://xppokryehkqp.com/]xppokryehkqp[/link], http://pnlqzfhrtylu.com/

>>481
OKと思われ。

>>482
OKと思われ。まぁ、こっちは単独主キー無くてもいいかも知れんが

>>486
レスありがとうございました。
これでスッキリしましたので先に進めそうです！！

http://ublog.union.edu/elpinner/88 buy zovirax

http://iqlveq.cn cheap mp3 downloads

http://itdvmb.cn mp3 player downloads

http://kgnsye.cn/imax-california.html Imax california
http://kgnsye.cn/california-dept-of-corporation-htm.html California dept of corporation htm
http://kgnsye.cn/single-family-homes-carlsbad-california.html Single family homes carlsbad california
http://kgnsye.cn/archangel-tattoo-design.html Archangel tattoo design
http://kgnsye.cn/blue-book-pricings-for-atv.html Blue book pricings for atv

http://bfsnbw.cn/mp34 free memory

MySQL4.1、5.0でも　DBDesignerは使えますか？

>>384 に同じ現象が書かれているのですが・・・
バージョンアップされてないからなぁ＾＾；

A C

n1ywUN <a href="http://vdgsdgcxvewl.com/">vdgsdgcxvewl</a>, [url=http://ltldczvyogvo.com/]ltldczvyogvo[/url], [link=http://dznjgohehaza.com/]dznjgohehaza[/link], http://whxrulsmcetw.com/

住所録のデータベースのモデルです。
取引先の会社とその担当者、お客様とその家族、
と、全部で4つのテーブルを作成しました。
それぞれのテーブルには、名前や電話や住所などの
列を並べました。

そこで疑問になったのが。
取引先の住所と担当者の住所は、共通する事もある（し違う事もある）。
家族の住所と個人の住所は、共通する事もある（し違う事もある）。
と、考えると。
住所部分のみでテーブルを作成して、4つのテーブルから
参照した方がいいのかな？とも思ったのですが、いかがでしょう？

そうね。それなら取引先が複数住所もってるケースにも対応できるね

取引先が複数住所を持ってるケースは考えていませんでしたが。
確かにおっしゃる通りで、良さそうですね。

また、営業所が移転した場合や家族が引っ越しした時に、
同じ住所テーブルを示していれば、個人の住所も一括で
修正されますね。ありがとうございました。

1レコードに開始/終了時刻を持って「状態」を記録するメリットって何？
開始/終了イベントテーブルにそれぞれ発生時刻を記録するほうがいいと思うんだけど

>>499
イベントテーブルにそれぞれ記録するほうがいいのは
たとえばどんな時でしょうか？

>>499
抽出したエンティティの意味的な違いに優劣はないから実用上のメリットで言うと、
所要時間を求めるようなクエリでjoinを節約できるとか。
逆に挿入/更新でコストはかかっているわけで、メリット/デメリットともに
事前集計表と似たようなもの。

保守

状態が欲しい場合も無く無いと思うけどなあ。


導入事例ってあんまり当てにならないのか。まあそもそも営業資料だしね。
導入されても、実際十分に活用されてるかどうかや、現在も使われてるかどうかはわからないしなあ。

町場の工務店用データベース作成のためこんな感じのＥＲ図を作成してみたのですが
もし問題があれば指摘していただけるとありがたいです。　
http://niyaniya.info/pic/img/2186.jpg

業務の基本的な流れは　見積作成⇒請負契約⇒ 工事 です。オリジナルはもうすこしマスタテーブルが
増えて複雑なのですが、基本はこんな感じです。　よろしくお願いします。　

>>504
普段、IDEF1Xでしか読み書きしてないから、リレーションシップの
意味が正しく理解できてるかわかんないのと、業務要件が不明だから、
自分の所見でコメント。
（１）「見積明細」の主キーは”見積ID”では？。
　　「見積明細」は「見積」のサブタイプということだと思うけど、
　　意味があって分けてるのかな？
（２）「請負契約明細」についても（１）と同様。
（３）「請負金額入金」「請負金額請求」は、「入金」「請求」として
　　独立エンティティにするか悩むところ。
　　入金単位や請求単位が請負契約単位なのかな？
　（１契約で入金は複数回とかないのかな）
（４）何故「仕入契約」「下請契約」は"業者ID"が主キーに
　　なってるのに、「請求契約」の方には”顧客ID”が主キーに
　　なってないの？　この違いの意味は？
　　両方とも<契約>という同じような意味のエンティティと
　　考えれば、その属性も同じような主キー構成で
　　いいと思うけど。

※属性なしで、エンティティ名だけでリレーションシップを
　考えた方がわかりやすいですよ。

>>505
レスありがとうです！

ありがたい指摘なのですが理解する語彙が足りずアドバイスを生かしきれないのが
残念ですが・・・

(1)で言われた「見積明細」テーブルは、本来「見積」テーブルと一体の繰り返し要素を別テーブルに分離した
もので主キーは設定していません。　１つの見積に対して複数の見積項目があるので２つのテーブルに分離しました。　
販売業者における販売テーブルと販売明細テーブルのような関係です。

(2)の「請負契約」と「請負契約明細」も同様の関係です。

(3)の「請負金額入金」「請負金額請求」は確かに一つのテーブルに統合できそうです。
盲点でした・・ありがとうございます。

問題は(4)でして、、、『なぜ「請負契約」の方には顧客IDが主キーになっていないのか』
との指摘ですが、　請負契約の場合、１つの契約に相手となる顧客は１つだけなのですが、下請契約や仕入契約は
１つの工事に相手となる業者は複数に及ぶことがあります。　その質の違いから差が生じたと思います。　

これがはじめてのデータモデリングで試行錯誤の結果ですのでもしかしたら基本的なところで誤理解をしてる可能性
ありですので・・・その程度のもんだとオモっていただけるとありがたいです。

明細テーブルにも主キーはつけるべきだよ。
この場合は表示順を主キーにすりゃいいんじゃないかな。

> (3)の「請負金額入金」「請負金額請求」は確かに一つのテーブルに統合できそうです。

統合すると請求1回に対して入金複数回のケースとか対応できなくなるよ。
あなたんとこの業務的には問題ないのかも知れんけど、
柔軟性保つために分けておいたほうがベター

主キー入ってないテーブルがあること以外は、大体OKそうに見えるね。
>>505は見当はずれだから気にしないほうがいい

> この場合は表示順を主キーにすりゃいいんじゃないかな。

ごめん、親テーブルの主キー＋表示順というつもりだった。
たとえば見積明細では（見積ID、表示順）を主キーにする

>>506
505です。今日は何故か眠れないのでレス
ちょっと説明がまずかったみたいなので、まず用語から。
※文中の用語はググってね。
エンティティ＝テーブル
属性＝列項目
主キー＝（簡単に言うと）一意に行を特定できる列項目

（１）の、「１つの見積に対して複数の見積項目がある」という
のは、「見積」１行に対して「見積明細」複数行という意味であれば、
「見積明細」テーブルの主キーは、”見積ID”と、明細を識別する”明細ID"
みたいなのが必要。（用語的には第２正規形）

（２）も同様。

（３）はそういう意味ではなくて、「契約」「請求」「入金」と、
それぞれ独立した（主キーを持つ）テーブルにしても良いのではという意味。
データモデルを考えるときに、業務の実態を、リソース（資源：名詞）と
イベント（出来事：動詞）に分けて、テーブルとして考えるのだけど、
例えば、
リソースは、「社員」「顧客」「業者」で、
イベントは、「見積」「契約」「請求」「入金」「工事」「支払」
なわけだ。

以上

>>507
どこが見当違いか、指摘してもらえるとうれしいね

>>507
もしかして、（１）でサブタイプって書いたことを見当違いって
言ってるのかな？
エンティティ名だけ見ると、第２正規形を意識したと思えたけど、
もしかして主キーが同じで、あえて分けたのかと深読みしただけ
なんだけどね。

（３）は509で書いた通り。
（４）は、業務要件わからないから、所見てことで、
主眼を「請負契約」と同様に<<契約>>に置いてもいいかなと思ったのさ。

よろしく。

あのさ、「明細」ってかいてあんのにピンと来ないようじゃお話にならないと思うよ。

>>507
＞明細テーブルにも主キーはつけるべきだよ。
この場合は表示順を主キーにすりゃいいんじゃないかな

なるほど！　これは勉強になりました。　キーはテーブルの結合しか用途がないもの
だと思っていたのでそういう使い方が出来るのは初めて知りました。

＞主キー入ってないテーブルがあること以外は、大体OKそうに見えるね。
>>505は見当はずれだから気にしないほうがいい

いえいえ皆さんのアドバイスは大変勉強になります。　

>>509
＞「見積明細」テーブルの主キーは、”見積ID”と、明細を識別する”明細ID"
みたいなのが必要。（用語的には第２正規形）

たしかにおっしゃるとおりです。　明細テーブルの各行を識別するキーも必要ですね・・・。
ここらへんはまったくノーマークでしたのでありがたい指摘です。　　その意味で
見積明細にも見積IDを主キーに設定すべきと仰っていたのですね。　私の間違いでした・・・

＞データモデルを考えるときに、業務の実態を、リソース（資源：名詞）と
イベント（出来事：動詞）に分けて、テーブルとして考えるのだけど、

この辺はいまの自分にはちょっと高度です　もうちとレベルアップしてからアドバイスを
生かさせていただきます^^;

高度ってあんた・・・

>>512
まぁ、そう言いなさんな。所見で深読みしたけどさ。
最初の図（モデル）から想像したのは、子エンティティの
外部キーについて、親エンティティからのキー移行だけを間違えて
記述したものと深読みしたということ。
（よって、排他的サブタイプと見たわけ）
業界／業務要件が不明なので、モデルから判断するだけ、つまり、
名称（用語）でエンティティを安易に想像してはダメってことも
あるからね。（話をよく聞かないうちに決めつけちゃダメさ）
ちなみにウチの所でも、第２正規化の結果を「XX」「XX明細」と
してるよ。

スレ汚しスマソ。

みなさんのご指摘を参考に最終的に↓のように仕上げてみました。これでなんとか
やってみようと思います。　どうもありがとうございましたです！
http://niyaniya.info/pic/img/2219.jpg

業務知識が無いと、まともな設計が出来ない見本だな。
運用で不具合出まくるだろうなあｗｗｗ

五階層まで登録できる工事の見積システムのデータモデリングをしてるのですが
↓こんなかんじでどうでしょう^^; 　

http://imepita.jp/20090604/333030
項目A→項目B→項目C→項目D→項目E　と具体的になっていく感じです

例）　電気→3LDK標準電気工事→玄関→外部玄関等→照明器具 DWP-3524DS

項目Aによって必要な階層がことなるので動的に階層を変更できればいいのですが、、

>519
階層構造を柔軟にとか考えると、
所要量展開、再帰、LLC、
部品展開、原価計算、
といったところをある程度考慮して取り入れながら
設計するのかなと思う。
これらでぐぐってみてもよいかと。

>>519
その前に親子関係は1対多なんだよね？
何もテーブルを幾つも作らなくても、
子情報が主キーでそこに親情報が従属するような
再帰的な1テーブルで済まないの？

これだと、多重構造が可変でも耐えられるでしょ？

目指してる 未来が違う　ｂｙシャープ
http://twitter.com/saramura6/statuses/6688087715352576　

もう語らないのか

また必要とあれば語るだろう。

あなたはどうなのか。

　　　　　 _
　　　　　 |O＼
　　　　　 |　　 ＼　ｷﾘｷﾘ
　　　　∧|∧ 　　＼　ｷﾘｷﾘ
ｸﾞｸﾞｩ>（；⌒ヽ　　　 ＼
　　　　∪　　|　　 　　(~)
　　　　　∪∪　　 γ´⌒｀ヽ
　　　　　）　）　　 　{i:i:i:i:i:i:i:i:}
　　　　 （　（　　　　(　´･ω･)、
　　　　　　　　　　　(O ⌒　)O
　　　　　　　　 　 　⊂＿)∪

※本投稿の拡散歓迎です。
違法派遣（偽装請負・多重派遣・偽装出向・事前面接等）についての刑事罰
【告訴権者＝業務委託、準委任、共同受注、業務請負契約および特定派遣（契約・正規）、一般派遣、正規社員】

�@職業安定法第４４条の労働者供給事業の禁止規定に違反（1年以下の懲役または20万円以下の罰金）
　■偽装請負・多重派遣・偽装出向・多重出向
　■事前面接（顔合わせ・面談・職場見学等）と履歴書・職務経歴書・スキルシート等提出による労働者の特定(※）
（音声録音で立証可能）
�A労働基準法第６条（中間搾取の禁止） (1年以下の懲役又は50万円以下の罰金)
　■多重派遣・多重出向

※違法派遣（派遣労働者の特定）→派遣法で認められた派遣労働者ではない→労働者供給事業→職業安定法44条違反というの
が前提となる法解釈となります。派遣法における罰則が軽微なのは法律の不備や労働者軽視などが原因ではありません。
違法派遣は全て職業安定法44条で裁くことが可能なため、刑罰の重複を避けるために派遣法には軽微な罰則（主に裁量行政による）しかないのです。

使用者に有利な民事訴訟や労働関係諸局への通報等の対極にあるのが書面（告訴状）による刑事告訴（※告訴先は検察の直告班）です。
労働関係諸局への通報・斡旋による軽微な「適正化」や監督・指導に対して、法律に定められた刑事罰を問うことになり、
違法派遣業者にとって有罪は考えられる限り最大の処罰となります。同時に刑事罰を受けた
担当者が取引先に与える悪印象を考慮すれば、通常会社側は告訴が受理された時点で告訴取り下げに
動くのが妥当でしょう。懲役、前科がつく刑罰が下される可能性から、告訴取り下げの和解金は高額となることが多いのです。

告訴の流れとしては、

刑事告訴⇒告訴受理⇒告訴取下げ要請⇒取下げ和解金入金⇒告訴取下げ

となります。告訴の懲役刑適応は犯罪者個人に対してのみですので、告訴する対象は

派遣先・派遣元 社長
派遣先・派遣元 担当者・責任者・管理役員・取締役
派遣先・派遣元 人事管理担当者・人事管理役員・取締役

が妥当です。刑事告訴取り下げの和解金額は犯罪者個人と交渉するとよいでしょう。（告訴状は人数分提出する必要あり）

お知らせ

市原警察署の生活安全課の帰化人創価警官の指導の元、
入学式から2週間ほど、在日の創価学会員を主体とした自称防犯パトロールが、
2週間ほど行われることになりました

生活安全課の指導であることと、パトロールであることは、
絶対に公言してはいけないとの指導も、帰化人創価警官より出ています

期間中は2人組の在日の創価学会員が、頻繁に創価批判者の自宅周辺を、
うろつき回ると思われます
日本人の方は、充分に注意してください

データモデリングと設計って違うの？

設計のほうが(データモデリングよりも)広い用語だろな
つまり、すべてのデータモデリングは設計の一種だけど、
逆は必ずしも真にはならない

データモデリングはDB設計の中でも上流工程の作業を指し「概念設計」とも呼ばれる
具体的には、現実世界の事物をコンピュータの内部表現に近い
エンティティとリレーションの集合で定義する作業になる
そして、これによって完成したモデルを利用するミドルウェアやフレームワークに
合わせて具体化する作業が「実装設計」になる
実装設計が終えれば(詳細設計もしくは)コード設計が待っている

　業務系ってクラスモデリングよりもデータモデリングが主流なんでしょうか？
単に興味本位で聞いただけです。