X



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

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画像を閲覧するためのプラグイン
0081NAME IS NULL
垢版 |
04/01/02 00:34ID:mdzOBQVK
Kさん 好循環  Aさん 悪循環  
 (健康体)  (喘息)

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:???
>>80は業務分析と設計の区別がついていないのか?
「業務分析」の結果に配属履歴が現れるかどうかは、「業務」によって決まる。
だから「モデリング対象の会社に社員の所属変更があるのなら」と言ってる。
業務は個別アプリケーションの都合で変わりはしないからな。
分析結果に履歴形式が現れた場合に、実際に履歴テーブルとして実装するかどうかは
設計段階で決めることで、トランザクション性能云々はこのときに考えること。

>>69-78はそういうことを踏まえずに、
配属イベントをすっとばして所属の話だけをしてるから、
それはおかしいっつってんの。
0083NAME IS NULL
垢版 |
04/01/02 09:56ID:???
>>82
>「業務分析」の結果に配属履歴が現れるかどうかは、「業務」によって決まる。

これは問題ないが、

>だから「モデリング対象の会社に社員の所属変更があるのなら」と言ってる。

ここがおかしい。所属変更があるということとその履歴が必要というのは
要件としてイコールじゃないから。

だから>>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:???
>おーい、>>69が業務分析だと言っている香具師がどっかにいたか?

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:???
>要は「T字型ER」での「業務分析の成果物」にはなんらかの「禁則」が
>あって、>>69はそれに反している、ということだろう?

そういうこと。回りくどくてすまん。
0091SS
垢版 |
04/01/15 00:32ID:???
 T字型ERってのは業務モデリング手法であって、
実装については何ら言及していないと理解してる。

 T字型でモデリングした後、実装で

 社員コード・名前・部門コード
 部門コード・部門名

なんて実装もありだと思われ
−−−−−−−−−−−−−−−−−−−−−−
 T字型マンセーの解説キボン
0092NAME IS NULL
垢版 |
04/01/15 12:38ID:???
>>91
もう一回ちゃんと本を読め
論理モデルと物理モデルの乖離を否定するのがT字形だぞ
0093SS
垢版 |
04/01/16 00:38ID:???
>>92

 それは幻想と思ってる。もう3回読んだよ(ry

 プライマリーキーがどれになるかがわからないリソースや
イベントの例に悩んでいてこう結論つけた。このまま実装す
るなら全テーブルに連番でも振らないと実装出来ない予感。

 DWH(データマート)やチューニングの話がミスディレクション
になってるんだよきっと。佐藤さんは推理小説好きなんだろう

 「論理データベース論考」のP198にこうある
・対照表を実装するのかしないのか、という点を判断する
・サブセットについては、最上位のセットと・・するのかを判断
・VEについては、派生源のentityに戻して実装するのか・・判断

 結局、実装では属人性を排除出来ていないじゃん(w

 まあそれでT字形の偉大さが毀損されると思わないけど、
本だけでチャレンジした人はきっとSDIにコンサルを依頼
するしかないのかも。毎度あり〜
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
>95

 実用書でなく単なる学者のたわごとだと言ってるのかな?
何十回も通読しないとわからないのは実用書ではないからね。
0097NAME IS NULL
垢版 |
04/01/20 00:49ID:???
そうか。3回読んだだけで、他人に説法できるほど理解できるのか。
神か仏だな。

まぁ、神や仏は他人を馬鹿にしたりはしないが。


俺は知ってるけど、お前ら馬鹿だなという書き込みほど役に立たないものは無い。
0098SS
垢版 |
04/01/21 03:37ID:???
>>97
> まぁ、神や仏は他人を馬鹿にしたりはしないが。

 神や仏でもないし他人を馬鹿にした覚えはないが。

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

 また数十回読むのでしょうか。大変ですね。
0099T型フォード
垢版 |
04/01/22 00:32ID:???
>>91
>  T字型でモデリングした後、実装で
>  社員コード・名前・部門コード
>  部門コード・部門名
> なんて実装もありだと思われ

 ちょっとマジレスすると、サブセットを上位テーブルに実装
するのは「アリ」だが、対照表を上位に実装するのはルール
違反だと思われます。

 T字形って、プライマリーキーを意識せず実装するっての
が信条のように思ってます。DBによって違うでしょうが、
連番を振ってプライマリーにするのも「アリ」でしょう(多分)。
0100NAME IS NULL
垢版 |
04/01/22 19:44ID:???
>>98

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

へぇ〜。新書が楽しみだ。期待したいな。
0101 
垢版 |
04/01/25 23:31ID:HFlIdygC
 渡辺幸三ってひとの本がすごいっておもうんですがどう?
0102NAME IS NULL
垢版 |
04/01/27 11:18ID:???
ウルトラマンとガンダムどっちが強いかって喧嘩してる子供と同じだな

銀の弾など無いんだし、お前がそれで納得のいく仕事ができればそれでいいじゃないか…
0103NAME IS NULL
垢版 |
04/01/27 23:50ID:???
>>102
探しているのは銀の弾ではなくガンド・ロア クラスの兵器かと。
0104NAME IS NULL
垢版 |
04/01/31 03:52ID:???
DBDesigner使ってる人少ないのか?オープンソースの良ツール
なんだが。
http://fabforce.net/dbdesigner4/

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

Delphi使える人とか、日本語化してくれると尚良いなぁ。
0105NAME IS NULL
垢版 |
04/01/31 04:51ID:???
日本語使いたきゃ別のツール使うんじゃない?
SIとかさ。
0106 
垢版 |
04/02/12 22:56ID:???
シンプルな商品マスタはこんなのでしょう

〔商品M〕   商品C  販売単価  仕入単価
         ~~~~~~
         ABC    \300     \200

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

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

−−−−−−−−−−−−−

 年1回半分ほども単価変更が発生すると徹夜
作業になってしまうのです。さてどうしましょ?
0107NAME IS NULL
垢版 |
04/02/13 00:00ID:???
まずは、なぜ徹夜作業が必要なのか考えてみ。
0108NAME IS NULL
垢版 |
04/02/13 17:07ID:???
>>106
長年の疑問だが、商品マスタの単価の扱いは、どうするのがベストなのだろう。

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

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

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

要件にもよるだろうけど、この辺、みんなどうしてるのかな。
0109NAME IS NULL
垢版 |
04/02/13 22:16ID:???
>この場合、適用年月日の判断が入るため、SQL一発で単価を取得できない。

なんで?
0110NAME IS NULL
垢版 |
04/02/13 22:48ID:Y1CFmVqe
>>108
>厳密に正規化すれば、単価は、商品マスタとは別に、
>商品単価マスタ{商品コード、適用年月日、単価}を作ることになるけど、

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

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

 ホストだと、過去データの洗い換えするためにそういう実装
することがあるけど、バッチ処理をなくす方向で考えた方が、
パソコン(鯖)向きだと思う
0111108
垢版 |
04/02/14 00:32ID:???
>>109
え、できるの?
できるなら、ぜひそのSQLを教えて欲しい。

>>110

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

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

別にT字型ER手法をマンセーするつもりはないけど、佐藤氏の本は色々考えさせられる。
0112NAME IS NULL
垢版 |
04/02/14 09:17ID:CE18kft9
>111

:問い合わせ年月日 時点の単価を求めたい場合

select A.商品名, B.単価
from 商品マスタ A
join 商品単価マスタ B on ( B.商品コード = A.商品コード )
where A.商品コード = :問い合わせ商品コード
and B.適用年月日 <= :問い合わせ年月日
and not exists (
select * from 商品単価マスタ
where 商品コード = A.商品コード
and 適用年月日 <= :問い合わせ年月日
and 適用年月日 > B.適用年月日
)
0113108
垢版 |
04/02/14 16:02ID:po36sjDo
>>112
Thanks!!!

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

でも、理屈が理解できん(泣
Exists、Not Existsを勉強し直そう。
0114108
垢版 |
04/02/14 16:51ID:po36sjDo
直積表を書いてみて、やっと理解できた。

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

重ね重ねThanks>>112
0115NAME IS NULL
垢版 |
04/02/15 00:59ID:EVaACx4p
>>111
>「eventの定義は、「DATE」が帰属するentityである、とする。」だそうだ。

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

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

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

 ただ、T字形でどうなるかはわからない。乞詳しい方
0117NAME IS NULL
垢版 |
04/02/15 22:58ID:fM+BL24T
>>112
スレ違いで申し訳ないです。
こっちのほうがシンプルでよさそうな気がするけど、、、ダメ?

select A.商品名, B.単価
from 商品マスタ A
join 商品単価マスタ B on ( B.商品コード = A.商品コード )
where A.商品コード = :問い合わせ商品コード
and B.適用年月日 <= :問い合わせ年月日
order by B.適用年月日 desc;

レコード数の抑制は
PostgreSQL、MySQL だと LIMIT句、SQL Server だと top が使える。
0119 
垢版 |
04/02/17 00:22ID:???
>>117
> >>112
> こっちのほうがシンプルでよさそうな気がするけど、、、ダメ?

 結果は同じだけど、order byを使うと普通コストが高い
10万件程度のデータを作ってテストすればわかる
(はず・・実装によって違うから)
0120NAME IS NULL
垢版 |
04/02/21 02:48ID:yCOAnZGt
 TH法ってのを聞いたのですが、
メリット・デメリットとかご存知ですか?

 マイナ〜な手法なんでしょうか
0121NAME IS NULL
垢版 |
04/02/21 19:49ID:???
TH法がマイナーっていわれると時代を感じるな
椿さんの本を買って読め
0122NAME IS NULL
垢版 |
04/02/22 13:50ID:/gnEdeW3
 amazonで調べると、椿正明って人ですか?

 過去の苦い経験からオーム社ってのが信用
出来ないのですが・・・書評も1件しかないって
のは終わってる本なんじゃないですか
0123 
垢版 |
04/02/26 02:00ID:???
 DOAを調べてると、なにげに面白そうな事をやってました
http://www.doaplus.com/

こういう学術的な(?)会と2chは無縁でしょうか
どなたか参加されてます?
0124
垢版 |
04/02/26 08:20ID:qvDCVOss
*現代の* DOA を学ぶのによい一冊を教えてください。
600ページくらいまで、洋書でもまったく構いません。

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


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

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

0125124
垢版 |
04/02/26 08:21ID:qvDCVOss
【自分の考える対比】
・機能要求、非機能要求を項目として列挙する。
→ 要求定義だから変わらないと思う。

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

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

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

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

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

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

0126NAME IS NULL
垢版 |
04/02/27 00:37ID:Pd0YyzCW
DOAでUMLは重要ですか?またどの図を使いますか?
0127NAME IS NULL
垢版 |
04/02/27 22:42ID:jks+KnjA
>>124
>600ページくらいまで、洋書でもまったく構いません。

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

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

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

 ただ、これには正規化の方法論が書かれていません。同じ著者の
「業務別データベース設計のためのデータモデリング入門」の
前半は実務で使うための初心者向け解説になっています。
たった3つのルールだけで、完璧な正規化(1〜5&BC)にする
秘伝も書かれています。たぶんこれは著者オリジナルでしょう。
0128NAME IS NULL
垢版 |
04/02/29 16:02ID:???
>>112
商品名の履歴が必要なシステムで、

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

はどうしたらいいですか。結構複雑になりそうな気がしますけど。
0129 
垢版 |
04/03/04 00:46ID:???
>>128
 無視されてるのじゃなくて、答える必要を感じてないんですよ

 求めたい日付を「問合せ年月日」に入れるSQLですから、
求めたい日付がわかってるなら困ることないですね(*^ー゚)b
0130128
垢版 |
04/03/04 08:49ID:???
勘違いしてました。
全然問題ないですね、問い合わせ年月日が1年前でも。
失礼しますた。
0131 
垢版 |
04/03/04 21:25ID:???
>>130

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

 こんなのは流石にSQLで書けないでしょう
0132(゜Jし゜)
垢版 |
04/03/04 23:28ID:???
昔、我が社で開発した前年度比計算プログラムでは、
うるう年のチェックをしてなかったので、先月末に大パニックになったらしい。
0133 
垢版 |
04/03/05 08:08ID:???
>>132

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

 2/29が日曜だったので大きな混乱がなくてよかった
0134NAME IS NULL
垢版 |
04/03/11 16:00ID:???
>>131
各年の基準日をテーブルに入れておけば
基準日からの日数を計算してSQLで処理できそうだけど
そんなに甘いもんじゃない?
0135NAME IS NULL
垢版 |
04/03/25 00:07ID:SVaksVzX
age
0136NAME IS NULL
垢版 |
04/05/23 22:43ID:???
ERすたでぃおのライセンス高すぎ
0137NAME IS NULL
垢版 |
04/06/29 00:24ID:4yFnbnwy
総勘定元帳のテーブル作ってみたら凄い横長になっちまったんですが、どうしたもんでしょう・・・

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

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

やはりカラムに年や月を作ってレコード分けてしまうべきなんでしょうか?
どなたか有効な意見をいただけると幸いです
0138NAME IS NULL
垢版 |
04/06/29 07:07ID:???
>137
データの発生元が異なる物を同じテーブルに入れない方が良い.
0139137
垢版 |
04/06/29 20:40ID:???
すると例えば、こうでしょうか

部門、勘定科目、会計年度、繰越残高貸借区分、繰越残高、借方金額1〜12、貸方金額1〜12
0140NAME IS NULL
垢版 |
04/06/30 01:09ID:???
>139
借方金額、貸方金額は別テーブルから導出できない?
導出可能なデータはViewでもってもテーブルにもたない方が良い.
よほど速度を気にする場合は別だが.

総勘定元帳 ってのは 記録媒体 だよね?
記録媒体の項目を単純にテーブルにマッピングしてはだめだよ.
データ発生源が何かをちゃんと考慮してあげないとデータ再利用性が低下する.
0141137
垢版 |
04/06/30 03:14ID:???
うーん、そうすると仕訳の明細を持ってるテーブルから算出する形になるかな?
いちいち計算させるのはどうかと思ったのでテーブルに持たせた方がいいかなあと

まあ、元帳や試算表を出すのは月次と決算の時ぐらいだから個々の勘定を画面に出す時の
速度に問題がなければ、わざわざテーブルに持たせる必要はないんでしょうけど・・・
0142NAME IS NULL
垢版 |
04/06/30 06:21ID:???
>141
>> いちいち計算させるのはどうかと思ったのでテーブルに持たせた方がいいかなあ

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

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

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

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

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

0144137
垢版 |
04/07/01 21:55ID:???
>>142-143
ありがとうございます
大変、参考になりました

また、意見がほしくなったらココ来ますね
0145NAME IS NULL
垢版 |
04/07/04 01:59ID:SPlLydxx
クラスタ表って、どのくらい使われてるのだろう。
とりあえず、俺が設計するなら一生使いたくないのだが。

クラスタキーの利用頻度、メリット・デメリットを知りたい
0146NAME IS NULL
垢版 |
04/07/08 22:31ID:???
T字型ERってどうですか?
0147NAME IS NULL
垢版 |
04/07/08 23:59ID:???
>145
>> 俺が設計するなら一生使いたくないのだが。
なぜ?

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

>146
使い用.
0148NAME IS NULL
垢版 |
04/07/09 00:09ID:???
途中で送信してしまった.

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


0149NAME IS NULL
垢版 |
04/07/23 10:53ID:???
>>146

      r;ァ'N;:::::::::::::,ィ/      >::::::::::ヽ
.      〃  ヽル1'´        ∠:::::::::::::::::i
       i′  ___, - ,. = -一   ̄l:::::::::::::::l
.      ! , -==、´r'          l::::::/,ニ.ヽ
      l        _,, -‐''二ゝ  l::::l f゙ヽ |、 ここはお前のER図じゃねえんだ
        レー-- 、ヽヾニ-ァ,ニ;=、_   !:::l ) } ト
       ヾ¨'7"ry、`   ー゙='ニ,,,`    }::ヽ(ノ  「ラピュタ」の中にでも書いてろ
:ーゝヽ、     !´ " ̄ 'l,;;;;,,,.、       ,i:::::::ミ
::::::::::::::::ヽ.-‐ ト、 r'_{   __)`ニゝ、  ,,iリ::::::::ミ    
::::::::::::::::::::Vi/l:::V'´;ッ`ニ´ー-ッ-,、:::::`"::::::::::::::;゙ ,  な!
:::::::::::::::::::::::::N. ゙、::::ヾ,.`二ニ´∠,,.i::::::::::::::::::::///
:::::::::::::::::::::::::::::l ヽ;:::::::::::::::::::::::::::::::::::::::::::/ /
::::::::::::::::::::::::::::::! :|.\;::::::::::::::::::::::::::::::/ /
0151NAME IS NULL
垢版 |
04/09/20 19:27:25ID:6Fl/7m0x
visio2003なんですが、データベースのER図で
ただの矢印でなくリレーションの種類によって
蛸足とか丸印とか付いてるのを見かけます。
あれはどうやったら出せるのでしょうか?
0152NAME IS NULL
垢版 |
04/09/22 12:16:06ID:???
2000しか知らないけど、線のプロパティで始点と終点の形状を弄れば出てくるぞ。
0153NAME IS NULL
垢版 |
04/09/24 16:52:16ID:AXzql5sY
たとえば顧客マスタで、顧客には最大5人まで担当者がいる場合に、

顧客コード・顧客名・担当1・担当2・・・担当5
とするか、

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

担当者の最大値が決まっている場合には繰り返し項目にならないと
思うので(違ってたら指摘して!)、正規化違反にはならないと
思うのだが、作ろうとしてるテーブルの列数が40位になりそう
なので、分けたほうがいいのかしらんと迷ってます。
0154NAME IS NULL
垢版 |
04/09/24 17:40:43ID:???
迷うならとりあえず正規化しとけ。
プログラミング局面では、最大値が決まっていようがいまいが正規化されてるほうが楽な事が多いよ。
担当者が3人以上いる顧客を抽出・・・ってな要件が出たとき、横に長いテーブルだとマンドクサ
あくまで例えだけど。
0156NAME IS NULL
垢版 |
04/09/25 01:29:10ID:axxmUZh0
>>154
でも担当者を横一列に並べようとする時に
正規化するとめんどくさいですね。

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

でも>>154の要件もあるかも知れないし
出力する局面でどっちにするか判断するって
ところじゃないでしょか。
0157NAME IS NULL
垢版 |
04/09/26 00:57:28ID:???
>>156
出力する局面で正規化するしないを判断するなんて論外。

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

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

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

そんなことはない。
「最大値が100だから繰り返し項目じゃないです。」
って言われても納得できないだろ?
0158156
垢版 |
04/09/26 10:22:16ID:Etehnh4k
レスくれた人さんきゅ。
繰り返し項目の正しい定義ってなんだろうね。
俺っちは、最大値が決まってる場合、担当1・担当2・・・というふうに
2次元の表にできるから、繰り返し項目にはならないのかと思ってた。

0159156
垢版 |
04/09/27 10:26:37ID:p0HsFnJ6
>>157
うーんそうか、流石に5人ともなると前詰とか考えなきゃいかんわけか。
実は俺がやったシステムは担当者は2名だったんで
正規化してませんでした(設計は別の人)。

2名だと正・副のニュアンスもあるからあえて正規化しなかったって
話かも知れなかったですね。うーん。
0160NAME IS NULL
垢版 |
04/10/08 07:13:32ID:???
担当1・担当2のようになるなら繰り返し。
最大値が決まってるというのは幻想で、実は今だけってのが現実
0161NAME IS NULL
垢版 |
04/10/08 07:15:55ID:???
最大値を制限するのはプログラム側でなくDBのトリガや制約等の機能を利用し
て制限するのが普通
0162NAME IS NULL
垢版 |
04/10/08 07:16:48ID:???
とにかくやつらにプログラムさせるな、が基本
0163NAME IS NULL
垢版 |
04/10/08 07:52:30ID:???
>>161
ユーザーにやさしくエラーを返してあげるためにプログラム側での工夫も必要?
0165NAME IS NULL
垢版 |
04/10/09 01:08:08ID:???
>163
制約エラーが発生すればエラーメッセージを出すようにはプログラムする
普通のエラー処理のある言語なら問題なく可能
制約でのエラーの方がプログラムをほぼしなくて済むので良い

とにかくやつらと、そしてわたしにプログラムさせるな、が基本である事にかわりない
プログラムは組めば組むほどバグが増加する物、それはだれが作成してもだ
0166NAME IS NULL
垢版 |
04/10/09 14:07:44ID:WoYiUuS/
>>165
C/Sの業務アプリなんかだとそう理想どおりいかないんですわ。

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

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

で、制約・アプリ両方盛り込むと二重管理になる。
どうしたもんかなあ、ってところで上のスレは止まってる。
0167NAME IS NULL
垢版 |
04/10/09 16:04:43ID:???
アプリ側でのバリデーションなんてWebだろうが業務アプリだろうが当然すると思うけど
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:???
>>166
DBMSの制約情報を動的に読みとってアプリ側でチェックするような仕掛けを
作ればいいのでは?
結局は二重だけどDBMS側をいじればアプリ側も追従してくるようにすれば
目的は達成できる気がする。
0170NAME IS NULL
垢版 |
04/10/10 14:11:41ID:???
それやるとアプリのDBMS依存性が高くなる
 ↓
ライブラリ/ミドルウェア層にまとめちゃおう
 ↓
だったらDBMSの制約情報読み取るよりも、最初からこっちで
管理した方が融通が利いて良いよな

SAPとかそんな感じだよね
0171165
垢版 |
04/10/10 19:39:45ID:???
>166 >169
わたしの所はあるアプリでDB定義を書くのだが、そこからSQLと
Valid用XMLが自動生成されるようになっている







0172NAME IS NULL
垢版 |
04/10/17 20:38:10ID:gvma0fXW
DB設計ビギナーです。
相談に乗ってください。

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

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

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

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

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

どうするのが一般的なんでしょうか。
またどうするのが楽なんでしょうか。
0173NAME IS NULL
垢版 |
04/10/18 01:10:05ID:???
合併した部署は、新しいIDを振ればいいのでは?
0174NAME IS NULL
垢版 |
04/10/18 09:55:59ID:???
>>172
一般的な方法として、やるとしたら(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:???
(3)間違えたので修正

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

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

生徒
人id(主キーかつ外部キー:人->人id),先生id(外部キー:先生->人id)
0177175
垢版 |
04/10/18 16:19:55ID:???
すいませんがageさせて頂きます。
レスを投稿する


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