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

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画像を閲覧するためのプラグイン
0270NAME IS NULL
垢版 |
2005/04/19(火) 11:57:10ID:8GDQE5S+
>268
検索速度については単表検索なら、簡単なコードのほうがいいと思います。
ただ、この設計だと投票結果テーブル検索時はユーザ情報テーブルをJOINするオーバヘッドが発生しますよね。
インデックス容量を考えると、コード有利です。
メールアドレスが変更される可能性があり、かつ変更後も同一人物として扱う必要があるならコード化です。
なければ、メールアドレスがキーのほうがアプリ工数は少ないかもしれません。（JOINの必要なし）
業務特性、システム特性を考えてトレードオフで考え、最良の設計を。

0271NAME IS NULL
垢版 |
2005/04/19(火) 19:34:30ID:???
>>270
> メールアドレスが変更される可能性があり、かつ変更後も同一人物として扱う必要があるならコード化です。
実は私もこの問題で>>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はメールアドレスですよね。
投票者はID { 001,002...}は知らない。
それで、既に投票されているかチェックに行く。そのための主キー。
とするとメールアドレス以外に主キーは考えられない。
0273NAME IS NULL
垢版 |
2005/04/19(火) 21:17:19ID:???
ER図から3NFまで自動変換するソフトウェアを探しています
0274NAME IS NULL
垢版 |
2005/04/20(水) 02:54:10ID:eImDdv+2
>270
いえいえ、違いますよ。
001は絶対に1レコードのままです。
変更情報は、
①「メールアドレス変更履歴エンティティ」を抽出する
②「変更前メールアドレス」項目を追加する
あたりで表現します。
純粋なデータモデルとしては①が正解とされますが
業務要件が「直近1世代の変更前アドレスだけの保持でよい」などであれば
②も現実的です。

0275NAME IS NULL
垢版 |
2005/04/20(水) 06:50:59ID:???
メールアドレスを外部キーにもつ列全部に UPDATE CASCADE をつけれ
0276NAME IS NULL
垢版 |
2005/04/20(水) 06:53:21ID:???
メールアドレスを外部キーにもつ列全部に UPDATE CASCADE をつけれ。
0277NAME IS NULL
垢版 |
2005/04/20(水) 08:24:29ID:???
>>273 ①が正解ですね。無理に>>268の枠組の中で解を求めたのが
いけなかった。
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:???
ただの連番ならDBMSが勝手に作ってくれるからラクじゃん。
0281NAME IS NULL
垢版 |
2005/06/01(水) 01:20:28ID:???
>>279
伝票番号だって、車のナンバーだって、出席番号だって、電話番号だって、意味を持たないだろ。
(言葉遊びの語呂合わせなどは別として)

単に個別を識別するためのものだ。
世の中の仕組みがそうなっていることに気が付けよ。
0282NAME IS NULL
垢版 |
2005/06/01(水) 11:04:24ID:???
>>281
電話番号は意味あるよ。
地域コード - 連番
じゃん。
伝票番号も会社によって
YYYYMMDDXXXXX
とか当たり前にある。
0285NAME IS NULL
垢版 |
2005/06/01(水) 19:01:57ID:???
>>281
出席番号は連番だが名前の読みの50音順に並んでたりするから
そんな場合は意味を持っている、名前の読みについて少しは類推ができる、と
言えると思うがどうか。類推する側が50音順って決まりをわかってないといけないが。
転入生があると転入生は連番の最後で我慢してねとか、誰か転校しちゃうと欠番とかはあるんだろうが。

出席番号をつけるのにくじ引きで名前を引いてその順番に連番をつけるような
場合は、意味を持っていない、といえるかも。
連番であっても意味がある場合とない場合があるということではないのか。
0286NAME IS NULL
垢版 |
2005/06/03(金) 12:15:18ID:???
性別コードは0が女で1が男だよな！
0289NAME IS NULL
垢版 |
2005/06/03(金) 16:04:13ID:???
自己記述的なコードとゆーやつかしら
0290NAME IS NULL
垢版 |
2005/06/03(金) 19:24:36ID:???
>>278
＞「パーティ」ってスーパーセット設けるのって実際どうなんでしょう。

OOのやり方。DOAでは積極的にはやらない(と思う)。
0291NAME IS NULL
垢版 |
2005/06/05(日) 12:42:42ID:???
>>285
それは、出席番号順というのではなくて、50音順という、別の意味だろ。
出席番号順のデータを作成する際に、イニシャルデータを作る手順として、
たまたま50音順にデータを投入したと言うだけだ。
だから転校生は、一番後ろになるわけで。
入学受付順、背の順、という学校もあるし、それはたまたま50音の学校が多いと言うだけ。
0292NAME IS NULL
垢版 |
2005/06/06(月) 10:19:45ID:???
>>291
そういや転校生って、後ろにpushだったなあ・・・。
なんか懐かしくて胸キュンだ。
0293NAME IS NULL
垢版 |
2005/06/06(月) 14:46:53ID:???
>>292
俺の学校では違ったなぁ・・・

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

ただ、転校生やらが入ってきた場合はその都度、出席番号が変わっていた。
つまり、再度、生年月日やら五十音で並べ替えられる。
0294NAME IS NULL
垢版 |
2005/06/06(月) 15:07:48ID:???
>>293
健康カードとか、下駄箱とか、出席番号を記入して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:???
>>297
ほかのテーブルから外部キーとして参照する場合は
ID？出席番号？
0299NAME IS NULL
垢版 |
2005/06/06(月) 23:26:34ID:???
>293は
出席番号は出欠名簿リストの左端についてる番号ぐらいの利用しかなくて、
いつもは学籍番号ばっかり使ってるってことはないのか。
0301NAME IS NULL
垢版 |
2005/06/06(月) 23:58:33ID:???
>>298
IDじゃないと、297で言ってるメリットが得られないです。
途中で転校生の分、出席番号振りなおしても
下駄箱テーブルはID参照してれば影響なし。

物理的な下駄箱については、頑張って貰おう。
0302NAME IS NULL
垢版 |
2005/06/07(火) 01:39:29ID:???
最初から出席番号を 10, 20, 30 と、10おきにつけておけばいい。
転校生が来たら 25 などを割り振ればいいだけだ。
0303NAME IS NULL
垢版 |
2005/06/07(火) 04:43:41ID:???

　 　 　 ＼∧＿ﾍ　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　,,､,､,,,　/ ＼〇ノゝ∩ ＜　転入合戦、いくぞｺﾞﾙｧ！！　
　　　　/三√ ´∀｀)　/　 ＼＿＿＿＿＿＿＿＿＿＿＿＿　　,,､,､,,,
　　 　　/三/| ﾟＵﾟ|＼　　　　　　,,､,､,,,　　　　　　　　　　　　　　　　　　　　　　　,,､,､,,,
　,,､,､,,,　Ｕ （:::::::::::）　　,,､,､,,,＼ﾜｼｮｰｲ！！／　＼ﾜｼｮｰｲ！！／ 　＼ﾜｯｼｮｰｲ！！／
　　 　 　//三/|三|＼　　　　　／■＼／■＼ ／■＼　／■＼　 ／■＼　／■＼
　　　　　　∪　 ∪　　　　　　 （ ´∀｀　）´∀｀　）´∀｀　） ´∀｀　 （ ´∀｀　） ´∀｀　）
　,,､,､,,,　　　　　　　,,､,､,,,　　／■＼／■＼ ／■＼　／■＼　 ／■＼　／■＼
　　　　　　,,､,､,,,　　　　　　 （ ´∀｀　）´∀｀　）´∀｀　） ´∀｀　 （ ´∀｀　） ´∀｀　）
　　　　　　　　　　　　　（(　（つ　　ノ（つ　丿（つ　　つ（つ　　ノ（つ　　丿（つ　　つ
　　　　　　　　　　　　　　　 ヽ　 （　ﾉ（　ヽノ　）　）　） ヽ　 （　ﾉ （　ヽノ　　 ）　）　）
　　　　　　　　　　　　　　　（＿）し'　し（＿） （＿）＿）（＿）し'　し（＿） 　 （＿）＿）
0304NAME IS NULL
垢版 |
2005/06/07(火) 08:55:18ID:???
昔のBASICの行番号かいｗ
0305NAME IS NULL
垢版 |
2005/06/07(火) 10:35:19ID:???
なつかしいね！
と思ったけど、表示順みたいなカラムでは
今もやってるなー。
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と認識容易番号の2本立てでいくのがベストと考えて
いいでしょうか。この方法の問題点注意点が何かあれば。

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

0310NAME IS NULL
垢版 |
2005/06/08(水) 07:34:54ID:???
>>309
随分前のWEB+DBプレスのデータモデリングの記事に
にそこらへんの事がかいてあった。
今なら全部のバックナンバーのPDFが売ってるから
読んでみるといいよ。面白かった。

意味無し連番こそ、データの識別子であって、
業務上使うコードは、ユーザーさんが使う際の便利な
アクセスパスにすぎないので、ごっちゃにしちゃ
いかんですうんぬんてな事が書いてありました。
0312NAME IS NULL
垢版 |
2005/06/08(水) 10:15:30ID:???
310の続き

じゃあOracleのRowIDやPostgreのOIDを
使えばいいじゃんって話しになりそうですが
そうすると、ひょんな事からエクスポート・インポートなど
する事になったりすると変わっちゃうのでだめですねー
てな事も書いてあった。
0313NAME IS NULL
垢版 |
2005/06/08(水) 11:35:13ID:???
>>310
WEB+DB PRESS特別総集編ってやつですね。
読んでみます。
0314NAME IS NULL
垢版 |
2005/06/08(水) 22:43:34ID:???
>>302

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

>>310

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

0315NAME IS NULL
垢版 |
2005/06/09(木) 00:38:03ID:???
>>314
勿論、学籍番号は見やすいほうがいいでしょう。
ただ、学籍番号ってのは業務で用いるコード、
特定のデータへのアクセスパスな訳です。

便利なアクセスパスってだけなので、
業務要件の変化によってどうなるもんか判らんので
データをアイデンティファイする識別子とは別にした方がよい、
と言うのが主旨。
意味無し連番ってのが、その識別子にあたります。
0316NAME IS NULL
垢版 |
2005/06/12(日) 11:13:50ID:???
WEB+DB PRESS特別総集編みました。
関係箇所がVol.11とVol.21に出てました。
どちらも著者は羽生彰洋さん。

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

結構詳しく説明されてます。これに反論するのは難しいか。
意味無し連番の今までの違和感が少しはなくなりました。
0317NAME IS NULL
垢版 |
2005/06/12(日) 23:52:13ID:???
>>316
俺も意味無しID、使ってはいたし
コードの洗替が楽ってのも判ってたけど
どうしても違和感があって、
それ読んで、識別子とアクセスパスって言い方で
すっきりしました。

はぶさん、この路線で本書くのかなと思ったけど
SQLドリルってのは、やられた。
0318NAME IS NULL
垢版 |
2005/08/11(木) 09:34:00ID:u6wEnJIp
age
0319NAME IS NULL
垢版 |
2005/08/16(火) 11:18:49ID:wzipZbWi
>>316
このスレみてWEB+DB PRESS特別総集編買ってきてました。
なるほどなぁ～と読みすすめてたのですが、一つ疑問が。

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

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

ちなみに作るとしたら以下のような交差エンティティを作成するのかな？
品種構造 構造ID,品種ID,商品ID 現在は1:m
単位構造 構造ID,単位ID,商品ID 現在は1:m
0320NAME IS NULL
垢版 |
2005/08/16(火) 13:19:07ID:???
>>319
ここで聞いてみよう
http://d.hatena.ne.jp/habuakihiro/

でもまあ、システムの規模や顧客の業務内容などなどで
最適解は色々ってのが答えなんじゃないかな。
正論かつ優等生ちゃんな答えでつまんないけどさ。
0321NAME IS NULL
垢版 |
2005/08/17(水) 05:35:09ID:???
>>320
サイト紹介してくれてありがとう。

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

私が担当するプロジェクトはそこまで大規模なものでもないので
今回は交差エンティティを定義しない方向で進めて行きたいと思います。
0322NAME IS NULL
垢版 |
2005/08/17(水) 10:39:17ID:???
>>321
いえいえどういたしまして。
なんか偶然だけど、凄いタイミングよかったね。

規模もそうだけど、
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:???
>>324
議論ではなく、同様ので命名規則を適用している方で
サフィックスだけでもどうやってるのかと意見をもらいたくて・・・。
何にせよ、スレ汚しごめ。
0326NAME IS NULL
垢版 |
2005/08/22(月) 23:01:53ID:???
Crsってサフィックスを見た事があるよ。
設計・命名者はメインフレーム出身の割と古い人。
0327NAME IS NULL
垢版 |
2005/08/23(火) 00:11:07ID:???
>>326
貴重な情報、ありがとうございます。
早速、関係するテーブル名を連結+CRSで命名したいと思います。
0328NAME IS NULL
垢版 |
2005/08/23(火) 08:35:13ID:???
でも英語としてあってるかどうか知らんよ。
あとで保守する人にだせーとか言われるかもよ。
0329NAME IS NULL
垢版 |
2005/08/25(木) 01:16:39ID:???
データウェアハウスの論理設計に関していい書籍やネット上の情報があったら教えてください。
0332NAME IS NULL
垢版 |
2005/08/27(土) 00:08:36ID:???
>>330
m:m確定ならそれいいね！
1:m, m:1かm:mのどちらかわからないときは"REF"だけでもよさそうだね。
0333NAME IS NULL
垢版 |
2005/08/28(日) 15:30:31ID:???
>>329
DWHは書籍とかネットとかの情報は少ないよ。

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

だから、通常は業務でデータを蓄積してる、ちゃんとモデリングや正規化されたDBとは別に
DWH用のDBを別に構築して、そこへ必要なデータを夜間バッチとかで流し込む。
0334NAME IS NULL
垢版 |
2005/08/29(月) 17:39:42ID:???
>>329
Ｍ＄のＳＱＬ鯖に付いてる。
使ってみると分かるとおもうし、
ＭＳＤＮにも資料落ちてるんじゃないかな。

要は、どんな分析をしたいのかをある程度
見極めとくことだと思う。
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:???
>>336
>なぜ２に数量があって３には無いんです？
申し訳ありません。私のミスです。
仰るとおり３は数量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:???
>>337
数量もCurrencyで問題ないかと思いますが・・・
浮動小数点じゃ誤差が出てしまうのではないかと
0339NAME IS NULL
垢版 |
2005/09/02(金) 16:12:47ID:???
>>338
>数量もCurrencyで問題ないかと思いますが・・・
>浮動小数点じゃ誤差が出てしまうのではないかと
商品のテーブルには数量は含めない予定です。
数量はあくまで伝票入力時に入力するものとし、標準では常に１とするからです。

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

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

う～ん、どっちのほうがいいんだろ？
0340NAME IS NULL
垢版 |
2005/09/02(金) 21:53:32ID:???
だれが数量を商品マスタに入れようと思うかよ
複数の重量にしてもそんなこと聞いてないと思うが
0341NAME IS NULL
垢版 |
2005/09/03(土) 02:22:57ID:???
>>337
> 汎用性を考えFloatやDouble等で定義すれば解決
> 重量に関しては、2kg,5kg等というような複数の重量は無いとのことです
>>339
> 商品のテーブルには数量は含めない予定です。
> 数量はあくまで伝票入力時に入力するものとし、標準では常に１とするからです
0342NAME IS NULL
垢版 |
2005/09/03(土) 02:26:28ID:???
　重量
　縦
　横
　奥行

って数量ですよ？
お客さんから寸法や重量を指定されるたびに商品を追加するとか？
0343NAME IS NULL
垢版 |
2005/09/03(土) 02:47:23ID:???
洗剤10ｋｇタンクを10本
洗剤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
>>335
これはRDBMS(ER図)の限界として、とてもよく出てくる典型的な問題ではないかな？
商品をオブジェクトとして保存できるのであれば、
商品基礎クラスを継承した３つの商品クラスを別途用意してしまえばいい。

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

これらはどっちが正しいということは無くて、状況に応じて使い分ける。
テーブルを分けると後で検索にjoinを多用しないといけなくなるので、
（１）のアプローチを採用することのほうが経験的には多い
0345NAME IS NULL
垢版 |
2005/09/04(日) 18:53:02ID:???
>>344
自分は商品基礎情報テーブルと個別商品テーブル×３を作ることが多いけど。
0346NAME IS NULL
垢版 |
2005/09/04(日) 19:13:35ID:???
>>344
10個くらいが境界かな。
さすがにsubclass tableを100個tableを作る気はしない。

ちなみに(1)は正規化違反なんだっけ？
0347NAME IS NULL
垢版 |
2005/09/05(月) 08:51:17ID:???
ORACLE Designer vs ERwin
比較したメリットデメリットをあげてください。
使用するデータベースはOracle 10g
0348NAME IS NULL
垢版 |
2005/09/05(月) 11:23:23ID:Kv8Ouo/7
両方使い込んでる奴なんて居ない。
0349NAME IS NULL
垢版 |
2005/09/05(月) 12:03:55ID:???
>>344
この問題、そもそもの現実のものを、どのように扱ってるかが主眼だと思う。
その３つの商品群が混在して扱われているのであれば、テーブルは１つ。
部署違いでまったく別の群をたまたま同じように扱っているのであればテーブル３つ。
データベースってのはあくまで現実の記録だから、そこを主眼にすることは大事だと思う。

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

あと、理想論・原則論からいけば、NULLフィールドやダミー値のフィールドを設けるのは良くない。
同一テーブルでどっかのフラグがこれなら、このフィールドは何とか。
なので、本来は３テーブル分割でまとめてみるViewを提供でよいと思う。
0351NAME IS NULL
垢版 |
2005/09/05(月) 21:27:48ID:???
商品マスタ・部品マスタはあくまで一元化しないとヤバいとおもうが…
縦横高さなんて仕様情報を、基本マスタに、要素ごとに列を与えて載せるべきなのか？
0352NAME IS NULL
垢版 |
2005/09/05(月) 23:22:00ID:???
DB設計の場合、パフォーマンス用件がどうしたって重要になってくるからね。
多少汚くても一個のテーブルで収まってくれると嬉しい
0353NAME IS NULL
垢版 |
2005/09/07(水) 21:00:08ID:???
上であがってるWEB+DB PRESS特別総集編Vol.11とVol.21では
ハードウエアも進化してるので理想論をもう少し追求してもよいのでは？とありますね。
なので分割したテーブル数が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,材質,最小値,最大値
プライマリキーはID
Uniqueキーは材質,最小値,最大値でいいんじゃない？
順序が必要なら各材質毎にNo.振って材質,No.にUniqueキーを設定するとか。

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

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

外してたらすまそ。
0357NAME IS NULL
垢版 |
2005/09/20(火) 02:19:56ID:???
>>356
お回答ありがとうございます。

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

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

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

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

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

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

俺なりには検討してみたんですが、
RDBMSの制約では実現できないんでしょうか・・・。
0358NAME IS NULL
垢版 |
2005/09/20(火) 05:41:11ID:???
>>357
構造は>>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:???
>>363
> 販売管理の売上データなどで売上伝票番号がキーとなる
> データがあるのですが、この番号は意味のない連番なんですが
> (但し、その番号を入力して該当すれば売上伝票を表示します。)
> 別途、意味なしキーを追加したほうがいいのでしょうか？

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

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

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

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

俺なら業務上のキーをそのままセットさせる。
一応ユニーク制約はつけておいて。
はっきりとメリットを説明できないことはやらない
0365363
垢版 |
2005/12/02(金) 20:53:58ID:???
>>364
webアプリなどでは有効ということですね。

>俺なら業務上のキーをそのままセットさせる。
マスタのキーが変更になるとデータまで変更しなければ
ならなくなると思うのですが・・・・
でもデータを見たときにわかりやすいというメリットはあります。
どちらがいいのでしょうか。
0367NAME IS NULL
垢版 |
2005/12/03(土) 01:52:24ID:???
つか、マスタのキーってのはそういう変更が起きないように慎重に設計するんだよ。
コード体系とか適当に作って、後で泣きを見るってのはよくある話だ
0368NAME IS NULL
垢版 |
2005/12/12(月) 11:39:12ID:???
設計時にうまくできてても、使ってるうちに使い方も変わって、なんだか最適から外れてきそう。
現場の使い方の詳細な知識が有れば、余裕もって作り込み出来るかも知れないけど、現実は与えられた情報でヤマかけて作り込むしか無いな。

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

ニューススポーツなんでも実況