【より良い】データモデリング【モデルを】
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
03/07/07 01:41ID:mnMZZn0Tモデル作成に関する質問、質問に対する回答、
作ったモデルの自慢、自慢されたモデルの批評など、
モデリングに関すること全般を扱います。
ソフトの使い方に関する話題、物理的なモデルの話題はご遠慮ください。
EX.
このソフトで○○の機能は～ → ソフトウェア板へ
○○の組み立てが完成して、これから塗装～ → 模型・プラモ板へ
モデリングツール
○SVG Cats
製品情報 http://www.sage-p.com/svgcats.files/svgcats.htm
DL http://www.vector.co.jp/soft/dl/win95/art/se251284.html
SVG(ベクター画像をテキストで記述するデータフォーマット。要はXMLの一種)でモデル図を描画するツール
●ER/Studio
製品情報 http://www.jsys-products.com/product/erstudio/
トライアル版DL http://www.jsys-products.com/download/trial/erstudio/
●AllFusion ERwin Data Modeler
製品情報 http://www.caj.co.jp/allfusion/erwin/data_modeler.htm
トライアル版DL http://www.caj.co.jp/registration/allfusion/erwin_pm.htm
●Rational Rose
製品情報 http://www.rational.co.jp/products/rose/
評価版請求 http://ops.rational.co.jp/CatalogHassou/f_req.html
●Microsoft Visio Professional
製品情報 http://www.microsoft.com/japan/Office/visio/evaluation/
評価版配布請求 http://www.microsoft.com/japan/office/visio/evaluation/trial/
SVGビューア
○SVG Viewerプラグイン
http://www.adobe.co.jp/svg/ ダウンロードページ
SVG画像を閲覧するためのプラグイン
0002名無しさん＠お腹いっぱい。
03/07/07 02:58ID:Q7SvyCOg0003名無しさん＠お腹いっぱい。
03/07/07 19:12ID:SY8PbIMK0004名無しさん
03/07/08 03:25ID:???0005名無しさん＠お腹いっぱい。
03/07/08 10:31ID:tx3ry9fl南下不安。
きわものに飛びつくよりIDEF1Xで我慢しとけといいたい
0006名無しさん＠お腹いっぱい。
03/07/08 23:12ID:???そだよ？知らなかった？
その手の比較には必ずっていうほど出てくる。
ｵﾏｴの場合は、ただのｵｴｶｷﾂｰﾙと一緒だろうが。
0007名無しさん＠お腹いっぱい。
03/07/09 00:45ID:wCmp9XwBいろんなツールが対応してるし、ERDと違って描き手によって表現が少しずつ違うってこともない。
ERDは、ツールによって表現が違うから、統一できなくて気持ち悪い。
つーかIDEF0の描き方がよくわからん・・・だれかいいサイトなり書籍なり教えて・・・
0008名無しさん＠お腹いっぱい。
03/07/09 19:57ID:wCmp9XwB独学じゃ限界もあるだろうし。
なんかいい練習法ないかな？
0009名無しさん＠お腹いっぱい。
03/07/09 20:00ID:qxLW72KXミリオンゴッドで稼ぎたい人はいませんか？
攻略法でも体感機でもありません。一日十万はいけます！
(私自身も三人グループで八十万いきました★)
詳しい内容については確実に連絡の取れるメールアドレスで
god-game@jp-q.ne.jpまでお願いします。
量産タイプのコピー品と違い、数に限りがありますので稼ぎ
たい人はお早めにどうぞ！！！
0010あぼーん
NGNG00117
03/07/09 22:02ID:wCmp9XwBデータモデリング基礎講座―データベース設計を楽しもう! DB Magazine SELECTION
http://www.amazon.co.jp/exec/obidos/ASIN/4798101109/qid%3D1057755191/249-8156321-9557966
実践的データモデリング入門 DB magazine selection
http://www.amazon.co.jp/exec/obidos/ASIN/4798103853/qid%3D1057755316/249-8156321-9557966
業務別データベース設計のためのデータモデリング入門
http://www.amazon.co.jp/exec/obidos/ASIN/4534032501/ref=pd_sim_b_dp_1_4/249-8156321-9557966
ちなみに今手元にないし、全部カバーかけて表紙覚えてないので、
感想はすぐかけません。であ。
0012名無しさん＠お腹いっぱい。
03/07/10 09:51ID:QyUEwDARデータモデリング基礎講座 はすごくわかりやすかった。
でもあれに出てくる書き方であるシュレイアーメラー？（T字型というやつなのか？）
ってはやってんでしょうか？
手元のVisioじゃあの書き方はできないし
0013名無しさん＠お腹いっぱい。
03/07/10 13:49ID:EwRs8XaCT字形いいよ。漏れは7年ほどやってる。設計品質の確保には便利。
でも書籍だけだと細かいところで悩むので、お金があるならセミナーを
受けるといいかも。漏れは受けたことはないし、自己流でアレンジしてる。
ちなみにツールはErwinでIDEF1Xでやってる。考え方がT字形ってことで。
多分佐藤氏からすれば邪道なのだろうが、納期に間に合い品質と性能が
出れば、それで良いのだよ（ｗ
0014名無しさん＠お腹いっぱい。
03/07/12 10:31ID:/MBRqZ7d対話形式の内容なので、イメージがしやすい。
モデリングの入門者にはいい本だと思う。
http://www.amazon.co.jp/exec/obidos/ASIN/4797321296/qid=1057970961/sr=1-1/ref=sr_1_2_1/249-9336605-0510750
0015あぼーん
NGNG0016名無しさん＠お腹いっぱい。
03/07/13 13:43ID:vNL7QqBWvisioって6万くらいでしょ？
ほかのは？
0017名無しさん＠お腹いっぱい。
03/07/13 13:59ID:???ageるな！
ヴォケッ！！
ドラゴンボール厨が寄ってくるだろ！
0018名無しさん＠お腹いっぱい。
03/07/13 14:08ID:???体中に広がるパノラマー
001916
03/07/13 14:41ID:???0020名無しさん＠お腹いっぱい。
03/07/13 18:30ID:???>>17-19の流れに思わず笑ってしまった。
0021名無しさん＠お腹いっぱい。
03/07/13 22:45ID:???尊敬される
0022名無しさん＠お腹いっぱい。
03/07/13 22:46ID:???0023名無しさん＠お腹いっぱい。
03/07/14 17:48ID:???ﾌﾟﾁﾜﾛﾀ
0024名無しさん＠お腹いっぱい。
03/07/18 12:07ID:SKq247KI0025名無しさん＠お腹いっぱい。
03/07/18 21:54ID:QjpeAqCT２ちゃんねるｐ http://www11.plala.or.jp/mg916/
こっちにも来てください！！
0026名無しさん＠お腹いっぱい。
03/07/23 12:53ID:???また、練習方法とかあったら教えてください。
0027あぼーん
NGNG0028あぼーん
NGNG0029あぼーん
NGNG0030DB2世 ◆rsm9sTjowQ
03/07/23 23:00ID:???はじめたほうがいいよ。
あとDBと書くと今の時期 ドラゴンボール設計って感じに
見られてしまう。。。（わけないか）
0031ヶ ◆/iQf.Br2tM
03/07/23 23:21ID:BWf0c5MjずばりAccess。会社でOracleのCDがゲットできるなら家のPCにインストル
してそれで遊ぶことも出来ます。この場合もAccessと併用して取り扱うと
能率が向上します
（SQL PLUSかナニかでクエリーを投げる→出てきた結果とAccessで覗き見ている
テーブルのデータを比較等）
会社にOracleなどのソフト類がない場合，自宅で練習にはとりあえずAccessでしょう。
自分で買ってもそれなりに安い
（そうしなくても大概は会社にCDあるからそれを自宅のPCに 以下自粛）
のとヘルプがしっかりしているから。
Access‐Oracle間はクエリーの命令式等多少の違いはありますが
基本的な取り扱い方はほぼ同じです。
データベース設計の一番の肝は データをどう整理していくか なので
（俺の意見ですがどうなんですかね）表領域の取り方とかそういう
カコイイことは色々習熟してから手をつけたほうがいいでしょう。
0033あぼーん
NGNG003426
03/07/28 08:09ID:???Oracleは、勉強しようとおもって一時OTN Pro入ってたから、
開発用ライセンスを持ってます。
勉強したいのは、DBに依存しない部分についてです。
このスレタイにあるような、モデリングなんかを覚えたいのですが・・・
Accessも、Office2000 Proがあるので、触れる環境ではあるし、
ちょっとしたものなら作れます。
正規化なんかもちょっとはかじりました。
しかし、その前の段階をどうやって勉強すればいいのかわからないんです。
DFDなんかも覚えてみたはいいものの、どこでどう使えばいいのかもよくわからないし・・・
>>32
DB2は、見たことすらないです・・・
0035ぼるじょあ ◆ySd1dMH5Gk
03/08/02 05:00ID:???ﾋﾟｭ.ｰ （ ・３・） ( ＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
＝〔~∪￣￣￣∪￣￣〕
＝ ◎――――――◎ 山崎渉&ぼるじょあ
0036名無しさん＠お腹いっぱい。
03/08/03 02:20ID:???WEB+DB Pressの11号「RDBMS再入門」中々参考になった。
お勧め。
0037名無しさん＠お腹いっぱい。
03/08/07 12:51ID:???へ～・・・ってｫｨ！完売じゃねぇかYO！
ttp://www.gihyo.co.jp/magazines/wdpress/archive/Vol11
0038名無しさん＠お腹いっぱい。
03/08/08 23:35ID:???まじで。
数日前に近くの書店で見かけて買ったんだけど。
渋谷のBook1にもあったと思う。
003936
03/08/11 09:44ID:???0040名無しさん＠お腹いっぱい。
03/08/11 17:41ID:???0041名無しさん＠お腹いっぱい。
03/08/13 20:25ID:???T字型？このスレで紹介されてた書籍に載ってたような・・・？
今手元にないんで、あとでISBNとか晒す。
0042名無しさん＠お腹いっぱい。
03/08/13 21:37ID:???http://www.amazon.co.jp/exec/obidos/ASIN/4798101109/qid%3D1057755191/250-1323438-1825824
これですよね。
これは持ってるんです。
他に分かりやすい本ありますか？
やっぱりコースを受講するしかないのかな。
「論理データベース論考―データ設計の方法:数学の基礎とT字形ER手法」
http://www.amazon.co.jp/exec/obidos/ASIN/4883731340/qid=1060778023/sr=1-1/ref=sr_1_2_1/250-1323438-1825824
この本は難しくて・・・
0043山崎 渉
03/08/15 23:02ID:???│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
0044名無しさん＠お腹いっぱい。
03/08/17 00:27ID:???http://www.sdi-rad.com/index2.html
0045名無しさん＠お腹いっぱい。
03/08/23 16:45ID:???１）モデルをカテゴリー化するときってどんなときですか？
パートと従業員の例だと解りやすいのですが、逆にこれだと区分つけた方が
理解しやすくないですか？
２）１：NのリレーションでNが依存エンティティの時、Nの外部キーって必ず主キーにしなくては駄目？
教えて君で申し訳ないですけど、よろしくお願いします。
0046名無しさん＠お腹いっぱい。
03/08/24 12:22ID:???２）依存だと主キーになっちゃうだろうな。漏れはいつも非依存で設計してる。
どっちも漏れ流なので、IDEF1Xの正道としてどうかというのはわからん。
0047名無しさん＠お腹いっぱい。
03/08/26 13:24ID:fop7qkdOhttp://www.modelcreator.com/
ってどうでつか？
$150 程度と手頃そうなんでつが。
0048名無しさん＠お腹いっぱい。
03/08/26 15:25ID:fop7qkdO埋め込んでしまう。
0049名無しさん＠お腹いっぱい。
03/09/09 11:39ID:RCsLfec9http://www.molips.com/jp/
0050名無しさん＠お腹いっぱい。
03/09/16 13:27ID:nh/rX7Clどういう風に単品在庫＆売上管理してのでしょうか？
単純に店員が人力でディスカウントという名の売上レコードを挿入するだけだと
ミスは多そうだし、粗利率や回転率なんかも後々で必要になるとややこしい話になりそうなので
以下のようなこと考えてるのですが、王道みたいなのがあれば教えて下さい。
＊売上明細テーブル＊
品番 名 基本単価 値引 値引後単価 個数 金額 値引コード
1 靴下A 500円 157円 343円 x 2ヶ = 686円 A
2 靴下B 500円 157円 343円 x 2ヶ = 686円 A
3 靴下C 500円 157円 343円 x 3ヶ = 1029円 A
4 靴下D 500円 157円 343円 x 4ヶ = 1372円 A
5 靴下E 500円 157円 343円 x 5ヶ = 1715円 A
6 傘A 1000円 0円 1000円 x 2ヶ = 2000円 NULL
---------------------------------
合計 7488円
＊値引の157円は値引テーブルを検索する
＊値引テーブルの内容＊
値引コード 個数 値引合計金額 値引単価
A 1ヶ 0円 0円
A 2ヶ 0円 0円
A 3ヶ 500円 166円
A 4ヶ 500円 125円
省略
A 16ヶ 2500円 157円
売上明細.金額など正規化でわざわざテーブルに値を保存しなくてもいいものも
説明の為含めています、あしからず。
0051名無しさん＠お腹いっぱい。
03/09/16 14:06ID:???わからんけど、それはデータベースのやることじゃなくて、
売上げ管理ソフトのプログラムがやることではなかろうか。
005250
03/09/16 15:46ID:Fb2G3tFnそうです。実際の値引き額のSETは
売上げ管理ソフトのプログラムからUPDATE系のストアドなどを叩こうと思うのですが
データモデリングで王道のサンプルみたいながあれば知りたかったのです。
あとマクドナルドのバリューセットなんかはどうなってるのだろう？
とかはデータモデリングの範疇じゃありませんか？
とりあえず、上記に載ってる本のどれか買って色々なSample見てみます。
0053名無しさん＠お腹いっぱい。
03/09/16 17:36ID:???なんかセット用のフィールドを作った気がする。
詳しいことは忘れた。
0054名無しさん＠お腹いっぱい。
03/09/16 17:57ID:???0055名無しさん＠お腹いっぱい。
03/09/18 00:06ID:YP920n31クラス図とは、全く違ったものになると思うのですが、
UMLとER図の連携?というのは、どうなのでしょうか？
まったく別物として考えるのでしょうか？
たまに、本で、クラス図を利用して、データベースを、表現したりしているものもあるのですが、
どのような、使い分けをするものなのでしょうか？
0056名無しさん＠お腹いっぱい。
03/09/19 13:48ID:9kTuVrlLER 図も書ける EA 使うってのは？
http://www.sparxsystems.jp/
あと、買ったっきり読んでないのでわからんが（をひ）
「データベース設計のための UML」参考になるかもね
http://www.amazon.co.jp/exec/obidos/ASIN/4798103675/
0057名無しさん＠お腹いっぱい。
03/09/25 09:08ID:inMyKwMQ以下の２つはよさげなんだけど、日本語のハンドリングにちょっと難点があり。
■DDS-Lite
http://www.chillisource.com/
http://www.dds-lite.com/
現在正式リリースされているのはライト版のみ。フルセットの Pro バージョンは
開発中。現在、ダウンロード版が特売価格で $79.95
ライトバージョンでも、DFDを扱える。（でもリーバースエンジニアリング機能はない）
ER図の日本語表示はなんとかなるが、ダイアログはだめ。
リソースはいろんなところに分散していて直すのが面倒。
また、無理矢理２バイトコードをぶちこむと落ちることがある。（うーむ）
■CaseStudio2
http://www.casestudio.com/
フルセット版で $329 ER、DFD （ライト版は DFD 非対応）
ER 図そのものに日本語の表示は可能なものの、ダイアログボックスが全滅
リソースいじろうとしたが、変な実装で、フォント名かえると、起動できない。
005857
03/09/25 10:26ID:inMyKwMQだけで、日本語のハンドリング問題なかったよ。安いんで、とりあえずレジスト。
使い物になるかな？
0059名無しさん＠お腹いっぱい。
03/09/29 22:53ID:???三足セットを別商品にして\1,000の単価をつけ、
三足セットの内訳「靴下×3」を部品表構造で表現するのは？
0060NAME IS NULL
03/10/15 09:17ID:???在庫と商品を別テーブルにすればいいんじゃないかな？
0061NAME IS NULL
03/11/04 14:38ID:???0062NAME IS NULL
03/11/07 01:58ID:???データの発生源から entity を抽出してゆく方法は、
目からうろこでした。
0063NAME IS NULL
03/11/15 00:38ID:6MpuOD/N0064もでるConflict
03/11/26 23:03ID:y70urj7V正規化違反せずに実装する例が示されていません。継承属性を含むモデルを正規化違反せずに実装する
例を示せる人いますか？（もちろん著者は示せるだろうが）教えてください。例えば、p153 図5●将来の日別在庫推移
を管理する、における（商品C）は継承属性を含むモデルとして挙げられます。
0065NAME IS NULL
03/11/30 09:27ID:pfYVgiCCトリガーとか使って関連テーブルから
読み込ませるとか？
0066NAME IS NULL
03/12/04 23:24ID:fvR2Sp9qいいホームページとかないですかねえ？
ITアットマークとか見てるのですが
モデリングに関してはなかなかないですね。
0067NAME IS NULL
03/12/06 18:45ID:PHxQoDnUこれ、リバースエンジニアリングしたのをさわった後、
実際にテーブル構造を書き換えるにはどうすればいいのでしょうか？
0068いなむらきよし
03/12/09 13:42ID:90H4pzxx0069NAME IS NULL
03/12/10 21:34ID:6/7ibqHE会社で社員が部門に所属しているのを表すとき、
社員（社員コード、氏名） 部門（部門コード、部門名） 所属（社員コード、所属部門コード）
のようになるようなんですが、T字型でないERの場合は
社員（社員コード、氏名、所属部門コード） 部門（部門コード、部門名）
となると思うのです。
T字型ERでは所属というのを設ける理由はなにでしょうか？
0070NAME IS NULL
03/12/10 23:27ID:fNZKjiUj社員が一人が複数の部署に配属される場合以外は
あまり必要がないような気がしますね。
0071NAME IS NULL
03/12/10 23:51ID:???社員と部門の間に依存関係が存在するかどうかの違い。
部門に所属しない社員が許容されるならば、必然的に上の形になる。
所属部門コードにNULLを許して下の形の社員テーブルとする場合は、
概念スキーマ上の社員と所属を結合したものと考える。
あとは>>70の言う通り、所属の主キーを何にするかによっても
表現するものが変わる。
007269
03/12/12 08:56ID:???データの状況や考え方次第ということですね。
0073NAME IS NULL
03/12/12 17:06ID:yh7D7A4gうーん、納得できないなあ。
部門に所属しない社員がいるとしても、社員が最大ひとつの部門にしか
所属できないとしたら、概念レベルでも「所属」は必然的ではないと思うな。
概念レベルでそういうエンティティを設けてそのまま実装したら、
ひとりの社員が複数の部門に所属しないための余計なコードを書かなきゃ
いけなくなるからね。
0074NAME IS NULL
03/12/13 17:11ID:???>概念レベルでそういうエンティティを設けてそのまま実装したら、
>ひとりの社員が複数の部門に所属しないための余計なコードを書かなきゃ
>いけなくなるからね。
なんで？制約で表現できると思うのだが。
0075NAME IS NULL
03/12/15 09:38ID:8oMPv+z7「所属」にどんな制約を組み込めば、
複数の部門に所属する社員が登録されるのを
避けれるんだろう。
0076NAME IS NULL
03/12/15 19:35ID:???社員キーをユニークにするんじゃだめなんか？
0077NAME IS NULL
03/12/15 20:01ID:8oMPv+z7社員コード＋所属部門コード
になるんではないのかな。
もしユニークキーが社員コードだけだと
すると、「所属」ってのは「社員」とキー
がいっしょってことになるな。
所属部門コードがＮＵＬＬではありえないなら
「所属」って意味ないような気がするんだが。
0078NAME IS NULL
03/12/16 23:03ID:???>もしユニークキーが社員コードだけだと
>すると、「所属」ってのは「社員」とキー
>がいっしょってことになるな。
>所属部門コードがＮＵＬＬではありえないなら
>「所属」って意味ないような気がするんだが。
「社員」「部門」はエンティティ、「所属」は「社員」と「部門」間の
リレーションシップを表現している。
意味がないと思うなら、>>71の言う通り、論理設計の段階で
結合してしまえば良い。
0079NAME IS NULL
04/01/01 20:26ID:???そのモデルだと所属が変わったときにその事実がどこにも残らないだろ。
モデリング対象の会社に社員の所属変更があるのなら、
配属イベント（配属コード、社員コード、部門コード、配属日）を置く。
そこから所属（＝指定日付における所属状態）がすべて再現できる。
0080NAME IS NULL
04/01/02 00:33ID:???そりゃ要件しだいだな。
履歴が必要ならそういう設計もするだろうが、必要ないなら
徒にトランザクション性能を下げるだけだし。
結局のところ、業務分析した結果にそれが現れるかどうかだろう。
0081NAME IS NULL
04/01/02 00:34ID:mdzOBQVK（健康体） （喘息）
1.（神が喘息であるかないかを決める）
2.K 喘息でない人 A 喘息の人は
は体力がある 体力がなくなる
3.K A 行動力、
五感（嗅覚）が鈍り感性が変化する
4.K&A 神は異常な感性の人間は本来人に迷惑をかけ
るから外に出てはいけないと思っている。
5.K 変化なし A アトピーになる
6.K 正常な感性 A 外に出なくなりさらに異常な感性になる
7.K 正常な人間 A 異常な人間（レッテル）
0082NAME IS NULL
04/01/02 08:01ID:???「業務分析」の結果に配属履歴が現れるかどうかは、「業務」によって決まる。
だから「モデリング対象の会社に社員の所属変更があるのなら」と言ってる。
業務は個別アプリケーションの都合で変わりはしないからな。
分析結果に履歴形式が現れた場合に、実際に履歴テーブルとして実装するかどうかは
設計段階で決めることで、トランザクション性能云々はこのときに考えること。
>>69-78はそういうことを踏まえずに、
配属イベントをすっとばして所属の話だけをしてるから、
それはおかしいっつってんの。
0083NAME IS NULL
04/01/02 09:56ID:???>「業務分析」の結果に配属履歴が現れるかどうかは、「業務」によって決まる。
これは問題ないが、
>だから「モデリング対象の会社に社員の所属変更があるのなら」と言ってる。
ここがおかしい。所属変更があるということとその履歴が必要というのは
要件としてイコールじゃないから。
だから>>79が最初に言っている
>そのモデルだと所属が変わったときにその事実がどこにも残らないだろ。
これが必要かどうか次第なわけ。
実際、一人の社員が複数の部署に所属し得るという事実を表現するのには
>>69のモデルで十分だし、それは所属変更がありうるとしても変わらない。
0084NAME IS NULL
04/01/02 15:13ID:???>>>69のモデルで十分だし、それは所属変更がありうるとしても変わらない。
うーん、やっぱり設計と業務分析の区別がついてないね？
>>69のは、テーブル設計（設計の成果物）としては有りだが、
モデル（業務分析の成果物）としてはおかしいんだよ。
ここはモデリングのスレだろ。
0085NAME IS NULL
04/01/03 01:01ID:???>>>69のは、テーブル設計（設計の成果物）としては有りだが、
>モデル（業務分析の成果物）としてはおかしいんだよ。
おーい、>>69が業務分析だと言っている香具師がどっかにいたか？
もしかして「モデリング」＝「業務分析」とか？
つか、>>84にとっては「業務分析」と「テーブル設計」の間って
ないのかよ？
>ここはモデリングのスレだろ。
そう。データモデリングのな。
0086NAME IS NULL
04/01/03 05:06ID:???T字ERを>>69自身が持ち出しているんだから、分析の文脈で捉えるのが自然だろ。
>もしかして「モデリング」＝「業務分析」とか？
>
>つか、>>84にとっては「業務分析」と「テーブル設計」の間って
>ないのかよ？
？？？ なんでこう話がかみ合わないかな…。
もしかして>>85はT字ERを知らないんじゃない？
0087NAME IS NULL
04/01/04 02:19ID:???T字型ERは業務分析だけで使うもんじゃないだろうに。
まぁそれは言葉の問題だとしても、分析フェーズのoutputってのは
要求分析を経てシステム境界等が明確に定義されているべきもの
なんで、要件と無関係に>>79のような断言はできるはずがない。
純粋に業務分析の話ならば、社員の所属変更というごく一般的な
プロセスについてなんらかの言及ができてもおかしくはないと思うが、
誰も最初から>>69がそういう意味での業務分析のことだと思って
いないし、>>69自身そのつもりじゃないだろう。
もともと業務分析じゃないものを「業務分析としておかしい」と言われ
ても意味不明だし。
とりあえず>>84の
>>>69のは、テーブル設計（設計の成果物）としては有りだが、
>モデル（業務分析の成果物）としてはおかしいんだよ。
これだけじゃ何も言っていないのと同じだから、具体的にどう
おかしいのか説明してくれないかい？
確かに俺はT字型ERは使ったことがないしよく知らないけど、
業務分析から設計までスムーズに落とし込めるという謳い文句の
T字型ERで、逆にそこのところの明確な切り分けをどのように
行うのか興味があるしな。
0088NAME IS NULL
04/01/06 04:42ID:???>誰も最初から>>69がそういう意味での業務分析のことだと思って
>いないし、>>69自身そのつもりじゃないだろう。
そうか、>>69自身が業務分析のつもりが全くないということが、
まだサワリの段階だったら十分ありえるわけだね。了解。
具体的にどうおかしいのかの説明かあ。
困ったな、俺にとっては自明なことなんだよ。T字型ERを算数にたとえると、
「算数では1+1=10になるようなのですが、なぜ10になるのですか？」
という質問のどこが具体的にどうおかしいのか、と聞かれてるような感覚。
でも「1+1は算数では2が答えだから、10になるという仮定は違うよ」という
言い方は算数を知らない人には絶対うまく伝わらないよね？
なので、どう説明したらいいものかと。
うまくできるかわからんが、T字型ERの体系をざっくり解説してみようか？
別に、T字型ERマンセー、って主張するわけでもしたいわけでもないけれど、
変な誤解（>>69のいう「所属」がT字型ERで普通に導かれる、というような）は
解きたいとは思うんだ。
0089NAME IS NULL
04/01/08 00:54ID:???>>79の「配属イベント」が必要という話じゃなくて、>>69の「所属」が
余計だという話をしてたわけね。
>なので、どう説明したらいいものかと。
要は「T字型ER」での「業務分析の成果物」にはなんらかの「禁則」が
あって、>>69はそれに反している、ということだろう？それを一言で
指摘してもらえば済む話かと思ったんだが。
というか、具体的に、ってのは
>変な誤解（>>69のいう「所属」がT字型ERで普通に導かれる、というような）は
>解きたいとは思うんだ。
というようなことををはっきり書いてもらえばそれでよかったんだが。
0090NAME IS NULL
04/01/09 03:45ID:???>あって、>>69はそれに反している、ということだろう？
そういうこと。回りくどくてすまん。
0091SS
04/01/15 00:32ID:???実装については何ら言及していないと理解してる。
Ｔ字型でモデリングした後、実装で
社員コード・名前・部門コード
部門コード・部門名
なんて実装もありだと思われ
－－－－－－－－－－－－－－－－－－－－－－
Ｔ字型マンセーの解説キボン
0092NAME IS NULL
04/01/15 12:38ID:???もう一回ちゃんと本を読め
論理モデルと物理モデルの乖離を否定するのがT字形だぞ
0093SS
04/01/16 00:38ID:???それは幻想と思ってる。もう３回読んだよ（ｒｙ
プライマリーキーがどれになるかがわからないリソースや
イベントの例に悩んでいてこう結論つけた。このまま実装す
るなら全テーブルに連番でも振らないと実装出来ない予感。
ＤＷＨ（データマート）やチューニングの話がミスディレクション
になってるんだよきっと。佐藤さんは推理小説好きなんだろう
「論理データベース論考」のＰ１９８にこうある
・対照表を実装するのかしないのか、という点を判断する
・サブセットについては、最上位のセットと・・するのかを判断
・ＶＥについては、派生源のentityに戻して実装するのか・・判断
結局、実装では属人性を排除出来ていないじゃん（ｗ
まあそれでＴ字形の偉大さが毀損されると思わないけど、
本だけでチャレンジした人はきっとＳＤＩにコンサルを依頼
するしかないのかも。毎度あり～
0094NAME IS NULL
04/01/17 14:09ID:???ビジネスに出てこないアイデンティファイアを導入したらアウトでしょ。
どういうので悩んでいたのか言ってみて？
俺は論理データベース論考は何十回か通読したけど、
SDIやヒューネットのコンサルもセミナーも受けてない。
考え方を身に付けるのが目的だから、
特定のツールを売り込まれたりしたら嫌だし。
確かに、実装の属人性排除はT字形ERの謳い文句には入ってないね。
DBMS側の技術導入で実装には新しい解が出てくるから、普遍化できない。
（例えば今ならサブセットはORDBMSのテーブル継承で実装できるとか。）
だから、実装にあまり突っ込まないT字ER手法の態度は真っ当だと思うが、
実装まで全部を体系化して欲しいと思う人には物足りないかもね。
0095NAME IS NULL
04/01/17 15:58ID:???この人は何を言っているのだ？
0096age
04/01/18 21:26ID:oePWTAbL実用書でなく単なる学者のたわごとだと言ってるのかな？
何十回も通読しないとわからないのは実用書ではないからね。
0097NAME IS NULL
04/01/20 00:49ID:???神か仏だな。
まぁ、神や仏は他人を馬鹿にしたりはしないが。
俺は知ってるけど、お前ら馬鹿だなという書き込みほど役に立たないものは無い。
0098SS
04/01/21 03:37ID:???> まぁ、神や仏は他人を馬鹿にしたりはしないが。
神や仏でもないし他人を馬鹿にした覚えはないが。
今日佐藤さんに聞くと、Ｔ字形を大幅に変更したらしいよ。
今年には新書を出すと言われてたので楽しみ。実装につい
ても言及して欲しいといっておいたけど、どうなる事やら。
また数十回読むのでしょうか。大変ですね。
0099Ｔ型フォード
04/01/22 00:32ID:???> Ｔ字型でモデリングした後、実装で
> 社員コード・名前・部門コード
> 部門コード・部門名
> なんて実装もありだと思われ
ちょっとマジレスすると、サブセットを上位テーブルに実装
するのは「アリ」だが、対照表を上位に実装するのはルール
違反だと思われます。
Ｔ字形って、プライマリーキーを意識せず実装するっての
が信条のように思ってます。ＤＢによって違うでしょうが、
連番を振ってプライマリーにするのも「アリ」でしょう（多分）。
0100NAME IS NULL
04/01/22 19:44ID:???> 今日佐藤さんに聞くと、Ｔ字形を大幅に変更したらしいよ。
> 今年には新書を出すと言われてたので楽しみ。実装につい
> ても言及して欲しいといっておいたけど、どうなる事やら。
へぇ～。新書が楽しみだ。期待したいな。
0101
04/01/25 23:31ID:HFlIdygC0102NAME IS NULL
04/01/27 11:18ID:???銀の弾など無いんだし、お前がそれで納得のいく仕事ができればそれでいいじゃないか…
0103NAME IS NULL
04/01/27 23:50ID:???探しているのは銀の弾ではなくガンド・ロア クラスの兵器かと。
0104NAME IS NULL
04/01/31 03:52ID:???なんだが。
http://fabforce.net/dbdesigner4/
メニューとか英語なのは痛いが、一応日本語も(難あり)使えるし、
モデリングには結構いいツールなんで、使ってみてくれ。
Delphi使える人とか、日本語化してくれると尚良いなぁ。
0105NAME IS NULL
04/01/31 04:51ID:???SIとかさ。
〔商品Ｍ〕 商品Ｃ 販売単価 仕入単価
~~~~~~
ABC \300 \200
カラー・サイズがないならこれで充分でしょう。
ところがこれで販売管理を作って運用すると
大変な事がわかります。商品数が5000件もある
ならまず間違いなく運用出来ません。
－－－－－－－－－－－－－
年１回半分ほども単価変更が発生すると徹夜
作業になってしまうのです。さてどうしましょ？
0107NAME IS NULL
04/02/13 00:00ID:???0108NAME IS NULL
04/02/13 17:07ID:???長年の疑問だが、商品マスタの単価の扱いは、どうするのがベストなのだろう。
COBOLの時代なら、同一レコードに単価項目を２つ（新旧）持ち、適用年月日
で判断するというのが一般的だったけど。
厳密に正規化すれば、単価は、商品マスタとは別に、
商品単価マスタ｛商品コード、適用年月日、単価｝を作ることになるけど、
この場合、適用年月日の判断が入るため、SQL一発で単価を取得できない。
そこで、ストアド・ファンクション使ったりするのだけど、内部的には結局カーソル
処理を行うことになる。
一方、旧来のCOBOL的なレイアウトだと、OracleならDecode関数で、一発取得
可能となる。他の製品でも、これは、可能だろう。
ただし、単価の履歴は２世代しか管理できない。
要件にもよるだろうけど、この辺、みんなどうしてるのかな。
0109NAME IS NULL
04/02/13 22:16ID:???なんで？
0110NAME IS NULL
04/02/13 22:48ID:Y1CFmVqe>厳密に正規化すれば、単価は、商品マスタとは別に、
>商品単価マスタ｛商品コード、適用年月日、単価｝を作ることになるけど、
「単価」を繰返し項目ととらえないなら、正規化違反じゃないよ
エンティティをリソースとイベントに分ける考え方からいうと、
全項目に日付を入れるとイベントに近くなってしまう
ホストだと、過去データの洗い換えするためにそういう実装
することがあるけど、バッチ処理をなくす方向で考えた方が、
パソコン（鯖）向きだと思う
0111108
04/02/14 00:32ID:???え、できるの？
できるなら、ぜひそのSQLを教えて欲しい。
>>110
＞「単価」を繰返し項目ととらえないなら、正規化違反じゃないよ
漏れもそう考えてたんだけど、最近、佐藤正美氏の本を読んで（まだ理解が浅いけど）、
むしろ、商品単価エンティティはeventと考えるべきなのかなという気がしている。
「eventの定義は、「DATE」が帰属するentityである、とする。」だそうだ。
読み違いの可能性も強いが・・・・。
別にT字型ER手法をマンセーするつもりはないけど、佐藤氏の本は色々考えさせられる。
0112NAME IS NULL
04/02/14 09:17ID:CE18kft9:問い合わせ年月日 時点の単価を求めたい場合
select A.商品名, B.単価
from 商品マスタ A
join 商品単価マスタ B on ( B.商品コード = A.商品コード )
where A.商品コード = :問い合わせ商品コード
and B.適用年月日 <= :問い合わせ年月日
and not exists (
select * from 商品単価マスタ
where 商品コード = A.商品コード
and 適用年月日 <= :問い合わせ年月日
and 適用年月日 > B.適用年月日
)
0113108
04/02/14 16:02ID:po36sjDoThanks！！！
確かに、やってみると出来る！
でも、理屈が理解できん（泣
Exists、Not Existsを勉強し直そう。
0114108
04/02/14 16:51ID:po36sjDoきっと、知ってる人にとっては当たり前の手法なんだろうけど、凄いなあ。
こういう方法があるとは。
Not Exists内のSQLは、主キーのみ参照なので、アクセスも軽い。
重ね重ねThanks>>112
0115NAME IS NULL
04/02/15 00:59ID:EVaACx4p>「eventの定義は、「DATE」が帰属するentityである、とする。」だそうだ。
本では、従業員マスタの例があったと思うけどイベントだととらえる
のは「入社イベント」であってマスタじゃない
佐藤さんの言うDATEを文字通りとらえると、全部のエンティティが
イベントになるよ。更新日付くらい全部に持つからね
「適用日付」でなく「登録日」が重要な意味をもつならイベントだろう
けど、やはりこれはリソースととらえるべきだとおもわれ
ただ、Ｔ字形でどうなるかはわからない。乞詳しい方
0116NAME IS NULL
04/02/15 22:14ID:???更新日に関する記事
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
単価変更に関する記述はなかった。
0117NAME IS NULL
04/02/15 22:58ID:fM+BL24Tスレ違いで申し訳ないです。
こっちのほうがシンプルでよさそうな気がするけど、、、ダメ？
select A.商品名, B.単価
from 商品マスタ A
join 商品単価マスタ B on ( B.商品コード = A.商品コード )
where A.商品コード = :問い合わせ商品コード
and B.適用年月日 <= :問い合わせ年月日
order by B.適用年月日 desc;
レコード数の抑制は
PostgreSQL、MySQL だと LIMIT句、SQL Server だと top が使える。
0118NAME IS NULL
04/02/16 00:35ID:???どのへんが？
>>104
MySQL用じゃないのか？
>>117
1票
> >>112
> こっちのほうがシンプルでよさそうな気がするけど、、、ダメ？
結果は同じだけど、order ｂｙを使うと普通コストが高い
１０万件程度のデータを作ってテストすればわかる
（はず・・実装によって違うから）
0120NAME IS NULL
04/02/21 02:48ID:yCOAnZGtメリット・デメリットとかご存知ですか？
マイナ～な手法なんでしょうか
0121NAME IS NULL
04/02/21 19:49ID:???椿さんの本を買って読め
0122NAME IS NULL
04/02/22 13:50ID:/gnEdeW3過去の苦い経験からオーム社ってのが信用
出来ないのですが・・・書評も１件しかないって
のは終わってる本なんじゃないですか
http://www.doaplus.com/
こういう学術的な（？）会と２ｃｈは無縁でしょうか
どなたか参加されてます？
0124
04/02/26 08:20ID:qvDCVOss600ページくらいまで、洋書でもまったく構いません。
DOAのプロジェクトにアサインされるのですが、
自分がずっとやってきたオブジェクト指向の方法論と比べて
何が共通して何が異なるのか、一通り押さえておきたいのです。
自分はオブジェクト指向の信奉者で、
構造化設計やDOAはその過程として歴史程度でしか学んでいません。
オブジェクト指向設計で言うところのユースケース、ドメインモデルは、
DOAではどのフェーズで何として書くのかが特に知りたいところです。
0125124
04/02/26 08:21ID:qvDCVOss・機能要求、非機能要求を項目として列挙する。
→ 要求定義だから変わらないと思う。
・業務フローを描く
→ 変わらない(自分はアクティビティ図で描いていた)
・ユースケース図を書く
→ コンテキスト図に相当？
・ユースケースのシナリオを書く
→ DFDのバブルの仕様として記述？
・ドメインモデルを抽出する
→ 新業務に対するER図に相当する？しかし振る舞いを描けない
・ドメインモデルの状態遷移を記述
→ 変わらない
● 特に分からない疑問
・ユースケースからDFDを導くのなら理解できるが、DFDからユースケースを導けるのか
シナリオは、DFDのバブルに対する説明として記述する？
・ユースケースシナリオ(外部から見た、システムの振る舞い)は、どの時点で決めるのか
DFDでは「システムがどう動くのか」は分かるかもしれないが、
「ユーザーがどのようにシステムとコミュニケートするのか」は分からないと思う。
0126NAME IS NULL
04/02/27 00:37ID:Pd0YyzCW0127NAME IS NULL
04/02/27 22:42ID:jks+KnjA>600ページくらいまで、洋書でもまったく構いません。
ＤＯＡは日本の文化です。歴史と伝統が必要な技です。
米国人には無理です。
ＤＯＡはビジネスを知らないと本当にはわかりません。
生産管理に興味があれば
「生産管理・原価管理システムのためのデータモデリング」
が一押しです。どういうビジネス的要件からどういうモデリング
になるかが丁寧に解説されています。
ただ、これには正規化の方法論が書かれていません。同じ著者の
「業務別データベース設計のためのデータモデリング入門」の
前半は実務で使うための初心者向け解説になっています。
たった３つのルールだけで、完璧な正規化（１～５＆BC)にする
秘伝も書かれています。たぶんこれは著者オリジナルでしょう。
0128NAME IS NULL
04/02/29 16:02ID:???商品名の履歴が必要なシステムで、
:１年前の年月日 時点の商品名を求めたい場合
はどうしたらいいですか。結構複雑になりそうな気がしますけど。
無視されてるのじゃなくて、答える必要を感じてないんですよ
求めたい日付を「問合せ年月日」に入れるSQLですから、
求めたい日付がわかってるなら困ることないですね(*^ーﾟ)b
0130128
04/03/04 08:49ID:???全然問題ないですね、問い合わせ年月日が１年前でも。
失礼しますた。
現実の業務だと、売上の「前年同曜日比較表」ってのがあったりします。
曜日によって売上が大きく違いますから「同日比較」だと意味ないのです
こんなのは流石にSQLで書けないでしょう
0132(゜Jし゜)
04/03/04 23:28ID:???うるう年のチェックをしてなかったので、先月末に大パニックになったらしい。
Windows2000のSP2でも、ある操作をすると日付が２／３０
になるっているバグがあった。それよりはましだろ
２／２９が日曜だったので大きな混乱がなくてよかった
0134NAME IS NULL
04/03/11 16:00ID:???各年の基準日をテーブルに入れておけば
基準日からの日数を計算してSQLで処理できそうだけど
そんなに甘いもんじゃない?
0135NAME IS NULL
04/03/25 00:07ID:SVaksVzX0136NAME IS NULL
04/05/23 22:43ID:???0137NAME IS NULL
04/06/29 00:24ID:4yFnbnwy部門コード、勘定科目コード、繰越残高貸借区分、繰越残高、当年借方第１月金額～当年借方第１２月金額、
前年第１月実績金額～前年第１２月実績金額
・・・とまあ基本がこんなんで、これにさらに配賦と予算（当年・前年で各月ごと）を入れると
物凄い長さになるんですが、こういうものなんでしょうか？
やはりカラムに年や月を作ってレコード分けてしまうべきなんでしょうか？
どなたか有効な意見をいただけると幸いです
0138NAME IS NULL
04/06/29 07:07ID:???データの発生元が異なる物を同じテーブルに入れない方が良い.
0139137
04/06/29 20:40ID:???部門、勘定科目、会計年度、繰越残高貸借区分、繰越残高、借方金額1～１２、貸方金額１～１２
0140NAME IS NULL
04/06/30 01:09ID:???借方金額、貸方金額は別テーブルから導出できない？
導出可能なデータはViewでもってもテーブルにもたない方が良い.
よほど速度を気にする場合は別だが.
総勘定元帳 ってのは 記録媒体 だよね？
記録媒体の項目を単純にテーブルにマッピングしてはだめだよ.
データ発生源が何かをちゃんと考慮してあげないとデータ再利用性が低下する.
0141137
04/06/30 03:14ID:???いちいち計算させるのはどうかと思ったのでテーブルに持たせた方がいいかなあと
まあ、元帳や試算表を出すのは月次と決算の時ぐらいだから個々の勘定を画面に出す時の
速度に問題がなければ、わざわざテーブルに持たせる必要はないんでしょうけど・・・
0142NAME IS NULL
04/06/30 06:21ID:???>> いちいち計算させるのはどうかと思ったのでテーブルに持たせた方がいいかなあ
正規形をくずすのは後で良いと思われ.
Viewとして計算させた値を保持させとけば良いのでは？
テーブルとして持たなくても良いとおもわれ.
できるだけデータはプリミティブに保持させておいた方が.
まずはデータをプリミティブに保持したテーブル群から作成したViewで 総勘定元帳View 作成しておく.
正規形くずしてもView定義が変更されるだけで、プログラムには影響ないようにするのが良いのでは.
0143NAME IS NULL
04/06/30 07:04ID:???あと個人的経験よりのアドバイス.
もしも元の考え通りに借方金額等を同じテーブルに入れるなら、別のプリミティブデータのテーブルからコピーする事になるだろう.
だが、ここでプルグラムを作成させるなよ.どうしてもやりたいならトリガでやれ.
とにかくやつらにプルグラムを作成させるな.
借方金額をいちいちプリミティブテーブルからView上で再計算させる速度なんてたいした事はない.
やつらの作成した 元帳View から帳表を出力するプルブラムの方がよっぽど遅い.
0145NAME IS NULL
04/07/04 01:59ID:SPlLydxxとりあえず、俺が設計するなら一生使いたくないのだが。
クラスタキーの利用頻度、メリット・デメリットを知りたい
0146NAME IS NULL
04/07/08 22:31ID:???0147NAME IS NULL
04/07/08 23:59ID:???>> 俺が設計するなら一生使いたくないのだが。
なぜ？
クラスタ化は検索中心の複数テーブルをJOINする場合に速度上の利点がある.
わたしの場合は第4正規化あたりまでする(正確には最初から第4正規化されてい
る状態で設計する)ので、更新は早いが検索が遅くなる傾向にある.
その場合にクラスタ化する.
>146
使い用.
0148NAME IS NULL
04/07/09 00:09ID:???>146
T字形だよ.良くまちがえられるけど.
DBの知識にしたがった方式.
知っているのと知らないでは格段に違うのは確かだけど、そのまま信じきるのもどうかと思う.
DATARUNと併せて知っておいた方がいい方法論.
最近はアジャイルデータベースとかオブジェクト指向方面からの方法論もいろいろあるようだ.
0149NAME IS NULL
04/07/23 10:53ID:???r;ｧ'N;:::::::::::::,ｨ／ >::::::::::ヽ
. 〃 ヽﾙ1'´ ∠:::::::::::::::::i
i′ ___, - ,. = -一 ￣ｌ:::::::::::::::ｌ
. ! , -＝=､´r' l::::::/,ﾆ.ヽ
ｌ _,, -‐''二ゝ ｌ::::l fﾞヽ |、 ここはお前のER図じゃねえんだ
ﾚー-- ､ヽヾﾆ-ｧ,ﾆ;＝、_ !:::l ） } ト
ヾ¨'７"ry､｀ ｰﾞ='ニ,,,｀ }::ヽ(ノ 「ラピュタ」の中にでも書いてろ
:ｰゝヽ､ !´ "￣ 'l,;;;;,,,.、 ,i:::::::ﾐ
::::::::::::::::ヽ.-‐ ﾄ、 r'_{ __)｀ニゝ、 ,,iﾘ::::::::ﾐ
::::::::::::::::::::Vi／l:::V'´;ｯ`ﾆ´ｰ-ｯ-,､:::::`"::::::::::::::;ﾞ , な！
:::::::::::::::::::::::::N. ﾞ､::::ヾ,.｀二ﾆ´∠,,.i::::::::::::::::::::/／／
:::::::::::::::::::::::::::::l ヽ;:::::::::::::::::::::::::::::::::::::::::::／ ／
::::::::::::::::::::::::::::::! :|.＼;::::::::::::::::::::::::::::::／ ／
0150NAME IS NULL
04/09/10 21:46:17ID:???新作マダー？
0151NAME IS NULL
04/09/20 19:27:25ID:6Fl/7m0xただの矢印でなくリレーションの種類によって
蛸足とか丸印とか付いてるのを見かけます。
あれはどうやったら出せるのでしょうか？
0152NAME IS NULL
04/09/22 12:16:06ID:???0153NAME IS NULL
04/09/24 16:52:16ID:AXzql5sY顧客コード・顧客名・担当１・担当２・・・担当５
とするか、
顧客コード・顧客名
担当コード・顧客コード・担当
というふうに２テーブルに分けるか、どうしたものだろう。
担当者の最大値が決まっている場合には繰り返し項目にならないと
思うので（違ってたら指摘して！）、正規化違反にはならないと
思うのだが、作ろうとしてるテーブルの列数が40位になりそう
なので、分けたほうがいいのかしらんと迷ってます。
0154NAME IS NULL
04/09/24 17:40:43ID:???プログラミング局面では、最大値が決まっていようがいまいが正規化されてるほうが楽な事が多いよ。
担当者が3人以上いる顧客を抽出・・・ってな要件が出たとき、横に長いテーブルだとﾏﾝﾄﾞｸｻ
あくまで例えだけど。
0156NAME IS NULL
04/09/25 01:29:10ID:axxmUZh0でも担当者を横一列に並べようとする時に
正規化するとめんどくさいですね。
明細がぶらさがるとかじゃなくて
5人って決まってる場合は
そういう出力の仕方の方が多くないかな。
でも>>154の要件もあるかも知れないし
出力する局面でどっちにするか判断するって
ところじゃないでしょか。
0157NAME IS NULL
04/09/26 00:57:28ID:???出力する局面で正規化するしないを判断するなんて論外。
・担当者別顧客リストなんて間違いなく要件の中にあるはずだが、どうやって実現する?
・とある担当が辞めた場合どうする?
全ての顧客マスタの担当項目1-5を検索して、該当する顧客レコードを更新。
更新箇所以降の担当項目の前詰め処理。
↑5人横に並べるのとどっちが面倒くさいよ?
素直に正規化しておくべき。
>>154
> 最大値が決まっている場合には繰り返し項目にならない
そんなことはない。
「最大値が100だから繰り返し項目じゃないです。」
って言われても納得できないだろ?
0158156
04/09/26 10:22:16ID:Etehnh4k繰り返し項目の正しい定義ってなんだろうね。
俺っちは、最大値が決まってる場合、担当1・担当２・・・というふうに
2次元の表にできるから、繰り返し項目にはならないのかと思ってた。
0159156
04/09/27 10:26:37ID:p0HsFnJ6うーんそうか、流石に5人ともなると前詰とか考えなきゃいかんわけか。
実は俺がやったシステムは担当者は2名だったんで
正規化してませんでした（設計は別の人）。
2名だと正・副のニュアンスもあるからあえて正規化しなかったって
話かも知れなかったですね。うーん。
0160NAME IS NULL
04/10/08 07:13:32ID:???最大値が決まってるというのは幻想で、実は今だけってのが現実
0161NAME IS NULL
04/10/08 07:15:55ID:???て制限するのが普通
0162NAME IS NULL
04/10/08 07:16:48ID:???0163NAME IS NULL
04/10/08 07:52:30ID:???ユーザーにやさしくエラーを返してあげるためにプログラム側での工夫も必要？
0164NAME IS NULL
04/10/08 10:05:34ID:h796f5Kmそれはこっちでちょっと話題になったな
↓
制約っていらなくね？
http://pc5.2ch.net/test/read.cgi/db/1087483786/l50
悩みどころだね。
0165NAME IS NULL
04/10/09 01:08:08ID:???制約エラーが発生すればエラーメッセージを出すようにはプログラムする
普通のエラー処理のある言語なら問題なく可能
制約でのエラーの方がプログラムをほぼしなくて済むので良い
とにかくやつらと、そしてわたしにプログラムさせるな、が基本である事にかわりない
プログラムは組めば組むほどバグが増加する物、それはだれが作成してもだ
0166NAME IS NULL
04/10/09 14:07:44ID:WoYiUuS/C/Sの業務アプリなんかだとそう理想どおりいかないんですわ。
例えば、必須項目の入力チェックをする時に、
エラー表示を閉じたら自動的に
未入力の入力欄にフォーカスを移動して欲しいって
要望があった場合、アプリ側でチェックせんといけない、
NOT NULL制約のエラーだけに頼れないんですよ。
とはいえ、制約はそれをみればドキュメントが貧弱だったとしても
設計した人の意図が浮き上がりやすいので捨てがたい。
で、制約・アプリ両方盛り込むと二重管理になる。
どうしたもんかなあ、ってところで上のスレは止まってる。
0167NAME IS NULL
04/10/09 16:04:43ID:???DB側の制約(CHECKとかNOT NULLとか)は制約内容とDB設計者の好みに寄る希ガス
漏れはビジネスルール的なものであればアプリ側でかけさせて
それ以外はなるべくDB側でかけさせるようにしてるかなあ
まあ、NOT NULLなんかは二重管理になりがちだけど
0168NAME IS NULL
04/10/09 16:12:21ID:???すればいいんじゃない？
0169NAME IS NULL
04/10/10 13:02:37ID:???DBMSの制約情報を動的に読みとってアプリ側でチェックするような仕掛けを
作ればいいのでは?
結局は二重だけどDBMS側をいじればアプリ側も追従してくるようにすれば
目的は達成できる気がする。
0170NAME IS NULL
04/10/10 14:11:41ID:???↓
ライブラリ/ミドルウェア層にまとめちゃおう
↓
だったらDBMSの制約情報読み取るよりも、最初からこっちで
管理した方が融通が利いて良いよな
SAPとかそんな感じだよね
0171165
04/10/10 19:39:45ID:???わたしの所はあるアプリでDB定義を書くのだが、そこからSQLと
Valid用XMLが自動生成されるようになっている
0172NAME IS NULL
04/10/17 20:38:10ID:gvma0fXW相談に乗ってください。
たとえば次のようなテーブル群があるとします。
部署(部署ID, 部署名)
社員(社員ID, 社員名)
所属履歴(所属履歴ID, 部署ID, 社員ID, 所属開始年月日, 所属終了年月日)
社員は時を経るにつれて所属が変わるのですが、
これは所属履歴レコードを1件追加することで示します。
ここで、経年するごとに次のような変化がおきます。
・部署名が変わる
・部署が統廃合される
・部署が分裂する
このとき、ある社員の部署所属履歴をうまく保持するにはどうすればいいでしょうか。
思いつく案は次のとおりです。
(1) 部署と部署情報履歴に分ける
部署(部署ID)
部署情報履歴(部署ID, 開始日, 終了日, 部署名)
(2) 所属履歴レコードを作成する時点で、部署テーブルの情報をコピーする
所属履歴(所属履歴ID, 部署ID, 部署名, 社員ID, 所属開始年月日, 所属終了年月日)
どうするのが一般的なんでしょうか。
またどうするのが楽なんでしょうか。
0173NAME IS NULL
04/10/18 01:10:05ID:???0174NAME IS NULL
04/10/18 09:55:59ID:???一般的な方法として、やるとしたら(2)だけど、本当にそこまでする必要が
あるのかどうかって所が一番大事だと思われ
0175NAME IS NULL
04/10/18 16:18:02ID:???名前・メールアドレス・パスワード・他色々
生徒
名前・メールアドレス・パスワード・担当先生・他色々(先生と全く同じパラメータ)
という構成の場合どういう設計にすべきですか？
(1)
先生
先生id(主キー),名前,メールアドレス・パスワード,他色々
生徒
生徒id(主キー),名前,メールアドレス・パスワード,先生id(外部キー:先生->先生id),他色々
(2)
人
人id(主キー),名前,メールアドレス・パスワード,他色々
先生
先生id(主キー),人id(外部キー:人->人id)
生徒
生徒id(主キー),人id(外部キー:人->人id),先生id(外部キー:先生->先生id)
(3)
人
人id(主キー),名前,メールアドレス・パスワード,他色々
先生
人id(主キーかつ外部キー:人->人id)
生徒
人id(主キーかつ外部キー:人->人id),先生id(外部キー:先生->先生id)
(4)その他
0176NAME IS NULL
04/10/18 16:19:18ID:???人
人id(主キー),名前,メールアドレス・パスワード,他色々
先生
人id(主キーかつ外部キー:人->人id)
生徒
人id(主キーかつ外部キー:人->人id),先生id(外部キー:先生->人id)
0177175
04/10/18 16:19:55ID:???0178NAME IS NULL
04/10/18 16:53:31ID:???(4)
0179NAME IS NULL
04/10/18 18:17:57ID:???具体的にはどんな感じですか？
0180NAME IS NULL
04/10/18 22:19:10ID:???その前に他色々を具体的にしてくれ。
0181NAME IS NULL
04/10/19 06:30:22ID:???所属履歴IDって必要か？
まあそれは良いとして、部署の統廃合を管理するだけなら部署expire期間を入れるのはどうか
実質173と同じ意見だけどIDは同じにできる
# 良いかどうかは別
0182NAME IS NULL
04/10/19 08:44:54ID:???要件次第でどれが適切かは変わってくると思われ。
生徒でも先生でもない人をシステム上扱う必要があるのなら、人テーブルを
分けた方がいいかもしれない。その必要がないのなら(1)で十分だと思うよ。
0183NAME IS NULL
04/10/25 23:05:28ID:0Gqq1XjYデータモデリングって何ですか？
データベースのテーブルのカラムを考える人？
0184NAME IS NULL
04/10/26 00:49:47ID:???データベースのテーブルとカラムを考える事。
渡辺幸三先生の本を読んでみましょう。
0185NAME IS NULL
04/10/26 01:10:00ID:???顧客の業務を視姦して丸裸にしてヌードデッサンする行為の事。
0186NAME IS NULL
04/10/26 01:25:51ID:???0187NAME IS NULL
04/10/26 14:10:28ID:???わりと死姦だったりするがな。
0188NAME IS NULL
04/10/26 17:08:53ID:???0189NAME IS NULL
04/10/27 00:51:41ID:???異様にデブだったり極端にガリガリだったり、それ以前に
奇形なモデルだったりする事がおおいからなｗ
0190NAME IS NULL
04/10/27 15:12:50ID:???0191NAME IS NULL
04/11/18 19:46:59ID:oOnWd0J7作成出来るエンティティ数とか？
0192NAME IS NULL
04/12/15 10:40:56ID:???なにかうまい方法ないでしょうか･･･ ○|￣|＿
【 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 …;
0193NAME IS NULL
04/12/15 10:41:12ID:???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
0194NAME IS NULL
04/12/25 22:54:27ID:ZtSP5EZKいいクリスマスを迎えることができてるといいのだが。
さて・・・どう「うまく」やりたいんだろ？
パフォーマンスの改善？
今後に備えて、データモデル（テーブルの実装も含め）を見直したい？
それとも？
そもそも、
・データモデル自体を見直したいなら、ＳＱＬ書かれても困る
・ＳＱＬを評価して欲しいなら、テーブル定義くらい無いと、マンドクセェ
・データの件数によっても、モデルは変える事がある
んだ。ヨロシコ。
0195NAME IS NULL
04/12/27 18:29:20ID:???（レスを頂けた事に、正直驚いています）
テーブル定義のフォーマルな表記方法はわからないのですが、
部品とその構成情報は、
┏━━━━━┓ ┏━━━━━━━━┓
┃部品 ┃ ┃品目- 品目_ 再帰 ┃ ┏━━━━━┓
┃----------┃ ┃----------------┃ ┃部品_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で管理 ）
を、アクセスクエリを数段かませ、
列が在庫受払いと同じになるように変換しました。
0196NAME IS NULL
04/12/27 18:29:42ID:???ユニオンクエリで結合しました。
これにさらに、
子部品があるかどうかの判定列 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件
です。
0197NAME IS NULL
04/12/27 18:45:20ID:???製造にかかる日数をうまく格納・計算する方法が思いつかないので、
とりあえす展開１階層ごとに長めの標準日数を設定し、
部品展開時に、出荷予定日から遡った日に部品が出庫（消費）する、
というふうになるよう、受払い日時を設定しました。
0198NAME IS NULL
04/12/27 19:19:44ID:???出荷予定表：100件強
（済のものを含めると7～800件）
でした。
0199NAME IS NULL
05/01/14 00:57:27ID:???これは SQL99の「再帰的SQL」を使う以外にないだろう．
http://www.atmarkit.co.jp/fnetwork/tokusyuu/01sql99/sql99_1b.html
つまり，現行のほとんどの DBMS では，手続き型の言語で書いた再帰構造に
短い SQL を大量に埋め込むしか方法がないと思われる．
それにしても，なぜ今まで，SQL に再帰が導入されなかったのだろうか．
SQL とおなじ宣言型言語である Prolog では，再帰は不可欠なのに．
0200NAME IS NULL
05/01/17 11:13:03ID:???レスありがとうございました。
0201NAME IS NULL
05/01/18 01:25:16ID:dY4jJ9fs渡辺幸三さんの生産管理のモデリングの本を読んでください。
ＬＬＣ（ローレベルコード）について詳しく書いてあります。
私の知っている限り生産管理のモデリングの最良の本です。
在庫推移のモデルに関しても詳しく書いてあります
いいところまで行ってるので頑張って
0202東浩紀
05/01/18 18:39:56ID:O7G91VlXつまり人は物語に感動してるのではなくデータベースから抽出された物に反応しているにすぎない
つまり世界はこういう仕組みになってる
0203NAME IS NULL
05/01/18 19:50:06ID:???アドバイスありがとうございます。
実は、その本はたびたび読み返して手本にしています。
モデリング自体も問題大有りですが、
再帰ＳＱＬの代わりになるコーディングが思いつかない段階です。
0204NAME IS NULL
05/01/20 03:13:45ID:TW1nlZVfなぜスクリプトで組まないの？
0205NAME IS NULL
05/01/20 22:59:44ID:TW1nlZVf孤軍奮闘しているようですね。渡辺さんの本の愛読者だと
いうことで、アドバイスしましょう。VBAが使えないときついかも
ＬＬＣを良く理解されていないようです。こういう自体を避ける
魔法のコードです。ステップを以下のように３つに分けて、それ
ぞれの中で細かい処理を悩めば道は開けると思います。
★問題が解けそうにない時は小問題に分割するのが定石です
以下簡単にモデルを提示してみます
0206NAME IS NULL
05/01/20 23:01:36ID:TW1nlZVfモデル：
[部品] {部品Ｃ}、品名、現在庫数、製造ＬＴ、ＬＬＣ
[部品構成] {親部品Ｃ、子部品Ｃ}、員数
[日次受払] {部品Ｃ、日付}、入庫数、製造数、出庫数、在庫数
計算手順：
(1)[日次受払]の内容をクリアしたうえ、いろいろなテーブルに
散らばっている現在の入出庫予定（出荷予定、製造予定、
入荷予定）を[日次受払]に集計する
(2)ＬＬＣの小さい部品順に、[日次受払]の製造数を[部品構成]
を使って（製造ＬＴで日付をずらしながら）シングルレベル展
開して、下位部品の出庫数として[日次受払]に反映させる
(3)部品毎に、[部品]の現在庫を起点として[日次受払]の日付
順に入出庫数を加減計算しながら在庫数を更新する
(4)最初の欠品日が早い品目順に対策を検討する
欠点：
このバッチ処理を走らせないと最新の状況に応じた在庫
推移がわからない。状況にリアルタイムに反応する「在庫
推移監視方式」が渡辺本（生産管理・原価管理システムの
ためのデータモデリング）で紹介されているので、参考に
してください
0207NAME IS NULL
05/01/21 15:25:20ID:???>>206
ありがとうございます！！
ＬＬＣの小さい順に展開することで、階層を最後まで展開しきることが出来るというわけですか！
目からうろこが落ちた思いです。
これから渡辺さんの本を再び読み返して理解していきたいと思います。
0208NAME IS NULL
05/01/22 01:08:18ID://zf7D53お役に立ててよかったです。渡辺本の３冊の中で私は
生産管理が最高だと思ってます。この他にもノウハウが
惜しげもなく載っていて驚くほどです。
※ところが一番売れてないと噂で聞きました
確かに難しいですが、あれだけSQLを書けるのですから
必ず理解出来ます。頑張ってください。
基本的な方針をお教えしただけですので、まだまだ
悩まれるところは豊富でしょうが、悩み甲斐ありますよ
もしこれで利益を得る事が出来れば、コンサルフィーと
していくらでも結構ですからスマトラ募金して下さいね
0209NAME IS NULL
05/01/23 20:56:09ID:+1Ab9Bdi0210NAME IS NULL
05/01/27 09:36:44ID:Z5JcZ2YJこの場合、運送料と手数料はテーブルを分けるべきか分けざるべきか。
どうですか皆さん？
（分ける場合）
[請求] 請求ID・顧客ID・金額
[運送料]請求ID
[手数料]請求ID
（分けない場合）
[請求] 請求ID・顧客ID・金額・区分コード
0211NAME IS NULL
05/01/27 12:29:02ID:Ff4IZNHF[請求顧客] 請求ID・顧客ID
[請求金額] 請求ID・金額
[運送料] 請求ID
[手数料] 請求ID
ならあるかな。
0212NAME IS NULL
05/01/27 13:17:27ID:???請求IDと運送料、手数料はそれぞれ一対一の関係なんでしょ?
だったら
[請求] 請求ID・顧客ID・金額・運送料・手数料
でいいんじゃない?
0213NAME IS NULL
05/01/27 13:22:42ID:Ff4IZNHFもっともPrologで書くと、
請求書(_顧客ID,_請求書ID)
:-
請求書(_請求ID,_請求書ID),
請求顧客(_請求ID,_顧客ID),
( 運送料(_請求ID),
請求金額(_請求書ID,_金額),
write_formatted('運送料 %t\n',[_金額]);
手数料(_請求ID),
請求金額(_請求ID,_金額),
write_formatted('手数料 %t\n',[_金額])
),
fail;
true.
でどうってことないが。
0214NAME IS NULL
05/01/27 13:39:52ID:Ff4IZNHF請求書発行(_顧客ID,_請求書ID)
:-
請求書(_顧客ID,_請求書ID),
<<以下略>>
にしないとね。
0215210
05/01/27 14:41:00ID:???請求が10件あったとして、運送料の請求が5件で手数料の
請求が5件かもしれないし、運送料の請求が10件で手数料の
請求が0件かもしれないといった感じです。
0216NAME IS NULL
05/01/27 15:02:24ID:???[請求] 請求ID・顧客ID・金額・運送料・手数料・合計金額
運送料・手数料どちらかをゼロにしとけばいいんじゃない。
0217NAME IS NULL
05/01/27 18:01:12ID:Ff4IZNHFIDが必須でうるさくなる。ただ、Prologとの相性はいいなあ。
うんと小さな規模のデータベースではデータの結びつきについて
敏感になれて面白いかもしれない。
<分けない場合>はRDBそのものだが、行の中の列の結びつきが「以前的」で
ちょっと強すぎる。なんらかの「契機」によって結びついていると考えられるが、
やはり、神様がいる感じ。
0218NAME IS NULL
05/01/28 00:09:12ID:GLvUf9Afprologなんてまだ生きてたのか。うざいね
> やはり、神様がいる感じ
電波受けてる？
0219NAME IS NULL
05/01/28 03:58:05ID:???[支払予定]は、見出単位で決定する場合と、明細単位で決定する場合の
２通りあるんですが、この場合のテーブル設計はどうすればよいだろう？
[発注見出] 発注NO、支払予定NO
[発注明細] 発注NO、行番、支払予定NO
[支払予定] 支払予定NO
こんな感じでいんだろうか？
なんかすっきりしないんだけど・・・・・・もう、まる一日以上なやんでます .... orz
0220NAME IS NULL
05/01/28 07:49:44ID:???発注と支払いの間に、債務とかなんかのテーブルを一つはさんだらどうかな？
0221NAME IS NULL
05/01/28 09:13:10ID:???[発注見出].支払予定NO≠[発注明細].支払予定NOの場合があるから、
[発注見出] は発注NOだけでいいんじゃない。
0222NAME IS NULL
05/01/28 13:18:05ID:???債務を挟むって具体的にどんな感じになるんでしょう？
>>221
これも考えたんですが、結局はプログラム側でちゃんと整合
取れるように制御しなきゃだめですよね～。
0223NAME IS NULL
05/01/28 18:13:41ID:???[発注見出し]+---≡[発注明細]+---≡[入荷明細]
[入荷見出し]+---…[入荷明細]+---…[仕入明細]
[支払見出し]+---≡[支払明細]+--･+[仕入明細] （ここ自信無し）
明細単位で決定する場合、支払に明細行が１行、
見出し単位で決定する場合、支払に発注と同じ複数の行、
でいいのかな…？
勘定とかも絡んできそうな気がしてますます複雑に… ○|￣|＿
0224NAME IS NULL
05/01/29 03:03:56ID:iJcNI0vI業務モデルによるでしょう。[支払予定]が何をしたいのか、
支払予定NOがどのタイミングで発生するかなどを示さないと
勝手に解釈したレスになりますよ。
一番汎用的なのはこんな感じかな
[発注見出] {発注NO}、取引先CD、発注日、納品希望日
[発注明細] {発注NO、行番}､品番、単価、数量
[支払発注対照表] {支払予定NO、(,発注NO)}
[支払予定] {支払予定NO}、支払い予定日、取引先CD
発注先のCDと支払先のCDが違うことは良くあるので[支払予定]
にも取引先CDを入れました。もし単に締日単位に１つの番号を振る
のならこれは不要
ただ、実務で使うなら納品（検品）のデータと関連させないと
納品されていないものまで支払う可能性があります。
-------------------
渡辺幸三さんの「業務別データベース設計のためのデータ
モデリング入門」の購買管理にはもっと実用的なモデルが示
されていたと思います（今手元にないので曖昧です）
0225NAME IS NULL
05/02/01 11:58:45ID:???これからもちょくちょくご登場キボンヌ．
俺はへぼい Lisper(Schemer) で，最近データモデリングを
かじり始めたのだけど，どうにもDB の世界は，閉鎖的で
息苦しくてかなわん．他のプログラミング言語との比較という
視点が全く欠けていると思う．
SQL は Prolog の親戚みたいなものなんだから，並べて
語れば，視野がぐっと広がると思うんである．
0226NAME IS NULL
05/02/02 23:11:26ID:???渡辺幸三さん、XEAD。いいです。
これがフリーソフト。信じられない。
http://homepage2.nifty.com/dbc/index.html
0227NAME IS NULL
05/02/03 01:17:55ID:???本当に凄いフリーソフトですね。open sourceにして英訳すれば世界中の人が使いそう。
0228NAME IS NULL
05/02/03 02:51:03ID:???ドキュメントまでそのまんま落ちたら最高なんだけど
それは望みすぎだわなー、すばらしいですよこれわ。
0229NAME IS NULL
05/02/03 20:15:41ID:???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/
0230NAME IS NULL
05/02/03 20:34:28ID:???プログラム・ロジックから排除する」とは、たとえばどういう事ですか？
ttp://www.doaplus.com/html/doc/bun01_20041206.pdf
0231NAME IS NULL
05/02/04 00:35:00ID:EU+jfE/iそのままの意味
Ｔ字形を使うと「4,800ステップのプログラムが（「nested-IF」のない）800ステップに軽減された」
って実績もある。マスコミには出ない魔法の手法。
ttp://www.sdi-net.co.jp/ter-home.htm
0232NAME IS NULL
05/02/04 11:35:10ID:???0233NAME IS NULL
05/02/04 16:56:20ID:???なんか表現がいちいちドラスティックだなあ。
そのサイトの段位表にでてくる
● 従業員のデータのなかに、部門コードが定義されていても疑問に感じない。
● 「データの一意性」を保証するために、複合キーを使ってデータ設計をする。
これが全然ピンと来ない。
特に前者、T字形ではどういう風に表現するんだろう?
0234NAME IS NULL
05/02/04 19:45:38ID:???のようなことが書いてあったような気がします。
0235NAME IS NULL
05/02/05 01:48:17ID:Kdyo+DVNＴ字形を単なるデータモデリング手法だと思うと
火傷をします。これは哲学です。
ビジネスを定義するにあたって
１．企業として共通の認識にあるものは何か？
→番号がついているもの＝識別子
（それがユニークかは関係ない＝＞複合キー）
２．イベントとリソースの峻別
→イベントとは企業活動の中で日付があるもの
３．エンティティ間の関係（４つのルール）
４．エンティティの属性（項目）としてホノニム（同音多義）や
シノニム（異音同義）、nullになる可能性があるかを考え、
データ分析する
→サブセット（クラス概念は否定）
この４を真剣に考えると、従業員のデータとして例えば
社長なら部門はnullになるし兼務者が定義できない事に
気付くはず
ここまで分析してはじめて業務分析ができ、しかも
プログラムからロジックが消える（らしい）
0236NAME IS NULL
05/02/07 18:37:02ID:???0237NAME IS NULL
05/02/07 22:26:05ID:UdrSQ9Qj1.4.1_03でも漏れは動いたよ
まあ全部の機能を試したわけじゃないが
0238NAME IS NULL
05/02/25 17:14:43ID:???データモデルパターン
http://www.jsys-products.com/iwaken/data_model_patterns.html
0239NAME IS NULL
05/02/25 21:12:10ID:???0240NAME IS NULL
05/03/01 17:08:53ID:???これらをサブタイプとして登録したとき、実装上はどう処理するのでしょうか？
たとえば、ある複数機種の機械の納品リストを考えます。
機種Ａ
ノズル１からジュースが出せます。 原液タンクには４／10㍑タンクが使えますがボトルは使えません。
ノズル２からジュースが出せます。 原液タンクには1.8／４㍑ボトルが使えますがタンクは使えません。
ノズル３からは水だけが出せます
機種Ｂ
ノズル１からジュースが出せます。 原液タンクには４／10㍑タンクが使えますがボトルは使えません。
ノズル２からジュースが出せます。 原液タンクには４／10㍑タンクが使えますがボトルは使えません。
ノズル３からジュースが出せます。 原液タンクには1.8／４㍑ボトルが使えますがタンクは使えません。
ノズル４からは水だけが出せます
オプションとしてOPT1,OPT2,OPT3が付加できます。（重複可）
機種Ｃ
ノズル１からジュースが出せます。 原液タンクには４／10㍑タンクが使えますがボトルは使えません。
ノズル２からジュースが出せます。 原液タンクには1.8／４㍑ボトルが使えますがタンクは使えません。
ノズル３からジュースが出せます。 原液タンクには1.8／４㍑ボトルが使えますがタンクは使えません。
水は基本的に出せませんが、機種に関係なく使用できるオプション機材Ｗを付加することにより水も出せます。
オプションとしてOPT1,OPT2,OPT3が付加できます。（２つまで重複可能、３つ重複不可）
ジュースＸ１～Ｘ９の原液は４㍑ボトルと10㍑タンクのどちらかが選べます。
ジュースＹ１～Ｙ９の原液は1.8㍑ボトルと４㍑タンクのどちらかが選べます。
出荷前に顧客のオーダーに合わせ、各ノズルからジュースＸ１～Ｙ９を出せるように調整し、オプションを付加します。
出荷する実際の機器には機番が一台一台についており、トレーサビリティを保証したい。
納品後も、一台一台の機番から、出荷先および、ノズルに割り当てたジュースの種類やオプションの情報を管理しなければならない。
出荷と一口に言っても、設置工事を行う場合もあり、機械を発送するだけの場合もある。 出荷先でオプションを
追加・変更する改造工事もありえる。移設・撤去工事もある。それらの工事イベントについても管理しなければならない。
１出荷先に複数機種を複数台納品する場合もあれば、移設などにより履歴として納品先が複数になる場合もある。
以上のような条件があったとします。
0241NAME IS NULL
05/03/01 17:09:58ID:???機種の仕様マスタとしては、
┌ ＋[機種基本仕様] （スーパータイプ）
│
├・＋[機種Ａ特有仕様]（サブタイプ）
│
├・＋[機種Ｂ特有仕様]（サブタイプ）
│
└・＋[機種Ｃ特有仕様]（サブタイプ）
のように持つのが正しいのでしょうか？
正しいとして、マスタはそれでいいとして、
出荷する一台一台の情報は、このマスタを利用してどう保存すればいいのでしょうか？
（２）
出荷先と工事と機番との関係は、
[機材]
＋
└─≡[工事]
┌─≡
＋
[出荷先]
のようになるのでしょうか？
この辺で長いこと悩んでいます。
上に紹介のあった本にも、
似たケースのモデル例は見つかりませんでした。
何かしらアドバイスいただけると助かります。
0242NAME IS NULL
05/03/02 00:08:35ID:???機種－機種ID、最大ノズル数、オプションタイプ可/不可
ノズル－機種ID、ノズルID、タイプ(ジュース/水)、ボトルタイプ(タンク/ボトル)、タンクタイプ（1.8、4、10)・・・
ジュース－ジュースID、ボトルタイプ(タンク/ボトル)、タンクタイプ（1.8、4、10)・・・
設置した機器－機番、機種ID、出荷先・・・
設置したノズル－機番、ノズル番号、ノズルID、ジュースID・・・
出荷するジュース－出荷日、出荷先、機番、ノズル番号、ジュースID・・・
こんな感じ？
0243NAME IS NULL
05/03/02 18:18:10ID:???レスありがとうございます。
なるほど。
＞設置した機器－機番、機種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、・・・
￣￣￣￣￣￣￣￣￣
ノズル数やその他の制限は、判断材料となるデータを保存しておくまでにとどめ、
実際の判断はデータベースの制約ではなくアプリケーションが都度判断する、
というのが正解になるんでしょうか…。
また、項目が、ノズル・オプションなど限られていれば良いのですが、
他にも例えば、左正面パネルの色・本体高さ・右サブテーブルの幅・左サイドレバーの位置・中央受皿の種類…など、
機種によって管理する項目が全然バラバラのとき、
新機種がでるたびアプリケーション側で機種固有に判断するルーチンを都度追加など、
アプリケーション側の負担が際限なく大きくなりメンテ困難にならないか不安です。
履歴として出荷先が複数になる点もサポートするためには、
過去の出荷先（現在は移設等で機材が無い）の履歴データは
アプリ側で別テーブルに持つのが良いのか、
あるいは設置した機器と出荷先を多対多にするべきなのか…
アプリ側で判断してしまえばどちらでも可能そうなので余計悩んでしまいます。
0244NAME IS NULL
05/03/02 19:55:10ID:???実際のオプション内容は別テーブルにして、機種との対応表を別表に作る
（パフォーマンス度外視）。
ものによっては >>242のとおり機種の属性に持った方が適切。
この辺りの判断は要件とかも絡んでくるし、一概には言えないと思う。
> 他にも例えば、左正面パネルの色・本体高さ・右サブテーブルの幅・
> 左サイドレバーの位置・中央受皿の種類…など、機種によって管理する項目が
> 全然バラバラのとき、
本当にバラバラなら機種テーブルそのものを分割する。
親子関係を持たせるとかは自由。
履歴は開始、終了時間で管理（一応、受付時間も）。設置場所だけが変わったら
終了時間が設定されて、開始時間、出荷先が変更された行が追加される、てな具合。
[マスタ]
機種 - 機種ID、（全機種共通情報）
ノズル機能 - ノズル機能ID、ノズル機能（ジュース、水）、タンクID
タンク - タンクID、タンク容量
オプション - オプションID、オプション内容
機種ノズル - 機種ID、ノズル番号、ノズル機能ID
機種オプション - 機種名、オプションID
ジュース - ジュースID、（ジュースの情報）
ジュースタンク - ジュースID、タンクID
出荷先 - 出荷先ID、（出荷先の情報）
[履歴]
設置機種 - 機番、機種名、出荷先ID、受付時間、
設定開始時間、設定終了時間、設定状態（自社設定、客先設置、設置済み etc）
設置ノズル - 機番、ノズル番号、ジュースID
設置オプション - 機番、オプションID
※出荷数量は設置機種により導出可
※２つまでの重複可とかははアプリで。
長文ｽﾏｿ
0245NAME IS NULL
05/03/03 01:27:26ID:8HW4Dnffchar(6) にしますか？それとも date型で、必ず１日とかにします？
0246NAME IS NULL
05/03/03 01:46:48ID:1vRnt2on0247NAME IS NULL
05/03/03 18:17:51ID:???俺はdate方にする。(月初又は月末しか入らないように制約をつけて)
後に必要な項目が年月が年月日に拡張されてもいいようにね。
まぁ、余計なもの(日)がはいるしChar型に比べてDate型のほうが
サイズが大きいデータベースがほとんどなんで、その辺りがきになるのであれば
Char型もいいんじゃない？
まぁ、結局はおこのみで
0248NAME IS NULL
05/03/03 21:41:11ID:???ありがとうございます。
頂いたアドバイスを元にただいま苦悩中。
何か形になったら報告に参ります～
0249NAME IS NULL
05/03/03 22:21:33ID:???機種の仕様により選択不可能なオプションを設定しようとすると、
リレーションシップの制約によりエラーがでて設定できないような成果を期待していましたが、
いわゆるビジネスロジック層ですべき判定をデータベース層にやらせようとしている、
というような気がしてきました…
データベース層は、あくまでビジネスロジック層での判定根拠となる設定情報を保持するだけ、
が正解なのかな…
せっかく機種の仕様制限をマスターのリレーションシップで表現しても、
今のままでは履歴テーブルで機種仕様制限に反する設定値を入力できてしまう…
0250NAME IS NULL
05/03/04 13:05:47ID:???> 上に紹介のあった本にも、
> 似たケースのモデル例は見つかりませんでした。
なんだかデジャヴを感じるモデルだったので家に帰ってから調べてみたけど
「業務別データベース設計のためのデータモデリング」の"フィーチャオプション"
あたりをじっくり読んでみると幸せになれるかもしれない。
0251NAME IS NULL
05/03/04 14:54:04ID:???ありがとうございます。
フィーチャーオプション、
オーダーメイド的な面のあるものに、
どうもしっくり来ない感があるんです。
フィーチャー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
0252NAME IS NULL
05/03/04 15:38:54ID:???今回のケースでは、
複数の機種が全く同じﾌｨｰﾁｬｰ体系をとることはまれであるためです。
上のモデルでは、
派生機種明細にマスタとして設定可能な全ての組み合わせを
予め持っておくみたいなのですが、
ノズルに割り当て可能なジュースを見ると、
ジュースの種類が非常に多く、新商品と販売終了の移り変わりが激しいなどの場合、
組み合わせ数がいたずらに多くなった上、マスタメンテの手間も大変そうです。
ところで、
オプションで例えば、キャスターっていうのを考えてみますと、
（アジャスター：高さ調整可能な機械の足
キャスター ：小さな車がついて移動可能な機械の足）
機種側の制約としては、
キャスターには耐荷重があるので、
機種の基本属性に稼動時最大重量というのを持って、
これで適用可能かどうか判断しなくてはいけません。
また、重量をクリアしても、
標準でついているアジャスターの取付方式と互換性のあるキャスターしか使えません。
機械の性質上、絶対揺らしてはいけないものは、
ロック時にアジャスターが降りてくるアジャスター一体型のキャスターしか
使えないかもしれません。
本体が縦長な場合、キャスターによる移動が不安定で極めて倒れやすいので不可、
という場合もあります。
単価が安くて手間をかけたくない機種などで、
営業上の判断でオプションを適用不可にしたい場合もあります。
こういった類の制限を表現するためにはもう、
オプションのマスターで制限を文章表記した上、
適用可能かどうかを判定する、機種×オプションの表に、
予めTrue/Falseで持っておいて、
その根拠として、
その判断を下した責任者、判断日、有効期限、判断理由、特記事項などを
持たないといけない気がします。
0253NAME IS NULL
05/03/04 15:47:29ID:???機械の使用環境がわの制限もありました。
勾配が何度以上だと使用不可とか、
大理石の床に硬いキャスターは不可とか、
あるキャスターの高さ調整範囲だと機械の高さがオーダーどおりに設定できないなど…
こちらも管理しないと、
たとえば機種Aを現場Aに設置した後、
現場Aでは不要になったので現場Bに移設するようオーナーからオーダーがあった場合に、
移設可能かどうか判断が出来なくなります。
従来だと、
・下見にコストがかかる。
下見に行っても制約条件を網羅しきれず無駄になる場合もある。
・とりあえず移設しようとしたが出来なかったので、
納期に間に合わない上に後出しで追加料金発生もやむなし。
だとおもいます。
0254NAME IS NULL
05/03/04 19:24:44ID:???やはり、最終段のこれかなぁ
ttp://www.jsys-products.com/iwaken/data_model_patterns/lower.html#13
モノ（クラス）→機種、アジャスタ、ジュース、ボトル、ノズル
モノ（インスタンス）→機種Ａ、高さ調節式アジャスタ、オレンジジュース
関係
機種Ａ－ノズルＡ(可能)
機種Ａ－ノズルＢ(ダメ)
ノズルＡ－ボトルＸＸ
ノズルＡ－ボトルＹＹ
機種Ａ－高さ調節式アジャスタ(ダメ、高さが合わないから)
関係タイプ
取り付ノズル
接続アジャスタ
属性
サイズ
容量
高さ
属性割り当て
ボトル－容量
ボトル－サイズ
変数
４㍑
１０㍑
なかんじ。
0255NAME IS NULL
05/03/04 19:41:13ID:???うわ、改めてみるとすごいモデルですね、これ…
週末使って考えてみます。 ありがとうございます。
DOA＋コンソーシアムってところでメーリングリストがスタート
したみたいです。
ttp://www.doaplus.com/html/topics_20050303.html
本当に悩んでるならそこで聞いてみてはどうでしょう？
ＤＯＡの錚々たるメンバが参加されているようです。
0257NAME IS NULL
05/03/13 14:37:10ID:???とりあえず入会してみましたがメーリングリスト届きません…
（´・ω・｀）
（´・ω:;.:...
（´:;....::;.:. :::;.. .....
0258NAME IS NULL
05/03/15 02:51:06ID:???来ましたがな
0259NAME IS NULL
05/03/18 09:42:19ID:???0260NAME IS NULL
05/03/19 22:52:31ID:pW3Ejy8nえっそうなの！ 無料だから入ってみるか
0261NAME IS NULL
05/03/20 00:10:27ID:???0262NAME IS NULL
2005/04/12(火) 15:08:28ID:c/VE92X6http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=13241&forum=26&showpollresult=1&showpollresult=1
0263NAME IS NULL
2005/04/16(土) 17:28:01ID:SaaWDc/aDBには各ユーザー名と回答を格納します。
回答の値はintの0～10ぐらい（選択肢の数だけ）と予想され、
設問の数はどんどん増えていくことが予想されます。
今下記のような二つの方法を考えています。
A)設問ごとにフィールドを作る。
回答１ 回答２ 回答３ ・・・
０ １ ５ ・・・
B)回答用フィールドは一つにし、カンマ区切りなどで格納する。
回答
0,1,5,,,,
Aは設問が増えるたびにフィールドを追加しなければならないし、
Bは集計のたびに分割して値を抜き出す作業が必要。
どちらが良いでしょうか？
0264NAME IS NULL
2005/04/16(土) 18:41:34ID:???0265NAME IS NULL
NGNGユーザID、設問ID、回答 をフィールドに持つテーブルを作ればいい。
0266NAME IS NULL
2005/04/16(土) 21:46:23ID:SaaWDc/a264さん265さんありがとう。
ちなみにメールアドレスをユーザーIDにしようと考えているのですが、
それを主キーにして良いでしょうか？
それともオートインクリメントで主キー用のフィールドを
別に作ったほうが良いでしょうか？
0267NAME IS NULL
2005/04/17(日) 00:33:06ID:???kaba@prolog.com,設問2,1
kaba@prolog.com,設問3,1
とかなりますが、kaba@prolog.comのユーザーIDを主キーにするので
よいとお考えですか。
0268NAME IS NULL
2005/04/17(日) 01:09:06ID:R6dX5cU6主キーは前者だけに設定するつもりです。
こんな感じ
ユーザー情報テーブル
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
それで知りたいのは主キーを簡単な数字にした場合とメルアドのような
複雑な文字列にした場合とで検索速度に違いが出るかということです。
0269263
2005/04/19(火) 11:14:49ID:4C71pzmpおかげで投票サイトが完成しました。
http://www.kiminari.info/kokumin/
なお、不具合報告等のスレッドを作りましたので、
ご協力いただける方は、よろしくお願いします。
http://pc8.2ch.net/test/read.cgi/php/1113871597/
0270NAME IS NULL
2005/04/19(火) 11:57:10ID:8GDQE5S+検索速度については単表検索なら、簡単なコードのほうがいいと思います。
ただ、この設計だと投票結果テーブル検索時はユーザ情報テーブルをJOINするオーバヘッドが発生しますよね。
インデックス容量を考えると、コード有利です。
メールアドレスが変更される可能性があり、かつ変更後も同一人物として扱う必要があるならコード化です。
なければ、メールアドレスがキーのほうがアプリ工数は少ないかもしれません。（JOINの必要なし）
業務特性、システム特性を考えてトレードオフで考え、最良の設計を。
0271NAME IS NULL
2005/04/19(火) 19:34:30ID:???> メールアドレスが変更される可能性があり、かつ変更後も同一人物として扱う必要があるならコード化です。
実は私もこの問題で>>268を見てモヤモヤしていました。ユーザー情報テーブルですが、
001 a@a.a pass1
001 a_new@a.a pass1_new
002 b@b.b pass2
となり、ID(主キー)を維持できなくなると思うのですが。
0272271
2005/04/19(火) 20:00:55ID:???投票者はID { 001,002...}は知らない。
それで、既に投票されているかチェックに行く。そのための主キー。
とするとメールアドレス以外に主キーは考えられない。
0273NAME IS NULL
2005/04/19(火) 21:17:19ID:???0274NAME IS NULL
2005/04/20(水) 02:54:10ID:eImDdv+2いえいえ、違いますよ。
001は絶対に1レコードのままです。
変更情報は、
①「メールアドレス変更履歴エンティティ」を抽出する
②「変更前メールアドレス」項目を追加する
あたりで表現します。
純粋なデータモデルとしては①が正解とされますが
業務要件が「直近1世代の変更前アドレスだけの保持でよい」などであれば
②も現実的です。
0275NAME IS NULL
2005/04/20(水) 06:50:59ID:???0276NAME IS NULL
2005/04/20(水) 06:53:21ID:???0277NAME IS NULL
2005/04/20(水) 08:24:29ID:???いけなかった。
0278NAME IS NULL
2005/05/25(水) 01:18:49ID:???「パーティ」ってスーパーセット設けるのって実際どうなんでしょう。
よくやるのでしょうか?
0279NAME IS NULL
2005/05/28(土) 23:14:32ID:rxg+K8Bf全くの連番だと、コードを見ただけでは全然類推ができないし
使いにくいと思うのですが、コードに意味を持たせないメリットは何。
コードに意味を持たせても、切り出して判断に使わなければＯＫ？
連番は採番しやすくていいのだけれど。両方満足させる方法があれば。
0280NAME IS NULL
2005/05/29(日) 09:41:43ID:???0281NAME IS NULL
2005/06/01(水) 01:20:28ID:???伝票番号だって、車のナンバーだって、出席番号だって、電話番号だって、意味を持たないだろ。
(言葉遊びの語呂合わせなどは別として)
単に個別を識別するためのものだ。
世の中の仕組みがそうなっていることに気が付けよ。
0282NAME IS NULL
2005/06/01(水) 11:04:24ID:???電話番号は意味あるよ。
地域コード - 連番
じゃん。
伝票番号も会社によって
YYYYMMDDXXXXX
とか当たり前にある。
0283NAME IS NULL
2005/06/01(水) 16:46:09ID:???0284NAME IS NULL
2005/06/01(水) 18:37:20ID:???0285NAME IS NULL
2005/06/01(水) 19:01:57ID:???出席番号は連番だが名前の読みの50音順に並んでたりするから
そんな場合は意味を持っている、名前の読みについて少しは類推ができる、と
言えると思うがどうか。類推する側が50音順って決まりをわかってないといけないが。
転入生があると転入生は連番の最後で我慢してねとか、誰か転校しちゃうと欠番とかはあるんだろうが。
出席番号をつけるのにくじ引きで名前を引いてその順番に連番をつけるような
場合は、意味を持っていない、といえるかも。
連番であっても意味がある場合とない場合があるということではないのか。
0286NAME IS NULL
2005/06/03(金) 12:15:18ID:???0287NAME IS NULL
2005/06/03(金) 12:19:30ID:???0288NAME IS NULL
2005/06/03(金) 16:02:04ID:???0289NAME IS NULL
2005/06/03(金) 16:04:13ID:???0290NAME IS NULL
2005/06/03(金) 19:24:36ID:???＞「パーティ」ってスーパーセット設けるのって実際どうなんでしょう。
OOのやり方。DOAでは積極的にはやらない(と思う)。
0291NAME IS NULL
2005/06/05(日) 12:42:42ID:???それは、出席番号順というのではなくて、50音順という、別の意味だろ。
出席番号順のデータを作成する際に、イニシャルデータを作る手順として、
たまたま50音順にデータを投入したと言うだけだ。
だから転校生は、一番後ろになるわけで。
入学受付順、背の順、という学校もあるし、それはたまたま50音の学校が多いと言うだけ。
0292NAME IS NULL
2005/06/06(月) 10:19:45ID:???そういや転校生って、後ろにpushだったなあ・・・。
なんか懐かしくて胸キュンだ。
0293NAME IS NULL
2005/06/06(月) 14:46:53ID:???俺の学校では違ったなぁ・・・
小・中学校では出席番号は生年月日の早い順。
高校での出席番号は五十音順だった。
ただ、転校生やらが入ってきた場合はその都度、出席番号が変わっていた。
つまり、再度、生年月日やら五十音で並べ替えられる。
0294NAME IS NULL
2005/06/06(月) 15:07:48ID:???健康カードとか、下駄箱とか、出席番号を記入して1年間使う物があるのに、
えらく不便なシステムだな。
0295NAME IS NULL
2005/06/06(月) 15:07:54ID:???やばい、このまま果てしなく脱線しそうだ。
0296NAME IS NULL
2005/06/06(月) 15:13:06ID:???>293のような事態がままあるので
識別子と業務上使われる出席番号などは
別に構えるのが吉って事ですね。
健康カードテーブルと下駄箱テーブルも
これで迅速な対応が出来ると。
ただお客さんとのモデリングセッションなどで
作っていく概念レベルではIDじゃなくて
出席番号を識別子とした方がいいでしょうね。
お客さんにシステム要件はなるたけ考えさせたくないし。
実装時に生徒IDでもなんでもシーケンスでふっちゃえばいい。
0297296
2005/06/06(月) 15:24:04ID:???ちゃんと>279へのレスになったな。
IDは、意味の無い連番。
出席番号は、業務ルール（五十音順など）の意味がある番号。
とすると。
出席番号は出席簿や健康カードといった
プレゼンテーション部で、ユーザーの認識容易性が得られる。
ただ変更の可能性がある場合に大変。
IDは意味が無い分、業務ルール変更に関係なく
行の識別子として機能する事が出来る。
出席番号はプレゼンテーションの要件なんだから必要だが
識別子としては不安なので、それはIDを採用。
結局両方持っとけって事ですね。
0298NAME IS NULL
2005/06/06(月) 21:59:03ID:???ほかのテーブルから外部キーとして参照する場合は
ID？出席番号？
0299NAME IS NULL
2005/06/06(月) 23:26:34ID:???出席番号は出欠名簿リストの左端についてる番号ぐらいの利用しかなくて、
いつもは学籍番号ばっかり使ってるってことはないのか。
0300NAME IS NULL
2005/06/06(月) 23:44:49ID:???千葉？
0301NAME IS NULL
2005/06/06(月) 23:58:33ID:???IDじゃないと、297で言ってるメリットが得られないです。
途中で転校生の分、出席番号振りなおしても
下駄箱テーブルはID参照してれば影響なし。
物理的な下駄箱については、頑張って貰おう。
0302NAME IS NULL
2005/06/07(火) 01:39:29ID:???転校生が来たら 25 などを割り振ればいいだけだ。
0303NAME IS NULL
2005/06/07(火) 04:43:41ID:???＼∧＿ﾍ ／￣￣￣￣￣￣￣￣￣￣￣￣
,,､,､,,, / ＼〇ノゝ∩ ＜ 転入合戦、いくぞｺﾞﾙｧ！！
/三√ ´∀｀) / ＼＿＿＿＿＿＿＿＿＿＿＿＿ ,,､,､,,,
/三/| ﾟＵﾟ|＼ ,,､,､,,, ,,､,､,,,
,,､,､,,, Ｕ （:::::::::::） ,,､,､,,,＼ﾜｼｮｰｲ！！／ ＼ﾜｼｮｰｲ！！／ ＼ﾜｯｼｮｰｲ！！／
//三/|三|＼ ／■＼／■＼ ／■＼ ／■＼ ／■＼ ／■＼
∪ ∪ （ ´∀｀ ）´∀｀ ）´∀｀ ） ´∀｀ （ ´∀｀ ） ´∀｀ ）
,,､,､,,, ,,､,､,,, ／■＼／■＼ ／■＼ ／■＼ ／■＼ ／■＼
,,､,､,,, （ ´∀｀ ）´∀｀ ）´∀｀ ） ´∀｀ （ ´∀｀ ） ´∀｀ ）
（( （つ ノ（つ 丿（つ つ（つ ノ（つ 丿（つ つ
ヽ （ ﾉ（ ヽノ ） ） ） ヽ （ ﾉ （ ヽノ ） ） ）
（＿）し' し（＿） （＿）＿）（＿）し' し（＿） （＿）＿）
0304NAME IS NULL
2005/06/07(火) 08:55:18ID:???0305NAME IS NULL
2005/06/07(火) 10:35:19ID:???と思ったけど、表示順みたいなカラムでは
今もやってるなー。
0306NAME IS NULL
2005/06/07(火) 18:27:35ID:???来るのは9人までにしてね
0307NAME IS NULL
2005/06/07(火) 21:28:29ID:???0308NAME IS NULL
2005/06/07(火) 22:07:15ID:???／￣￣￣￣￣￣￣￣
| 転校生の織田です
＼
￣∨￣￣￣￣￣￣
∧＿∧ ／￣￣￣￣￣￣￣
∧＿∧ （ ´Д｀ ） ＜ 小田です
（ ´Д｀ ） ／⌒ ⌒ヽ ＼＿＿＿＿＿＿＿
／, / ／_／| へ ＼
(ぃ９ | （ぃ９ ./ / ＼ ＼.∧＿∧ ／￣￣￣￣￣￣￣
/ /、 / ./ ヽ （ ´Д｀ ）＜ 尾田です
/ ∧_二つ （ / ∪ , / ＼＿＿＿＿＿＿＿
/ / ＼ .＼＼ (ぃ９ |
/ ＼ ＼ .＼＼ / / ,、 （（（ ））） ／￣￣￣￣￣￣￣
/ /~＼ ＼ > ） ） ./ ∧_二∃ （ ´Д｀ ） ＜ 緒多です
/ / > ） / ／／ ./ ￣￣ ヽ (ぃ９ ） ＼＿＿＿＿＿＿＿
／ ノ / ／ / / / .＿/ /~￣￣/ ／ / ∧つ
/ ／ . / ./. / / / )⌒ ＿ ノ / ./ / ＼ (ﾟдﾟ)ｵﾀﾞﾃﾞｽ
/ ./ （ ヽ､ （ ヽ ヽ | / （ ヽ､ / /⌒> ） ﾟ( )－
（ _) ＼__つ ＼__つ).し ＼__つ （＿) ＼_つ / >
0309NAME IS NULL
2005/06/07(火) 22:16:05ID:???いいでしょうか。この方法の問題点注意点が何かあれば。
確かに意味なし連番IDを後から変更しようとは思わない。
認識容易番号では何桁目が何を表すかという意味自体が古くなったりする。
電話番号も市町村合併で市町村の枠が違ってしまえば
番号の体系と合わなくなってしまう。
新しい市町村の体系に合わせて電話番号を直して
すっきりしたいと思ってしまうようなものなのだろう。
0310NAME IS NULL
2005/06/08(水) 07:34:54ID:???随分前のWEB+DBプレスのデータモデリングの記事に
にそこらへんの事がかいてあった。
今なら全部のバックナンバーのPDFが売ってるから
読んでみるといいよ。面白かった。
意味無し連番こそ、データの識別子であって、
業務上使うコードは、ユーザーさんが使う際の便利な
アクセスパスにすぎないので、ごっちゃにしちゃ
いかんですうんぬんてな事が書いてありました。
0311NAME IS NULL
2005/06/08(水) 07:51:15ID:???べつに？
0312NAME IS NULL
2005/06/08(水) 10:15:30ID:???じゃあOracleのRowIDやPostgreのOIDを
使えばいいじゃんって話しになりそうですが
そうすると、ひょんな事からエクスポート・インポートなど
する事になったりすると変わっちゃうのでだめですねー
てな事も書いてあった。
0313NAME IS NULL
2005/06/08(水) 11:35:13ID:???WEB+DB PRESS特別総集編ってやつですね。
読んでみます。
0314NAME IS NULL
2005/06/08(水) 22:43:34ID:???出席番号はどうせ生徒を特定する識別キーにはならないのだから、
再割り振り・ケツに追加のどちらでも良い。
>>310
学籍番号で言えば、全く意味のない連番より、入学年度＋連番のほうが見やすい。
見やすいだけで、意味なし連番と違わないのだが、
違いがないのなら見やすい方が良い。
0315NAME IS NULL
2005/06/09(木) 00:38:03ID:???勿論、学籍番号は見やすいほうがいいでしょう。
ただ、学籍番号ってのは業務で用いるコード、
特定のデータへのアクセスパスな訳です。
便利なアクセスパスってだけなので、
業務要件の変化によってどうなるもんか判らんので
データをアイデンティファイする識別子とは別にした方がよい、
と言うのが主旨。
意味無し連番ってのが、その識別子にあたります。
0316NAME IS NULL
2005/06/12(日) 11:13:50ID:???関係箇所がVol.11とVol.21に出てました。
どちらも著者は羽生彰洋さん。
少し説明すると、この中では、
意味無し連番->アイデンティファイア=ID=識別子=FKで使用JOIN用
認識容易番号->ビジネス上のコード体系=アクセスパス
としており、一見さんに対する顧客コードのつけ方や、
商品開発で開発の最初でコードが決まりにくい場合の例などで、
意味無し連番と認識容易番号を分けて考えて両方採用する
ことが大事である、と。詳しくは本文を。T字形の影響も
形を変えて入っているように感じました。
(ただ、Vol.11では主キーという言葉を認識容易番号の意味で使っていて、
使い方が間違ってないかな。Vol.21では直ってると思う。)
結構詳しく説明されてます。これに反論するのは難しいか。
意味無し連番の今までの違和感が少しはなくなりました。
0317NAME IS NULL
2005/06/12(日) 23:52:13ID:???俺も意味無しID、使ってはいたし
コードの洗替が楽ってのも判ってたけど
どうしても違和感があって、
それ読んで、識別子とアクセスパスって言い方で
すっきりしました。
はぶさん、この路線で本書くのかなと思ったけど
SQLドリルってのは、やられた。
0318NAME IS NULL
2005/08/11(木) 09:34:00ID:u6wEnJIp0319NAME IS NULL
2005/08/16(火) 11:18:49ID:wzipZbWiこのスレみてWEB+DB PRESS特別総集編買ってきてました。
なるほどなぁ～と読みすすめてたのですが、一つ疑問が。
商品に対する品種。
商品に対する単位。
いままでこれらは商品マスタに品種や単位のコードを参照するように
カラムを追加していました。
しかし、Vol21p112にあるように各関係に対して交差エンティティを作成するほうが
後のためによいのでしょうか？
ちなみに作るとしたら以下のような交差エンティティを作成するのかな？
品種構造 構造ID,品種ID,商品ID 現在は1:m
単位構造 構造ID,単位ID,商品ID 現在は1:m
0320NAME IS NULL
2005/08/16(火) 13:19:07ID:???ここで聞いてみよう
http://d.hatena.ne.jp/habuakihiro/
でもまあ、システムの規模や顧客の業務内容などなどで
最適解は色々ってのが答えなんじゃないかな。
正論かつ優等生ちゃんな答えでつまんないけどさ。
0321NAME IS NULL
2005/08/17(水) 05:35:09ID:???サイト紹介してくれてありがとう。
みてみると交差エンティティはm:mの時、定義するように書いてありますね。
WEB+DB PRESS特別総集編によると、1:mでもとりあえず定義しとけとあったので
ちょっと疑問に思っていました。
私が担当するプロジェクトはそこまで大規模なものでもないので
今回は交差エンティティを定義しない方向で進めて行きたいと思います。
0322NAME IS NULL
2005/08/17(水) 10:39:17ID:???いえいえどういたしまして。
なんか偶然だけど、凄いタイミングよかったね。
規模もそうだけど、
1:mって関連がどれだけ確かなものかってのを
お客さんにしっかり聞いておくのが一番だと思います。
業界でしっかりと規格化されてるものだったり
物理的にそれい以外考えられないとかだったら
カラムにしちゃった方がいいだろうし
「今までそうだったから」とかだと変わる可能性あるから
関連エンティティにした方が良いかも知れない。
0323NAME IS NULL
2005/08/20(土) 22:14:02ID:UVFT2kPn日本語が使えない時はどんな名前にしてますか？
～マスタだと「～MST」
～のログだと「～TRN」
～と～の相互参照だと「～？？？」
私と似た様な命名規則を適用されている方、どうかお知恵をお貸し下さい。
0324NAME IS NULL
2005/08/22(月) 09:41:01ID:???そもそもサフックスにするところから議論になるぞ。
まず、プレでも何でもつけるか否か、つける場合の分類、そして略称。
そこの末端だけのことなんだから、開発者は小脇に辞書を抱えて即引きするのが常識。
命名で悩んでる時間がもったいない。
0325NAME IS NULL
2005/08/22(月) 13:32:34ID:???議論ではなく、同様ので命名規則を適用している方で
サフィックスだけでもどうやってるのかと意見をもらいたくて・・・。
何にせよ、スレ汚しごめ。
0326NAME IS NULL
2005/08/22(月) 23:01:53ID:???設計・命名者はメインフレーム出身の割と古い人。
0327NAME IS NULL
2005/08/23(火) 00:11:07ID:???貴重な情報、ありがとうございます。
早速、関係するテーブル名を連結+CRSで命名したいと思います。
0328NAME IS NULL
2005/08/23(火) 08:35:13ID:???あとで保守する人にだせーとか言われるかもよ。
0329NAME IS NULL
2005/08/25(木) 01:16:39ID:???0331NAME IS NULL
2005/08/26(金) 09:50:12ID:???あんた、センス良いね。
0332NAME IS NULL
2005/08/27(土) 00:08:36ID:???m:m確定ならそれいいね！
1:m, m:1かm:mのどちらかわからないときは"REF"だけでもよさそうだね。
0333NAME IS NULL
2005/08/28(日) 15:30:31ID:???DWHは書籍とかネットとかの情報は少ないよ。
というかね、そもそもモデリングとか正規化とか無縁の世界。
どういう切り口でデータを分析するかが目的だから、
正規化とかを ”しない” のが普通。
どうすれば必要なデータをだせるのかを最優先に考え、
その為ならば、データベースの構造がどうであってもOK。
だから、通常は業務でデータを蓄積してる、ちゃんとモデリングや正規化されたDBとは別に
DWH用のDBを別に構築して、そこへ必要なデータを夜間バッチとかで流し込む。
0334NAME IS NULL
2005/08/29(月) 17:39:42ID:???Ｍ＄のＳＱＬ鯖に付いてる。
使ってみると分かるとおもうし、
ＭＳＤＮにも資料落ちてるんじゃないかな。
要は、どんな分析をしたいのかをある程度
見極めとくことだと思う。
0335NAME IS NULL
2005/09/01(木) 22:49:42ID:3lCOPcx7現在、商品のテーブルに商品区分のフィールドがあります。
商品区分が'1'の時、計算で使用する項目は標準単価のみ(数量x標準単価=金額)。
商品区分が'2'の時、計算で使用する項目は重量、重量当りの単価。(数量x重量x重量当りの単価=金額)
商品区分が'3'の時、計算で使用する項目は縦、横、奥行、サイズ当りの単価。(縦x横x奥行xサイズ当りの単価=金額)
このような時、商品のテーブルには標準単価、重量、重量当りの単価、縦、横、奥行、サイズ当りの単価のフィールドを設けるべきでしょうか？
それとも商品区分毎に各テーブルを設けるべきでしょうか？
このシステムの前担当者は商品テーブルに全てのフィールドを設けているようですが、
ちょっとひっかかるところがあって、質問しました。
以上よろしくおねがいします。
0336NAME IS NULL
2005/09/02(金) 04:00:25ID:???標準単価は例外なく全ての商品に入りません？
商品テーブルに単位（１：個 ２：kg ３：cm^3 など）が入ってれば・・・
重量 2kg と 5kg 、あるいはサイズ 1m×2m×0.4m と 0.2mm×0.5m×0.05m とで、
商品名（商品コード）は同じですか？異なるんですか？
重量やサイズは注文ごとに計量加工して出荷するんですか？定重量・定サイズのもので在庫してるんですか？
その辺の業態の違いで変わってくるように思いますが…
0337NAME IS NULL
2005/09/02(金) 05:25:44ID:???>なぜ２に数量があって３には無いんです？
申し訳ありません。私のミスです。
仰るとおり３は数量x縦x横x奥行xサイズ当りの単価=金額となります。
>標準単価は例外なく全ての商品に入りません？
この点なのですが、各商品区分によって標準単価の少数以下の有効桁数が微妙に違うのです。
例えば１の時は少数以下無し、２の時は少数第二位等・・・。
汎用性を考えFloatやDouble等で定義すれば解決なのですが、
仕様通りの型に何とか当てはめれないかと悩んでおります。
>重量 2kg と 5kg 、あるいはサイズ 1m×2m×0.4m と 0.2mm×0.5m×0.05m とで、
>商品名（商品コード）は同じですか？異なるんですか？
重量に関しては、2kg,5kg等というような複数の重量は無いとのことです。
サイズは複数のタイプがあるようで、そのときは商品コードはそれぞれ違います。
データの有り方としては商品+標準単価又は、
商品+重量+重量あたりの単価(標準単価)又は、
商品+縦+横+奥行+サイズ当りの単価(標準単価)のようになっており、
同じ商品で重量と縦+横+奥行等が含まれることはありません。
>重量やサイズは注文ごとに計量加工して出荷するんですか？
>定重量・定サイズのもので在庫してるんですか？
この当たりは商品毎に違うようで現場の人が
重量で請求するのか計量で請求するのかを決めるようで
単に個数x単価の時もあれば、個数x重量で金額を算出したり、
サイズで算出したりとまちまちのようです。
以上宜しくお願いします。
0338NAME IS NULL
2005/09/02(金) 08:11:56ID:???数量もCurrencyで問題ないかと思いますが・・・
浮動小数点じゃ誤差が出てしまうのではないかと
0339NAME IS NULL
2005/09/02(金) 16:12:47ID:???>数量もCurrencyで問題ないかと思いますが・・・
>浮動小数点じゃ誤差が出てしまうのではないかと
商品のテーブルには数量は含めない予定です。
数量はあくまで伝票入力時に入力するものとし、標準では常に１とするからです。
>>335の
>このような時、商品のテーブルには標準単価、重量、重量当りの単価、縦、横、奥行、サイズ当りの単価のフィールドを設けるべきでしょうか？
>それとも商品区分毎に各テーブルを設けるべきでしょうか？
この点はどのように考えると良いのでしょうか？
設計１
商品のテーブル
商品コード
商品名
商品区分
標準単価
重量
縦
横
奥行
設計２
商品のテーブル
商品コード(PK)
商品名
商品区分
標準単価
商品単価１テーブル
商品コード(FK)
重量
商品単価２テーブル
商品コード(FK)
縦
横
奥行
う～ん、どっちのほうがいいんだろ？
0340NAME IS NULL
2005/09/02(金) 21:53:32ID:???複数の重量にしてもそんなこと聞いてないと思うが
0341NAME IS NULL
2005/09/03(土) 02:22:57ID:???> 汎用性を考えFloatやDouble等で定義すれば解決
> 重量に関しては、2kg,5kg等というような複数の重量は無いとのことです
>>339
> 商品のテーブルには数量は含めない予定です。
> 数量はあくまで伝票入力時に入力するものとし、標準では常に１とするからです
0342NAME IS NULL
2005/09/03(土) 02:26:28ID:???縦
横
奥行
って数量ですよ？
お客さんから寸法や重量を指定されるたびに商品を追加するとか？
0343NAME IS NULL
2005/09/03(土) 02:47:23ID:???洗剤500gビンを200本
洗剤50kg特大タンクを2個
コレが同じ値段。
じゃあ重量73gと指定して1370本下さいと言ったら
計量してビンに入れて同じ値段で売ってくれる？
アクリル板 500×200×0.2
アクリル板 400×125×0.4
アクリル板 1000×400×0.05
コレも同じ値段。
じゃあ今度は半端な数は言わない。
8000×5×0.5と指定します。
折ったら返品します。
こういう極端な例を出さないと
要求仕様をちゃんと考えてくれないのでしょうか。
0344NAME IS NULL
2005/09/04(日) 04:09:33ID:hkkDWCwFこれはRDBMS(ER図)の限界として、とてもよく出てくる典型的な問題ではないかな？
商品をオブジェクトとして保存できるのであれば、
商品基礎クラスを継承した３つの商品クラスを別途用意してしまえばいい。
でも、RDB使ってるなら当然そんなことは出来ないので、解決策としては
（１）１つの商品テーブルを作って、そこに全部の項目を用意する
（２）３つの商品テーブルを別に作る
のどちらかを採用することになる。
これらはどっちが正しいということは無くて、状況に応じて使い分ける。
テーブルを分けると後で検索にjoinを多用しないといけなくなるので、
（１）のアプローチを採用することのほうが経験的には多い
0345NAME IS NULL
2005/09/04(日) 18:53:02ID:???自分は商品基礎情報テーブルと個別商品テーブル×３を作ることが多いけど。
0346NAME IS NULL
2005/09/04(日) 19:13:35ID:???10個くらいが境界かな。
さすがにsubclass tableを100個tableを作る気はしない。
ちなみに(1)は正規化違反なんだっけ？
0347NAME IS NULL
2005/09/05(月) 08:51:17ID:???比較したメリットデメリットをあげてください。
使用するデータベースはOracle 10g
0348NAME IS NULL
2005/09/05(月) 11:23:23ID:Kv8Ouo/70349NAME IS NULL
2005/09/05(月) 12:03:55ID:???この問題、そもそもの現実のものを、どのように扱ってるかが主眼だと思う。
その３つの商品群が混在して扱われているのであれば、テーブルは１つ。
部署違いでまったく別の群をたまたま同じように扱っているのであればテーブル３つ。
データベースってのはあくまで現実の記録だから、そこを主眼にすることは大事だと思う。
で、システム上の扱いで１つにまとまってたり３つに割れてたりして困るならば、そこはViewでカバーする。
１つのテーブルをあるコードで３つそれぞれに分けて表示したり、逆に結合したり。
あと、理想論・原則論からいけば、NULLフィールドやダミー値のフィールドを設けるのは良くない。
同一テーブルでどっかのフラグがこれなら、このフィールドは何とか。
なので、本来は３テーブル分割でまとめてみるViewを提供でよいと思う。
0350NAME IS NULL
2005/09/05(月) 20:57:11ID:???>>346も言ってるが、もし3個でなくて100個だったら？
0351NAME IS NULL
2005/09/05(月) 21:27:48ID:???縦横高さなんて仕様情報を、基本マスタに、要素ごとに列を与えて載せるべきなのか？
0352NAME IS NULL
2005/09/05(月) 23:22:00ID:???多少汚くても一個のテーブルで収まってくれると嬉しい
0353NAME IS NULL
2005/09/07(水) 21:00:08ID:???ハードウエアも進化してるので理想論をもう少し追求してもよいのでは？とありますね。
なので分割したテーブル数が10未満程度なら、テーブルを分割したほうがよいのかもしれません。
0354NAME IS NULL
2005/09/07(水) 23:24:35ID:???0355NAME IS NULL
2005/09/19(月) 20:50:45ID:KI/vbbTMどのようにモデリングしたらよいのでしょうか？
例えば、次のような形のデータです。
材質,最小値,最大値
SPC270D，100，200
SPC270D，250，330
SPC270D，360，380
渡辺幸三さんが書かれた
「業務別データベース設計のためのデータモデリング入門」は読みました。
（他の2冊も読みました）
この本の中には、連続して重複しない場合の例は載っていましたが、
連続せず、重複しない例が載っていませんでした・・・。
初心者っぽい質問ですみません。
いきなりオフコンからの移行プロジェクトを
押し付けられてしまいました・・・。
0356NAME IS NULL
2005/09/20(火) 00:19:17ID:???プライマリキーはID
Uniqueキーは材質,最小値,最大値でいいんじゃない？
順序が必要なら各材質毎にNo.振って材質,No.にUniqueキーを設定するとか。
>この本の中には、連続して重複しない場合の例は載っていましたが、
>連続せず、重複しない例が載っていませんでした・・・。
この部分がよくわかりません。
データの並びを見ると、連続して重複(材質が)しているようにみえます。
外してたらすまそ。
0357NAME IS NULL
2005/09/20(火) 02:19:56ID:???お回答ありがとうございます。
俺の言う重複ってのは、例えばこんな感じです。
材質,最小値,最大値
SPC270D，100，200
SPC270D，180，330
SPC270D，300，380
どう言う事が具体的に説明してみます。
板厚ごとに単価が変ります。
材料メーカーさんの都合で、
サイズの範囲が決まっています。
例えば355の例で言いますと、
200-250ってサイズは存在し得ないんです。
俺なりには検討してみたんですが、
RDBMSの制約では実現できないんでしょうか・・・。
0358NAME IS NULL
2005/09/20(火) 05:41:11ID:???構造は>>356のような感じで作る。
その後制約したいテーブルをビューでラップ。
追加、更新時にトリガーをかませ、制約テーブルを読み取り違反していれば
クライアントに例外を投げる。
俺だったらこんな感じにする。
0359NAME IS NULL
2005/09/20(火) 10:09:33ID:???358さんのいうように、アプリ（ストアド・トリガー）の範疇だと思います。
0360NAME IS NULL
2005/09/20(火) 10:25:52ID:???0361NAME IS NULL
2005/09/29(木) 15:32:26ID:gDAO8DBJ定石的な方法をご教示ください。
各取引から次の取引に外部キーをもたせて連結リストっぽくすると、
挿入や削除でいじる箇所が少なくてすみますが、
リストが切れた場合の危険があるからよくないですよね？
各取引の表示順序を1からの連番としてもたせるとすると、
挿入や削除が発生したときに手間がかかります。
10おきとかの番号をつけて、足りなくなったら番号つけかえるのが
現実的でしょうか？
0362NAME IS NULL
2005/09/29(木) 16:03:04ID:???又は、順序カラムを数値で持っておいて、差し込み先より大きい列に対して、＋１するUPDATEで割り込み完了。
そもそもで、そういう仕様は蹴飛ばすような・・・。
順序が任意ならば表示側のソートで勝手にしてってするか、
ソートした最終結果だけ受け取ってがらがらぽんする。
0363NAME IS NULL
2005/11/30(水) 14:22:09ID:???データがあるのですが、この番号は意味のない連番なんですが
(但し、その番号を入力して該当すれば売上伝票を表示します。)
別途、意味なしキーを追加したほうがいいのでしょうか？
また、マスタに業務上のキー以外に意味なし連番を作成した場合に
売上データなどにマスタ値としていれるのは業務上のキーでOK？
業務上のキーを入力されたら、マスタを参照してわざわざ意味なし
連番をセットするのが面倒っていわれたんだけど・・・
0364NAME IS NULL
2005/12/01(木) 01:07:01ID:???> 販売管理の売上データなどで売上伝票番号がキーとなる
> データがあるのですが、この番号は意味のない連番なんですが
> (但し、その番号を入力して該当すれば売上伝票を表示します。)
> 別途、意味なしキーを追加したほうがいいのでしょうか？
どちらでもよい。
俺はシンプルなのが好きだから、必要ないときは
意味なしキーは作らない。
ただ、最近はRubyOnRailsやHibernateなど、
アプリ側のアーキテクチャの都合で意味なし連番が
効果を発揮する場合がある。
基本的には好みの問題だけど、意味なし連番をつける
メリットが明らかにあるときはつける、なければつけない
という方針が分かりやすいかもしれない
> また、マスタに業務上のキー以外に意味なし連番を作成した場合に
> 売上データなどにマスタ値としていれるのは業務上のキーでOK？
> 業務上のキーを入力されたら、マスタを参照してわざわざ意味なし
> 連番をセットするのが面倒っていわれたんだけど・・・
俺なら業務上のキーをそのままセットさせる。
一応ユニーク制約はつけておいて。
はっきりとメリットを説明できないことはやらない
0365363
2005/12/02(金) 20:53:58ID:???webアプリなどでは有効ということですね。
>俺なら業務上のキーをそのままセットさせる。
マスタのキーが変更になるとデータまで変更しなければ
ならなくなると思うのですが・・・・
でもデータを見たときにわかりやすいというメリットはあります。
どちらがいいのでしょうか。
0366NAME IS NULL
2005/12/03(土) 01:36:35ID:???このへん読んでみなはい。
0367NAME IS NULL
2005/12/03(土) 01:52:24ID:???コード体系とか適当に作って、後で泣きを見るってのはよくある話だ
0368NAME IS NULL
2005/12/12(月) 11:39:12ID:???現場の使い方の詳細な知識が有れば、余裕もって作り込み出来るかも知れないけど、現実は与えられた情報でヤマかけて作り込むしか無いな。
項目増えたらまた設計し直しって言うのも面倒だな。
業種別の汎用的なモデリング例とか共通化してしまえば楽だと思うけど、モデリングで飯喰ってる香具師には営業妨害かな。
0369NAME IS NULL
2005/12/13(火) 00:48:14ID:???でもいくら汎用的にって言っても顧客のビジネスルールは千差万別だから、
業務をシステムに合わせるためにコンサルが出てきたりカスタマイズが
必要だったり、ってことになるんだけどね。
0370NAME IS NULL
2005/12/13(火) 11:52:17ID:???結局イチから作ったほうがよかったんじゃねーかという罠。l
0371NAME IS NULL
2005/12/17(土) 15:20:22ID:???顧客のビジネスルールごとに似たような設計を繰り返すのは無駄だと思う。
ISOでもJISでもいいから定義しないかなあ。
0372NAME IS NULL
2005/12/17(土) 17:17:01ID:???カスタマイズが減ると仕事も減りそうw
0373NAME IS NULL
2005/12/18(日) 00:16:39ID:5chxNrki設計に反映できたらいいなと思っています。
できれば日本語だとありがたいのですが、日本語訳の計画などないでしょうか。
日本でデータモデル系の本を書かれてる方の一部にとっては気になる本(種本?)に
なっている傾向もあると思うし、モデル自体のいい悪いは別にして、
素人考えでは結構売れると思う(一冊は手元に置きたいという需要もあるだろうし)。
例えば、この本の中で、相手先の管理(顧客マスター)で履歴管理が必要な場合などの
データモデルなどモデルで提示されていると参考にしたくなる。個人名の
履歴管理として、刑務所の囚人の名前として偽名やあだ名の管理などにも言及
していたりして面白いと思う。(ある人物が名前や住所をいくつも持つという状態)
提示されているモデルを盲信しないようにということもあるかもと思ってしまうが、実際、
この本の評価(モデルの有用度)はどんなものでしょうか。
0374NAME IS NULL
2005/12/19(月) 02:11:17ID:???0375NAME IS NULL
2005/12/22(木) 01:02:21ID:???0376373
2006/01/09(月) 12:12:34ID:???この書籍内の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は試してない。
0377NAME IS NULL
2006/01/10(火) 09:58:29ID:???暇ならがんがれ。
0378NAME IS NULL
2006/01/25(水) 02:11:14ID:???俺もタネ本として買ったよ。
読むたびに、なにがしかを得られる本だよな。
0379NAME IS NULL
2006/01/27(金) 11:28:43ID:???0380NAME IS NULL
2006/02/26(日) 10:11:56ID:hHkdb9kSlocalhostのMySQL4.1.13に接続しようとすると
dbExpress Error: Invalid Username/Password
というダイアログが出てしまい接続できません。
どなたかこの現象の回避方法をご存知の方いたら教えて下さい。
お願いします。
0381NAME IS NULL
2006/02/26(日) 10:32:58ID:???ヒント:英語の辞書
0382NAME IS NULL
2006/02/26(日) 10:41:01ID:hHkdb9kSダイアログの内容を読め、といった意味であればそれくらいはさすがに分かっています。＾＾；
UsernameもPasswordも一致しているのにこのメッセージが出ているから困っているのですが・・・。
root以外のユーザもいくつか作成して試しましたが同じでした。
それとも海外にこの現象について解説したサイトがあるって事でしょうか？
う～む・・・。
0383NAME IS NULL
2006/02/26(日) 15:27:07ID:???OLD_PASSWORD関数つかってみれ
例：
UPDATE mysql.user SET Password = OLD_PASSWORD('hogehoge') WHERE User = 'foo';
FLUSH PRIVILEGES;
0384380
2006/02/26(日) 17:43:32ID:hHkdb9kSありがとうございます！
教えて頂いた通りやってみたところ、エラーは消えて無事接続できました！
・・・が、モデルが開けません・・・orz
DBDesigner4はMySQL4.1以降には対応していないって事でしょうか。
フリーでかなり良さそうなツールだったので残念。
でもお陰で勉強になりました。
本当にありがとうございました！
0385NAME IS NULL
2006/02/27(月) 01:44:31ID:???でも、もともと不安定なツールだからね＞DBDesigner4
0386NAME IS NULL
2006/03/04(土) 14:33:11ID:DNs0MEkq論理・物理名を切り替え、同時表示できるのありますか？
0387NAME IS NULL
2006/03/10(金) 08:45:13ID:pPH8uClm推奨する読み物を見掛ける事があるのですが実際の所どう思います？
●定義
ID:ユーザが意識しないシステム上での識別子
CD:ユーザが意識する識別子
この定義までは、同意です。
この後、CDを使う場合は、IDを主キーとし、
CDには、ユニークインデックスを張るという解説がよくみるパターンです。
この通りに進めると確かにCDは変更できるのですが、
モデルが複雑になりアプリの開発工数が確実に増えます。
（昔CDを変更する要件があって同じ実装をしたが
履歴系情報との整合性問題を理解して貰うとか、
CD変更用アプリを別途作るとか面倒ダタヨ）
その辺のバランスが、私の経験だとヤリスギと感じるのですが、
どう思いますかね？
0388NAME IS NULL
2006/03/10(金) 09:55:44ID:???(2) 変更履歴を管理しやすい（コード変更時は直接変更ではなく古いコードに削除フラグを立てる、という感じ）
(3) 最近のアプリケーションフレームワークにシステムidを前提にしたものが増えてきている（Hibernate,RoRなど）
0389NAME IS NULL
2006/03/10(金) 12:49:21ID:???要求側には出来る限り押し通す
0390NAME IS NULL
2006/03/10(金) 12:57:26ID:???主キーにするのでは。
0391387
2006/03/12(日) 03:12:21ID:???>(1) joinするときに便利（複合主キーの場合）
４階層目のテーブルなどで、主キーの項目数が、やむえず増えた場合に
代替となるIDを振る事には、同意です。
気になっているのは、1:1でCDとIDを作成する事が、どうなのかなぁと。。
例えば、↓こんなテーブル
取引先テーブル
取引先ID（主キー）
取引先CD（ユニーク制約）
取引先名（単なる属性項目）
>(2) 変更履歴を管理しやすい（コード変更時は直接変更ではなく古いコードに削除フラグを
立てる、という感じ）
削除フラグを使用するという事は、CDにはユニーク制約を
張らないという事ですね。
変更履歴を、作りやすいという点は、分かりました。
この方法で気になる事は、
・CD値の重複チェックをアプリ側で徹底する必要がある。
・変更のたびにレコードが増えて行くのは、
いたすらに負荷(JOIN等)を増やす事になるのでは？
・CD値の変更を行った場合には、レコードが追加され
新しいIDが振られると思うのですが、
子テーブルとの紐付けはどうなるのでしょうか？
>(3) 最近のアプリケーションフレームワークにシステムidを前提にしたものが増えてきてい
る（Hibernate,RoRなど）
な～るほど、それには従った方がよさそうですね。
0392387
2006/03/12(日) 03:14:03ID:???>仕様変更とか柔軟になるし要求側には出来る限り押し通す
う～ん、本当にそこまでやるメリットがあるのか
私の経験上わからないのですよねぇ。
ちなみに開発してきたのは、中小規模で数人で分析～リリースし
半年位の規模で、受注だとか会計だとかのシステム。
>>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
0393387
2006/03/12(日) 03:15:25ID:???思っているのですが、変更できないといっている原因は、
参照整合性制約が理由ですかねぇ？
だとしたらCD値を主キーとして、参照整合性制約にON UPDATE CASCADEを
付加する方が、シンプルで柔軟性も確保でき負荷軽減という点でもメリットが
大きいと思うんですよねぇ・・・
ちなみに、ON UPDATE CASCADEのサポート状態を、ざっと調べてみた所、
使用可：SQLServer2000 , Access97 , MySQL4.0.8 ,pgsqlでも使えるっぽい。
使用不可：Oracle（Oracleで使えんのは問題か。。？）
0394NAME IS NULL
2006/03/13(月) 12:46:46ID:???主キーに整合性とってないデータも有ったりだし。
別に外部キー更新したい訳じゃないし。
0395NAME IS NULL
2006/03/13(月) 20:08:01ID:???無限履歴とか、ラスト５回履歴とか、便利では有るが、ディスク容量喰うよなあ。
年度毎あたりでダンプして履歴リセットって仕様にすると、継続サポートコスト発生で開発側はウマーかな？
0396387
2006/03/13(月) 20:57:29ID:???私も基本は、主キーは変更しないという考えです。
というか、CDだろうがIDだろうが、一度付けた識別子を、
変更するな、という旧い？考えなのです。
ただ、会社として扱うデータ量、種類が増えてきた為に
コード体系を、変更したいといった要望が発生するのは
分かるので、コードを変更する上で効率的なモデリングは、
どんなのかなぁと考えている所です。
まぁ、そんな状況になった場合は、CDだけじゃなくシステム
全面見直しな上、会社として儲かっている可能性が高い訳で、
アプリの修正工数なんて、ちょちょいと出てくるはずなんで
すけどねぇ。。。Ψ(｀▽´)Ψｹｹｹ
その辺のバランス、CDの洗い替えが多発するという状況が
思いつかないのも、疑問に思う一つの理由です。
>主キーに整合性とってないデータも有ったりだし。
整合性が取れない可能性のあるテーブル（参照整合性制約を
張らないテーブル）で、私がよく作るのは、
・トランザクション系テーブル
・履歴系テーブル
・外部からの連携情報テーブル
・汎用的に様々なCDを入れる為の属性
な～るほど、こう考えるとCD一本でモデリングした場合の
トランザクションが問題で、CD変更時に生きている
トランザクションが存在すると面倒ですねぇ。
みなさんありがとう、納得しました。
IDとCDを分ける事によりシステムの寿命が延びるが、
工数と負荷の面でのデメリットがあるという考えで
使い分るとします。
CD体系の変更が発生する可能性の高いシステムが前提の場合、
トランザクション系システムならば、IDとCDを分けて、
データウェアハウスや、寿命よりも処理速度にシビアなシステム
ならば、分けないといった感じですかね。
工数も少なくCDの変更ないだろう、といった場合は、
やっつけ仕事で、次回に回収すると。。Ψ(｀▽´)Ψｹｹｹ
他には、IDとCDを分けた場合、履歴系はデータを登録しすぐに削除し
また同じCDで登録した時に関連が切れるという点をユーザーに理解
してもらう必要があると。（たいした問題ではない。）
0397NAME IS NULL
2006/03/26(日) 12:56:39ID:???0398NAME IS NULL
2006/03/27(月) 17:42:12ID:???0399NAME IS NULL
2006/03/32(土) 00:02:21ID:???T字型は表記法と正規化における規則であって、正規化そのものじゃないと思うけど。
ER 図なら Visio や ER Studio などで十分。
69の言ってことがよく分からん。
> 会社で社員が部門に所属しているのを表すとき、
> 社員（社員コード、氏名） 部門（部門コード、部門名） 所属（社員コード、所属部門コード）
> のようになるようなんですが、T字型でないERの場合は
社員（社員コード、氏名、所属部門コード） 部門（部門コード、部門名）
> となると思うのです。
これは、表記法がT字型であろうとなかろうと、結果は一緒になる罠。
理由は70、71が言ってるとおり。
0400NAME IS NULL
2006/03/32(土) 17:00:56ID:uNjChBoxDynamicDraw(ttp://www.molips.com/jp/)
に
ttp://groups.yahoo.co.jp/group/molips/files/
のテンプレートを入れて使う。
EXCELとかWORDは矢印線の先端スタイルが限られているから
いまいち使えないね。「ファイルが開けないよ～」って人には
WORD or EXCELにクリップボード経由でメタファイル形式で貼り
付けて渡せばいいし。
（再編集はできないけど。）
0401NAME IS NULL
2006/04/02(日) 01:56:16ID:???ありがとう。結構よさげだね
0402NAME IS NULL
2006/04/05(水) 22:46:40ID:5UG0+3IT勉強用にいろいろ見てみたいのですが・・・。
0403NAME IS NULL
2006/04/22(土) 05:31:29ID:pFb3dyuH下記以外にお勧めの書籍ありましたら、お教え願えませんでしょうか。
■ 読んだ
「実践的データモデリング入門」 真野 正
「業務別データベース設計のためのデータモデリング入門」 渡辺 幸三
「データベース設計論 －Ｔ字形ＥＲ」 佐藤 正美
「名人椿正明が教えるデータモデリングの技」 椿正明
■ 読むつもり
「データ中心システムの概念データモデル」 椿正明
「生産管理・原価管理システムのためのデータモデリング」 渡辺 幸三
「Ｔ字形ＥＲ」は新しいのを読んだので、ほか２冊は読まなくて良いかなと
思ってるんですがどうでしょう？
（店頭で見つからないので、内容確認できないんです）
0404NAME IS NULL
2006/04/22(土) 07:26:55ID:???0405NAME IS NULL
2006/04/22(土) 13:18:55ID:pFb3dyuH実際、著者により主張が違うところがあるので自分で比較検討してみたいんです。
>>402 さんみたいに、サンプルを沢山見てみたい、てのもあります。
0406NAME IS NULL
2006/04/24(月) 04:43:21ID:???0407NAME IS NULL
2006/04/25(火) 00:55:55ID:???いろいろ勉強すればＴ字型ってダサいなぁと気付いたりするわけよ
0408NAME IS NULL
2006/04/25(火) 10:26:47ID:???0409NAME IS NULL
2006/04/25(火) 13:26:45ID:???じゃあ、ナウでヤングなモデリングを教えてくだされ。
0410NAME IS NULL
2006/04/28(金) 01:15:02ID:???わざわざ主キーを非明示にする理由がわからん。
0411NAME IS NULL
2006/04/30(日) 10:51:28ID:???0412NAME IS NULL
2006/05/07(日) 13:07:50ID:???0413NAME IS NULL
2006/05/07(日) 21:18:58ID:???0414NAME IS NULL
2006/05/11(木) 00:42:24ID:???えー。
ＤＢ屋以外の関係者との会話に使えないような記法はどうかと思うけど。
0415NAME IS NULL
2006/05/11(木) 00:59:09ID:???0416NAME IS NULL
2006/05/11(木) 07:29:29ID:???哲学者とは会話できるようになるぞｗ
0417NAME IS NULL
2006/05/14(日) 01:28:50ID:???あの理論編の哲学議論がまさに「言語ゲーム」。
0418NAME IS NULL
2006/05/14(日) 01:42:07ID:???悟り開いて宙に浮く様になれば尊師の教えが分かるよって感じ。
傍から見てるとDQNにしか見えない罠。
0419NAME IS NULL
2006/05/14(日) 13:29:08ID:???0420NAME IS NULL
2006/05/15(月) 00:55:43ID:???従来のＥＲ手法でエンティティとリレーションを同時並列的に検討するのは、
純粋な「実体主義」も、純粋な「関係主義」も、現実的には極端すぎるから両方を同等に扱いましょう、
ていうのが背景にあると思う。（明示的にではないにしろ）
それを“実体主義のほうが本質的で、だからエンティティーを重視するんだ！”って主張するんだったら
そのへんをちゃんと論理的に、かつ皆が納得できるように説明してくれないと．．．
あの理論編は、ぜんぜん「理論」になってなくて、いろんな哲学のオイシイ結論を寄せ集めただけに見える。
だってボク、クリプキ好きなんだもん、とか言われても困っちゃう。
0421NAME IS NULL
2006/05/15(月) 04:32:07ID:???でも、たしかに理論書としては、ちゃんと筋道たてて説明してない感じがする。
論理の飛躍がある、というより、断片を継接ぎした結果みたいな。
モデリングって学問としてあるわけじゃないのかな・・
奥が深いし、博士号取得した哲学者や数学者がもっと研究してほしい
0422NAME IS NULL
2006/05/16(火) 19:37:34ID:???上界値＝計算量が最大と思われる値？
0423NAME IS NULL
2006/05/16(火) 23:01:00ID:???てか板ちがい
0424NAME IS NULL
2006/05/16(火) 23:20:39ID:???レスありがとうございます。
では、これはどこの板行けばいいんですかね？プログラム板ですか？
0425NAME IS NULL
2006/06/29(木) 00:28:29ID:s69NJyt80426NAME IS NULL
2006/06/30(金) 12:54:48ID:5MdCXCSh扱いにくくってしょうがないんですが。
0427NAME IS NULL
2006/06/30(金) 13:03:31ID:???VisioのProfessional版を使っていて、できそうだったのでちょっとやってみたら
「Enterprise Editionを使え( ﾟДﾟ)ｺﾞﾙｧ！」と言ってきました｡インスコしてないので試せないが､
Enterprise版を使えばできると思われ。MSDNにはついてきていると思う｡
0428NAME IS NULL
2006/06/30(金) 23:23:03ID:???0429NAME IS NULL
2006/07/01(土) 11:42:35ID:???理由等わかればkwsk
0430NAME IS NULL
2006/07/01(土) 15:00:38ID:???0431NAME IS NULL
2006/07/02(日) 07:56:49ID:???実装と文書化の二度手間のほうが苦痛。
0432NAME IS NULL
2006/07/02(日) 09:59:38ID:???DBDesignerでもER図やDB定義書くらい作れるぞ
0433NAME IS NULL
2006/07/02(日) 15:46:50ID:???手書き程度ならチラシの裏に落書きで十分だし。
0434425
2006/07/05(水) 22:25:25ID:???というバージョンで出来ました。
ところで、教えていただきたいことがあるのですが、3種類のコードが組み合わさって
出来ているコードがあるのですが
AAABBCC
コードA VARCHAR(3)
コードB VARCHAR(2)
コードC VARCHAR(2)
こんな感じです。AとBとCは親－子－孫の関係にあるのですが
この親－子－孫を表せるようにモデリングするにはどうしたらよいでしょうか・・・・
0435NAME IS NULL
2006/07/06(木) 18:28:47ID:???親＝PK:|AAA|
子＝PK:|AAA|1-n|BB|
孫＝PK:|AAA|1-n|BB|1-n|CC|
かな？
んで。気になるのは。各コードは固定長でなく可変長なんですか？？
0436NAME IS NULL
2006/07/06(木) 22:26:39ID:???あ、固定長です。
>親＝PK:|AAA|
>子＝PK:|AAA|1-n|BB|
>孫＝PK:|AAA|1-n|BB|1-n|CC|
これは、まさしくこんな関係です。
0437NAME IS NULL
2006/07/10(月) 23:41:46ID:2umW5dHJ交差エンティティを作成するという例はよく見かけるのですが、
イベントエンティティ同士の関係についても交差エンティティを作成するという
事はあるのでしょうか？
たとえばある複数の勘定科目から出金して、出金した額を別の種類の複数の
科目へ入金するといった作業があるとして、出金エンティティと入金エンティティ
との関係はどう表したらよいのでしょうか。
0438NAME IS NULL
2006/07/10(月) 23:45:40ID:EbhJ+Fw+0439NAME IS NULL
2006/07/11(火) 02:01:08ID:???交差エンティティって呼ぶのかどうかは知らないけど、
そんなようなものは必要に応じて当然作るよ。
○親テーブル
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
0440NAME IS NULL
2006/07/11(火) 14:42:29ID:???帳票をそのままDBにすればおk。
0441NAME IS NULL
2006/07/15(土) 15:39:26ID:???0442NAME IS NULL
2006/08/27(日) 18:38:29ID:7FPwEeLv顧客IDなどのコードの作成方法は
決まっているのでしょうか。
社員番号なら入社年月日＋連番
などでいいと思うのですが、
何か指針はあるのでしょうか。
0443NAME IS NULL
2006/08/28(月) 01:10:22ID:???総務や人事と打ち合わせて決めたほうがいいよ。
全社的に統一しないと意味がない。
顧客コードなら営業とかと打ち合わせて決めるべき。
営業上、顧客の元に自社の顧客番号が付いたものが送られるし、「ああ、うちって１００社目なんだな」って推測されちゃうような顧客IDは恥ずかしい。
0444NAME IS NULL
2006/09/01(金) 01:41:11ID:???XEADとかJude、ObjectBrowserERあたりがよさげなんですが！！
今試そうと思ってるのがOracle JDeveloper10g！！！
0445NAME IS NULL
2006/09/01(金) 17:52:21ID:???XEADだけは勘弁
0446NAME IS NULL
2006/09/02(土) 23:04:56ID:???XEADは、どこら辺が駄目だと思いますか？
0447NAME IS NULL
2006/09/16(土) 01:13:27ID:???顧客マスタとか商品マスタみたいなのはナチュラルキー、
受注TRとか売上TRはサロゲートキー、
仕様変更が多そうならサロゲートキー多め、
ERモデリングツール使うならナチュラルキー、
ORマッピング使うならサロゲートキー、
こなかじ？
0448NAME IS NULL
2006/09/16(土) 01:23:02ID:???あれもアホな議論だったな
0449NAME IS NULL
2006/09/17(日) 01:56:26ID:???信者（？）で何が何でも導入したいみたいで。。。本を読んでみたけど
文章表現は下手（だと思った）だし理論にしても判り辛いような。。。
数千人規模の会社の基幹業務構築のモデリングには大丈夫なのかな～？
と思ってます（例えば数年後には理論自体廃れてるとか・・・）。
0450NAME IS NULL
2006/09/17(日) 02:41:45ID:???いいところはresource概念とevent概念云々のところぐらいか
あとはちょっと・・・。identifierの扱いがアレなんで、あの理論をそのまま適用するのは
実際的ではないと思う
0451NAME IS NULL
2006/09/17(日) 04:11:40ID:???主キーと関連だけしっかり抑えとけば大概上手くいく。
大事なのは、間違ったモデリングなんてないと知っておくこと
0452NAME IS NULL
2006/09/17(日) 16:38:22ID:???いろんなモデリングのシミュレーションソフトとかあれば設計時に検証しやすくて便利なのにな。
0453NAME IS NULL
2006/09/18(月) 11:28:44ID:???基幹ではないが、大手での採用例はあり。
和光市の某自動車メーカとか、麹町の某信販会社とか。
ただ、Ｔ字型を使ったプロジェクトで試行錯誤した経験者がいない状態で
本読んだだけでいきなり実地の大規模システムに適用しようとすると
多大な困難が待ち受けていそうな悪寒が…
0454ＴＭ使ってるよ
2006/09/20(水) 14:17:52ID:6C6LnzZC業務系のシステムでは「コード体系」を使って分析するのが便利って便法を思いついたりしながら発展して
きましたが、根っこの部分ではオブジェクト指向におけるドメインモデリングと繋がっています。
なので、#453 の方が言われる様に、本を読んだだけで見よう見真似で始めるのは、少し辛いでしょう。
できれば、本人から習うことが可能なので、それが一番だと思います。
http://www.sdi-net.co.jp/ に行ってみましょう。
0455NAME IS NULL
2006/09/23(土) 17:10:07ID:???ＨＰ見てみたけど、本当大丈夫なの？かなり素人っぽいＨＰで
すが。コンサルとかやってるんんだったらもうちょっとマシな
ＨＰにした方がいいような。。。
それに実績も書いてないし。>>453 の和光や麹町の会社ではどれだけ
ＴＭにより実績がでたのかな？
コンサルやるなら会社（？）の規模も知りたいなー
0456NAME IS NULL
2006/09/24(日) 12:10:14ID:???「Ｖｉｓｉｏの方が書きやすいじゃん」ってノリだから「ＴＭを
導入してビジネスの強み・弱み・・・」なんて程遠い状態。
0457NAME IS NULL
2006/09/24(日) 20:16:59ID:???WebPages見てそういう感想抱いたのなら、ＴＭとは出会わなかったことにした方が多分幸せになれる。
いや、煽りや皮肉ではなく、本音ベースの話。
感覚的な「合う」「合わない」っていうのは結構重要な要素かと。
0458NAME IS NULL
2006/09/25(月) 00:31:01ID:???ってのは凄いなー。
事例とかあるといいけどね。
0459NAME IS NULL
2006/09/25(月) 01:10:08ID:???まあ優秀なエンジニア集めれば、別に何でも短納期でできそうな悪寒。
そういう論点のすり替えをして一儲けするのがコンサルと言えばそうだけど。
0460NAME IS NULL
2006/09/25(月) 10:26:51ID:???ステップってコード量だよねぇ？
でコンサルが開発するわけじゃないだろうし、有効なメトリクスなのかね？
コンサルとしてはそういうところ大事だと思うんだが。
0461NAME IS NULL
2006/09/26(火) 00:04:22ID:???0462yossy
2006/09/26(火) 00:38:05ID:3/C3qjqeDBDesigner4の使い勝手が良かったので日本語化してみました（需要アルカナ・・・）
http://dbdesigner.iimp.jp/
使ってみてご意見いただければと存じ上げます。
Delphiはあまり使ったことがないので安定度が下がっているかもしれません。。
あと、、まだWindows版しかコンパイルしていないです・・・。
Linuxはあまり慣れていないもので。。すみません。。。
0463NAME IS NULL
2006/10/02(月) 23:45:41ID:???主キーベースのERDを作成する段階では、ナチュラルキーでモデリングし始め、
全属性ERDを作成する段階で、最終的にサロゲートキーに再設計してる。
（最初はナチュラルキーの方がわかりやすいので・・・）
全部サロゲートキーにしてる理由は、
（１）安定性の確保
：将来のシステム改善などでの主キー属性の設計変更を、極力抑える。
（候補キー自体が安定していることが前提なのに、変わることあるから・・・）
（２）データへのアクセスコストを抑えたい
：ナチュラルキーだと３つ以上のコンポジットとなってしまう場合がある（特に連関エンティティ）
（３）ポリシーの統一
：全エンティティを同じポリシーで設計するため全部サロゲートキー
なんて言い訳でサロゲートキーにしてる。
0464NAME IS NULL
2006/10/02(月) 23:56:56ID:???>候補キー自体が安定していることが前提なのに、変わることあるから・・・
間違えた。
候補キー -> 主キー
0465NAME IS NULL
2007/05/12(土) 18:00:45ID:???0466NAME IS NULL
2007/05/15(火) 19:54:55ID:/Spdz0dJ次回のバージョンアップで他のシリーズも同一のテーブルで管理できるようにしたいです。
現在
武器 (武器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だとキーの作成は簡単だが、データの入力順を間違えると気持ち悪いナンバリングになってしまう。
どのような場合にどちらがいいか教えてください。
0467NAME IS NULL
2007/05/15(火) 23:21:27ID:???複合キー列への外部キー設定は列が増えてしまって、
子表が増えるほど面倒になるから案2がいいなぁ。どうせ
武器IDなんてもとより意味のあるものじゃないんだし。
もういっそ武器IDは乱数を採番するようにしちゃえば気にならないよ。
0468NAME IS NULL
2007/05/16(水) 03:44:39ID:???最近の流行は2か。アプリケーションフレームワーク的に２のようになってないとあかんものがあるな。
武器リストだと表示順ってのも気にしたいだろうから、
１のテーブルにさらにid列を一つ追加して、
武器IDは表示順的な意味を持たせるのもありかも
0469NAME IS NULL
2007/07/08(日) 18:42:56ID:???それとも、postgresqlをodbcで接続して、DBDesignerを使っても、幸せになれますか？
0470NAME IS NULL
2007/08/07(火) 20:28:30ID:bIEMzxGi独学で簿記を勉強しようとすると、書籍を購入して勉強となりがちだが、
項目が羅列してあり説明は最小限のような簿記の書籍ではなかなか理解は進まない(俺だけか)。
簿記の書籍は不親切であり、そのために資格学校が存続できてる気がする。
資格学校に通わなくても資格学校の通信教育等もあるし、それもそんなに高くはない。
さらに講義形式の勉強で一番手軽なのは、資格学校が出版しているDVDビデオの教材がある。
例えば、以下のような教材がある。
合格テキスト講義DVD日商簿記3級 商業簿記 Ver.4.0(10,500円)
DVD6枚組 TAC出版
俺は本屋で買ったが、amazonにもある。講師は違うが2級もある。
これと対になってる書籍(テキスト)も別に売ってるが、なくても特に困らない。
DVDの講義なので、好きなときに何回でも見れる。
これを見てしまうと、いかに市販の書籍で学ぶことが能率が悪いかということがよく分かる。
おそらく簿記の勉強は書籍ではなくて人の話を聞いて学ぶのが一番よいのでは
ないかと思う。「要はこういうこと」みたいな言葉やくどいぐらいの説明は
なかなか書籍には載りにくい。このDVDのテキストも同じ欠点がある。
例えば減価償却累計額について簿記上の具体例を含めて詳しい説明を書籍で
探そうとすると結構大変だと思う。また、講師がしゃべってくれるわけで漢字の
読み方も問題なくなる。この3級の講師は大変よいと思う。きっちりとよく話してくれている。
スレ違いすまん。
0471NAME IS NULL
2007/08/08(水) 00:35:59ID:???たかが3級レベルで分かりやすいも分かりにくいも無いと思うんだが・・・
0472NAME IS NULL
2007/08/08(水) 21:18:53ID:???実際は1週間足らず勉強してケアレスミスで落として
90点代後半取れた。
0473NAME IS NULL
2007/08/09(木) 22:20:09ID:MI2mCbx1物理データモデルの「内部スキーマ」とは、具体的にRDBMSで
いうところの、どのようなオブジェクトなのでしょうか？
どなたか御教授ねがいます。
0474NAME IS NULL
2007/08/10(金) 02:23:03ID:???0475NAME IS NULL
2007/08/10(金) 22:15:11ID:???ANSI/SPARC ３層スキーマのことなら、
概念スキーマ：テーブル
外部スキーマ：VIEW
内部スキーマ：物理ファイル定義（oracleだとセグメントかな）
0476473
2007/08/11(土) 00:56:13ID:Fq8lPKBOありがとうございます。
ANSI/SPARC ３層スキーマに関してですが、SQL Server 2000
について「内部スキーマ」なるものが、どのようなオブジェクトを
指すのかご存知なら教えていただけますか？
宜しくお願いします。
0477NAME IS NULL
2007/08/11(土) 09:26:15ID:???内部スキーマについて、oracleだとセグメントって書いたけど、
データベース上の特定のオブジェクトや構造を指している
というよりも、索引からセグメントからデータファイルまでの
物理構造のことを指してる。
SQL Serverは詳しくないのだけど、同じようにセグメント
（oracleでは表領域に相当）からデータベースデバイス？までの
物理構造のことを指しているのではないかな。
0478NAME IS NULL
2007/11/19(月) 21:31:13ID:YgXjo0NC長文で申し訳ありませんが宜しくお願いします。
<前提条件>
製造業向けの部品加工を想定(在庫関連の処理は無し）
製品･部品･工程･実績の４つのエンティティがあるとして、、、
製品 … 製品というよりは製造指示Noのようなもの
部品 … 製品を構成する部品です。(※一般的なBOMのような親品目,子品目を再帰で保持するような複雑な構造ではない)
工程 … 部品を加工するための加工工程手順です。(手順1:旋盤, 手順2:マシニング...)
実績 … 加工工程に対する実績(労務費、労務時間)
４つのエンティティの関連は次のような階層構造を考えています。
(※この考え方がおかしい場合はご指摘ください)
製品 → 部品 → 工程 → 実績
(1:n) (1:n) (1:n)
部品には材料や購入品といった部品区分があり、データ属性が異なるため、
部品をスーパータイプ、材料･購入品をサブタイプで持たせようと思っています。
製品 → ＋部品(部品id(PK), 部品区分...) → 工程 → 実績
｜
＋材料(部品id(PK), 仕入先cd(FK), 寸法...)
＋購入品(部品id(PK), 仕入先cd(FK), 購入品品番(FK)...)
*** 質問１***
各エンティティの主キー(PK)をどのように設けるのが一般的なのでしょうか？
上記のようなデータ構造の場合の一般的な主キーの設け方をご教授ください。
今考えているのが①と②の方法です。
①各エンティティに単独の主キー(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, 着手日, 労務費, 労務時間...
②各エンティティの主キー(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, 着手日, 労務費, 労務時間...
そもそも考え方がおかしい場合はご指摘ください。
0479NAME IS NULL
2007/11/19(月) 21:32:24ID:YgXjo0NC*** 質問２***
次の原価をリアルタイムで把握したい場合には原価データをどのように保持するのが一般的なのでしょうか？
(※ここでは外注費は無いもとする)
1.製品別原価(製品別の材料費計＋購入品費計＋労務費計)
2.部品別原価(部品別の材料費計＋購入品費計＋労務費計)
3.工程別原価(工程別の労務費計)
考えているのは次のとおりです。
①製品エンティティに"材料費計", "購入品費計", "労務費計"のデータ項目を持たせる。
②部品のスーパータイプエンティティに"材料費計", "購入品費計", "労務費計" のデータ項目を持たせる。
③工程エンティティに"労務費計"のデータ項目を持たせる。
各計データの更新はトリガーやストアドにて行う
そもそも考え方がおかしい場合はご指摘ください。
以上、宜しくお願いします。
0480NAME IS NULL
2007/11/20(火) 02:27:57ID:???正規化をきちんとするなら、①の材料と購入品には製品idは入らないはず。
俺なら他のテーブルとの一貫性を保つために
材料: 材料id(PK), 部品id(FK), 仕入先cd(FK), 寸法...
購入品: 購入品id(PK), 部品id(FK), 仕入先cd(FK), 購入品品番(FK)...
とする。でも、部品idにユニーク制約をつけなきゃいけないのでそこを手間と感じるかどうか。
①か②かはどっちでもいいけど、最近は①が主流。
処理側のフレームワークと言うかプログラムロジックに便利な方を選択。
質問２
集計用のテーブルを別に作るべき。
完全なリアルタイムにせずに、例えば１０分ごとに集計バッチをまわすとか、
Oracleならマテビューを使うとかする
0481NAME IS NULL
2007/11/20(火) 14:49:55ID:/GHn6NrO遅くなりまして申し訳ございません。
レスありがとうございました。
質問１について
なるほど、確かにデータ編集時に、複合主キーより単独主キーでアクセスした方が
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, 着手日, 労務費, 労務時間...
0482NAME IS NULL
2007/11/20(火) 14:51:01ID:/GHn6NrO>>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), 労務費計...
以上、質問ばかりで申し訳ございませんが
宜しくお願いします。
0483NAME IS NULL
2007/11/20(火) 20:40:10ID:wWhiZNbuhttp://want-pc.com
0484kmyPJqxBGr
2007/11/20(火) 21:35:11ID:???0485YDdMTWcmpUvtToARj
2007/11/20(火) 21:57:55ID:???0486NAME IS NULL
2007/11/21(水) 00:24:58ID:???OKと思われ。
>>482
OKと思われ。まぁ、こっちは単独主キー無くてもいいかも知れんが
0487NAME IS NULL
2007/11/21(水) 10:43:07ID:???レスありがとうございました。
これでスッキリしましたので先に進めそうです！！
0488kkEaqflyQ
2007/11/23(金) 04:52:59ID:???0489kAXUAXtktXfWiAc
2007/11/23(金) 10:57:18ID:???0490XRXQZTpLvYJra
2007/11/23(金) 12:14:42ID:???0491qgNOgKJitye
2007/11/23(金) 21:16:42ID:???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
0492vnlCkSByPPMG
2007/11/25(日) 00:46:56ID:???0493NAME IS NULL
2008/02/10(日) 12:22:27ID:???>>384 に同じ現象が書かれているのですが・・・
バージョンアップされてないからなぁ＾＾；
0494NAME IS NULL
2008/05/23(金) 04:29:26ID:P38jVWZR0495VQiYlHzPZa
2008/06/01(日) 13:42:47ID:???0496NAME IS NULL
2008/07/07(月) 17:23:41ID:???取引先の会社とその担当者、お客様とその家族、
と、全部で4つのテーブルを作成しました。
それぞれのテーブルには、名前や電話や住所などの
列を並べました。
そこで疑問になったのが。
取引先の住所と担当者の住所は、共通する事もある（し違う事もある）。
家族の住所と個人の住所は、共通する事もある（し違う事もある）。
と、考えると。
住所部分のみでテーブルを作成して、4つのテーブルから
参照した方がいいのかな？とも思ったのですが、いかがでしょう？
0497NAME IS NULL
2008/07/07(月) 22:08:49ID:???0498NAME IS NULL
2008/07/07(月) 22:38:19ID:???確かにおっしゃる通りで、良さそうですね。
また、営業所が移転した場合や家族が引っ越しした時に、
同じ住所テーブルを示していれば、個人の住所も一括で
修正されますね。ありがとうございました。
0499NAME IS NULL
2008/09/06(土) 12:04:21ID:???開始/終了イベントテーブルにそれぞれ発生時刻を記録するほうがいいと思うんだけど
0500NAME IS NULL
2008/09/08(月) 00:51:51ID:???イベントテーブルにそれぞれ記録するほうがいいのは
たとえばどんな時でしょうか？
0501NAME IS NULL
2008/09/08(月) 23:23:38ID:???抽出したエンティティの意味的な違いに優劣はないから実用上のメリットで言うと、
所要時間を求めるようなクエリでjoinを節約できるとか。
逆に挿入/更新でコストはかかっているわけで、メリット/デメリットともに
事前集計表と似たようなもの。
0502NAME IS NULL
2008/12/23(火) 20:52:33ID:GasTPqXo0503NAME IS NULL
2008/12/28(日) 05:07:16ID:???導入事例ってあんまり当てにならないのか。まあそもそも営業資料だしね。
導入されても、実際十分に活用されてるかどうかや、現在も使われてるかどうかはわからないしなあ。
0504NAME IS NULL
2009/01/17(土) 01:16:45ID:jMspYNZvもし問題があれば指摘していただけるとありがたいです。
http://niyaniya.info/pic/img/2186.jpg
業務の基本的な流れは 見積作成⇒請負契約⇒ 工事 です。オリジナルはもうすこしマスタテーブルが
増えて複雑なのですが、基本はこんな感じです。 よろしくお願いします。
0505NAME IS NULL
2009/01/17(土) 23:29:03ID:???普段、IDEF1Xでしか読み書きしてないから、リレーションシップの
意味が正しく理解できてるかわかんないのと、業務要件が不明だから、
自分の所見でコメント。
（１）「見積明細」の主キーは”見積ID”では？。
「見積明細」は「見積」のサブタイプということだと思うけど、
意味があって分けてるのかな？
（２）「請負契約明細」についても（１）と同様。
（３）「請負金額入金」「請負金額請求」は、「入金」「請求」として
独立エンティティにするか悩むところ。
入金単位や請求単位が請負契約単位なのかな？
（１契約で入金は複数回とかないのかな）
（４）何故「仕入契約」「下請契約」は"業者ID"が主キーに
なってるのに、「請求契約」の方には”顧客ID”が主キーに
なってないの？ この違いの意味は？
両方とも<契約>という同じような意味のエンティティと
考えれば、その属性も同じような主キー構成で
いいと思うけど。
※属性なしで、エンティティ名だけでリレーションシップを
考えた方がわかりやすいですよ。
0506NAME IS NULL
2009/01/18(日) 03:01:18ID:rdZV1j35レスありがとうです！
ありがたい指摘なのですが理解する語彙が足りずアドバイスを生かしきれないのが
残念ですが・・・
(1)で言われた「見積明細」テーブルは、本来「見積」テーブルと一体の繰り返し要素を別テーブルに分離した
もので主キーは設定していません。 １つの見積に対して複数の見積項目があるので２つのテーブルに分離しました。
販売業者における販売テーブルと販売明細テーブルのような関係です。
(2)の「請負契約」と「請負契約明細」も同様の関係です。
(3)の「請負金額入金」「請負金額請求」は確かに一つのテーブルに統合できそうです。
盲点でした・・ありがとうございます。
問題は(4)でして、、、『なぜ「請負契約」の方には顧客IDが主キーになっていないのか』
との指摘ですが、 請負契約の場合、１つの契約に相手となる顧客は１つだけなのですが、下請契約や仕入契約は
１つの工事に相手となる業者は複数に及ぶことがあります。 その質の違いから差が生じたと思います。
これがはじめてのデータモデリングで試行錯誤の結果ですのでもしかしたら基本的なところで誤理解をしてる可能性
ありですので・・・その程度のもんだとオモっていただけるとありがたいです。
0507NAME IS NULL
2009/01/18(日) 04:03:52ID:???この場合は表示順を主キーにすりゃいいんじゃないかな。
> (3)の「請負金額入金」「請負金額請求」は確かに一つのテーブルに統合できそうです。
統合すると請求1回に対して入金複数回のケースとか対応できなくなるよ。
あなたんとこの業務的には問題ないのかも知れんけど、
柔軟性保つために分けておいたほうがベター
主キー入ってないテーブルがあること以外は、大体OKそうに見えるね。
>>505は見当はずれだから気にしないほうがいい
0508NAME IS NULL
2009/01/18(日) 04:09:07ID:???ごめん、親テーブルの主キー＋表示順というつもりだった。
たとえば見積明細では（見積ID、表示順）を主キーにする
0509NAME IS NULL
2009/01/18(日) 04:25:30ID:???505です。今日は何故か眠れないのでレス
ちょっと説明がまずかったみたいなので、まず用語から。
※文中の用語はググってね。
エンティティ＝テーブル
属性＝列項目
主キー＝（簡単に言うと）一意に行を特定できる列項目
（１）の、「１つの見積に対して複数の見積項目がある」という
のは、「見積」１行に対して「見積明細」複数行という意味であれば、
「見積明細」テーブルの主キーは、”見積ID”と、明細を識別する”明細ID"
みたいなのが必要。（用語的には第２正規形）
（２）も同様。
（３）はそういう意味ではなくて、「契約」「請求」「入金」と、
それぞれ独立した（主キーを持つ）テーブルにしても良いのではという意味。
データモデルを考えるときに、業務の実態を、リソース（資源：名詞）と
イベント（出来事：動詞）に分けて、テーブルとして考えるのだけど、
例えば、
リソースは、「社員」「顧客」「業者」で、
イベントは、「見積」「契約」「請求」「入金」「工事」「支払」
なわけだ。
以上
0510NAME IS NULL
2009/01/18(日) 04:28:57ID:???どこが見当違いか、指摘してもらえるとうれしいね
0511NAME IS NULL
2009/01/18(日) 04:43:29ID:???もしかして、（１）でサブタイプって書いたことを見当違いって
言ってるのかな？
エンティティ名だけ見ると、第２正規形を意識したと思えたけど、
もしかして主キーが同じで、あえて分けたのかと深読みしただけ
なんだけどね。
（３）は509で書いた通り。
（４）は、業務要件わからないから、所見てことで、
主眼を「請負契約」と同様に<<契約>>に置いてもいいかなと思ったのさ。
よろしく。
0512NAME IS NULL
2009/01/18(日) 12:41:42ID:???0513506
2009/01/18(日) 20:01:21ID:???＞明細テーブルにも主キーはつけるべきだよ。
この場合は表示順を主キーにすりゃいいんじゃないかな
なるほど！ これは勉強になりました。 キーはテーブルの結合しか用途がないもの
だと思っていたのでそういう使い方が出来るのは初めて知りました。
＞主キー入ってないテーブルがあること以外は、大体OKそうに見えるね。
>>505は見当はずれだから気にしないほうがいい
いえいえ皆さんのアドバイスは大変勉強になります。
0514506
2009/01/18(日) 20:11:51ID:???＞「見積明細」テーブルの主キーは、”見積ID”と、明細を識別する”明細ID"
みたいなのが必要。（用語的には第２正規形）
たしかにおっしゃるとおりです。 明細テーブルの各行を識別するキーも必要ですね・・・。
ここらへんはまったくノーマークでしたのでありがたい指摘です。 その意味で
見積明細にも見積IDを主キーに設定すべきと仰っていたのですね。 私の間違いでした・・・
＞データモデルを考えるときに、業務の実態を、リソース（資源：名詞）と
イベント（出来事：動詞）に分けて、テーブルとして考えるのだけど、
この辺はいまの自分にはちょっと高度です もうちとレベルアップしてからアドバイスを
生かさせていただきます^^;
0515NAME IS NULL
2009/01/18(日) 23:18:35ID:???0516NAME IS NULL
2009/01/19(月) 01:35:56ID:???まぁ、そう言いなさんな。所見で深読みしたけどさ。
最初の図（モデル）から想像したのは、子エンティティの
外部キーについて、親エンティティからのキー移行だけを間違えて
記述したものと深読みしたということ。
（よって、排他的サブタイプと見たわけ）
業界／業務要件が不明なので、モデルから判断するだけ、つまり、
名称（用語）でエンティティを安易に想像してはダメってことも
あるからね。（話をよく聞かないうちに決めつけちゃダメさ）
ちなみにウチの所でも、第２正規化の結果を「XX」「XX明細」と
してるよ。
スレ汚しスマソ。
0517506
2009/01/19(月) 20:38:23ID:???やってみようと思います。 どうもありがとうございましたです！
http://niyaniya.info/pic/img/2219.jpg
0518NAME IS NULL
2009/02/01(日) 03:55:40ID:???運用で不具合出まくるだろうなあｗｗｗ
0519NAME IS NULL
2009/06/04(木) 09:25:50ID:w6Hljn46↓こんなかんじでどうでしょう^^;
http://imepita.jp/20090604/333030
項目A→項目B→項目C→項目D→項目E と具体的になっていく感じです
例） 電気→3LDK標準電気工事→玄関→外部玄関等→照明器具 DWP-3524DS
項目Aによって必要な階層がことなるので動的に階層を変更できればいいのですが、、
0520NAME IS NULL
2009/06/07(日) 19:19:03ID:???階層構造を柔軟にとか考えると、
所要量展開、再帰、LLC、
部品展開、原価計算、
といったところをある程度考慮して取り入れながら
設計するのかなと思う。
これらでぐぐってみてもよいかと。
0521NAME IS NULL
2009/06/09(火) 23:40:48ID:jbiexGaFその前に親子関係は1対多なんだよね？
何もテーブルを幾つも作らなくても、
子情報が主キーでそこに親情報が従属するような
再帰的な1テーブルで済まないの？
これだと、多重構造が可変でも耐えられるでしょ？
0522NAME IS NULL
2011/02/08(火) 23:20:58ID:???http://twitter.com/saramura6/statuses/6688087715352576
■ このスレッドは過去ログ倉庫に格納されています