ホーム フォーラム一覧 - トピック一覧 astah*への改善アイデア
ER図の記述について | 投稿するにはまず登録を |
| スレッド表示 | 新しいものから | 前のトピック | 次のトピック | 下へ |
| 投稿者 | トピック |
|---|---|
| kangol | 投稿日時: 2008-6-16 15:42 |
新米   登録日: 2008-6-16 居住地: 投稿: 7 |
ER図の記述について JUDE Professional 5.2.2にてER図の記述をしております。
SQLのCreate文の生成やEXCEL表へのスキーマ出力など 非常に重宝しているのですが、利用者の視点でいくつか 問題を見つけましたので報告致します。 １．属性にPK、FK、NOT NULL制約等が持てて、図でも 表でもSQLでも反映されるのですが、INDEXが付与できる とJUDE内で全てを解決できるので助かります。表に出す だけであれば「定義」に記述することで解決するのですが SQLを別途作る必要があるため、対応いただけると助かり ます。 ２．主キーに対するシーケンスオブジェクトの生成への対応 や、SQLや表への反映が行えると助かります。 ３．あるエンティティのPKとあるエンティティのFKがリレ ーションを持つ場合は記述出来るのですが、あるエンティティ の主キー以外の属性とあるエンティティのFKのリレーション が記述できないようです。さらにFKとして明示しないが同じ 属性でリレーションシップを図示したい場合の記述も出来ない ようです。 JUDEの仕様に関する内容もあるとは思いますが、インデックス、 主キー以外のリレーションは実用上不可欠と思いますので、 よろしくお願い致します。 |
| kangol | 投稿日時: 2008-6-16 18:20 |
新米 登録日: 2008-6-16 居住地: 投稿: 7 |
Re: ER図の記述について もう一点だけ小さなことかもしれませんが、EXCEL
表への出力されたエンティティの順番を変更できると 助かります。「エンティティ一覧」シート内の順序や シート毎のエンティティがJUDE内で保持されている 順番（生成順？）に従っているため、プロジェクト 内での参照頻度の高いエンティティが下位に行くこと があり、また関連するエンティティはひとまとまりで あって欲しいため、順序を変えることができることが 望ましいです。 |
| joba | 投稿日時: 2008-6-17 9:06 |
開発者   登録日: 2006-4-27 居住地: Fukui 投稿: 597 |
Re: ER図の記述について kangolさん、こんにちは。
ER図に関する大変丁寧な要望のご連絡、誠にありがとうございます。  またメールでもご連絡いただき、ありがとうございました。 いただいたご要望に関して、早速、調査・対応検討致します。 |
| joba | 投稿日時: 2008-6-25 14:51 |
開発者 登録日: 2006-4-27 居住地: Fukui 投稿: 597 |
Re: ER図の記述について kangolさん、こんにちは。
返信が遅くなりまして申し訳ありません。 引用： １．属性にPK、FK、NOT NULL制約等が持てて、図でも表でもSQLでも反映されるのですが、INDEXが付与できるとJUDE内で全てを解決できるので助かります。表に出すだけであれば「定義」に記述することで解決するのですがSQLを別途作る必要があるため、対応いただけると助かります。 いずれもご要望としてお預かりして、今後の対応を検討致します。 INDEXやシーケンスオブジェクトは重要なものであることを認識しておりますが、DBの種類によりSQLが変わることもあり、現在まで優先度を高く設定せずにきました。今回ご要望をいただいたことで、今後JUDEとしてどの程度DB依存の部分に踏み込むべきか検討致します。 【参考情報】 大変手間のかかる方法ですが、現在のJUDEで、APIを利用してkangolさんの目的を達成することができます。モデルの情報としては定義やタグ付き値で設定して、その情報をJUDE APIを通して参照して、独自にSQL出力などを実装いただく方法です。JUDE APIについては、製品サイトのJUDE APIをご覧下さい。 引用： ３．あるエンティティのPKとあるエンティティのFKがリレ ーションを持つ場合は記述出来るのですが、あるエンティティの主キー以外の属性とあるエンティティのFKのリレーションが記述できないようです。さらにFKとして明示しないが同じ属性でリレーションシップを図示したい場合の記述も出来ないようです。 恐れ入りますが、ER図の仕様としてご連絡のような記述について存じません。今後の対応検討における参考のため、こちらの仕様に関する資料、又はこのようなリレーション記述に対応しているDB設計ツールをご存知でしたら教えていただけると幸いです 引用： もう一点だけ小さなことかもしれませんが、EXCEL表への出力されたエンティティの順番を変更できると 助かります。「エンティティ一覧」シート内の順序やシート毎のエンティティがJUDE内で保持されている順番（生成順？）に従っているため、プロジェクト内での参照頻度の高いエンティティが下位に行くことがあり、また関連するエンティティはひとまとまりであって欲しいため、順序を変えることができることが望ましいです。 そうですね。こちらもご要望としてお預かりします 現時点ではエンティティ定義書出力時のダイアログにおいて、対象エンティティを選択する際、表のヘッダー部分をクリックすることで選択した項目による簡易なソートが可能です。ただし、個別の順序指定には対応しておりません。 この度は、大変丁寧な要望のご連絡、ありがとうございました。 |
| Shontec | 投稿日時: 2008-8-18 14:06 |
新米 登録日: 2008-7-18 居住地: 投稿: 1 |
Re: ER図の記述について 横レス失礼します。
kangolさんのご要望には、普通ER図では、代替キー（AK）や逆方向エントリ(IE)で対応することになると思います。 まだ、JUDEのERを試していないのですが、JUDEのERでAKやIEに対応していれば、実用上問題は無いと思います。 --------------------------------------------------------------------- 【kangolさんのご要望】 あるエンティティのPKとあるエンティティのFKがリレ ーションを持つ場合は記述出来るのですが、あるエンティティの主キー以外の属性とあるエンティティのFKのリレーションが記述できないようです。さらにFKとして明示しないが同じ属性でリレーションシップを図示したい場合の記述も出来ないようです。--------------------------------------------------------------------- 【jobaさんのご回答】 恐れ入りますが、ER図の仕様としてご連絡のような記述について存じません。今後の対応検討における参考のため、こちらの仕様に関する資料、又はこのようなリレーション記述に対応しているDB設計ツールをご存知でしたら教えていただけると幸いです --------------------------------------------------------------------- |
| joba | 投稿日時: 2008-8-19 11:03 |
開発者 登録日: 2006-4-27 居住地: Fukui 投稿: 597 |
Re: ER図の記述について Shontecさん、投稿ありがとうございました
引用： JUDEのERでAKやIEに対応していれば、実用上問題は無いと思います。 代替キー（AK）・逆方向エントリ(IE)は、次期バージョン(10月頃リリース予定)より対応致します。 kangol様とは、弊社サポートと直接メールでやり取りしたため、本フォーラムでの情報更新が中断したままでした。申し訳ありません。  |
| Kota | 投稿日時: 2008-9-30 14:58 |
開発者  登録日: 2006-5-9 居住地: 投稿: 151 |
Re: ER図の記述について Kota＠JUDE開発部です。
これまでJUDEのER図使っていてこの点はご不便に感じられていたと思いますが、 今回9/30リリースのJUDE/Professional5.4b1で、やっと対応することができました。 ・AK(代替キー) ・IE(逆方向エントリ) ・インデックス もちろん、以下でも対応しました。 ・DBリバースツールでのリバース (詳しくはDBリバースツールのドキュメントも更新されていますのでそちらもどうぞ。) ・SQL出力 (INDEX, UNIQUE CONSTRAINT)  ので、ぜひお試しください。 |
| ゲスト | 投稿日時: 2008-10-1 17:11 |
|
Re: ER図の記述について ゲストの「kangol」さんからの投稿です。
--- kangolです。  5.4b1を試用させていただきました。 残念ながら以前出させていただいた私からの要望は解決されて おらず、不具合の報告をさせていただきます。  まずINDEXに対する認識が異なっていると思います。INDEXと代 理キーや逆エントリは無関係です。INDEXは単純にカラムに対 して単体INDEXや複合INDEXが付けられるのみで、また昇順や 降順の指定や、INDEX名だけではなくINDEXの条件式も書ける方が 望ましいです。 （例：update_time:timestamp型のような場合に秒まで一致した Queryは行わずにdate(update_time)=current_dateのように 関数で指定することが多いです。この場合update_timeに対する INDEXは効果がなくdate(update_time)にINDEXを貼る必要が あります。関数に限らずQueryの形のままのINDEXが必要と書い た方が分かり易い？） 代理キーと逆エントリですが、こちらはエンティティ間のリレ ーションの両端のカラム指定で実現されるべきかと思います。 その際のカラムがUNIQUE制約があれば代理キーとして、制約が なければ逆エントリと開発者は認識するだけなので、ツールが 指定する必要はなく、ただ単一のカラムや複数のカラムに対 するUNIQUE制約をつける方法があればいいと考えます。 以下は操作性に対する報告になります。 INDEXの指定画面で複数カラムを選択して「＞」を押下しても一 番上の一つしか動きません。結局、複数回「＞」を押下する必要 があるのが操作性でおかしいと感じました。選んだ順序を反映 して移動して欲しいと思います。 「＞＞」を押下すると全てのカラムが移動するのもおかしいと 感じました。複合INDEXで全カラムを指定することは余程特殊な ケースですし、INDEXでは順序も意味があるためです。通常は単体 INDEXを基本として、少数カラムによる複合INDEXが無難な設計だ と思います？分かり易くするために使うことはないor「＞」が 複数選択可になれば「＜＜」も「＞＞」も不要と考えます。 βのうちに報告した方がより良いツールになると思い、厳しい意見 をたくさん書かせていただきましたが、期待の裏返しとして検討 よろしくお願いします。応援しています！  |
|
| okamura | 投稿日時: 2008-10-2 18:17 |
開発者  登録日: 2006-5-2 居住地: 投稿: 157 |
Re: ER図の記述について kangolさん、β版の確認とコメントありがとうございます。
引用：
確かに、ご指摘どおり、現状の仕様には問題があると思いますので、改善したいと思います。 整理してみると、本来は、論理と物理で次のような設定ができると理想なのだと思います。 [論理] [物理] キーグループ インデックス 代替キー(一意) 一意 逆方向エントリ(非一意) 非一意 一意制約 ここで、代替キーとインデックスは本来別モノですが、ツールの仕様として便宜的に、次のような対応を考えてもいいのかもしれません。 代替キー <----> 一意インデックス / 一意制約 逆方向エントリ <----> インデックス これに対して、β版では、次のようになっています。 [論理と物理の区別なし] インデックス(*) SQL出力では 代替キー(一意) → 一意インデックス / 一意制約 逆方向エントリ(非一意) → インデックス 現状、キーグループとしての代替キーや逆方向エントリを設定でき、SQL出力では、便宜上、それらをインデックスや一意制約として出力できる、という仕様になっています。 まず、少なくとも(*)は、インデックスではなく、キーグループなど別の呼び方をすべきですね。 また、これではインデックスの対応として足りていない。 理想のように論理と物理をしっかり区別して、それぞれ扱えるといいのですが、やや難しいため、次のように変更したいと思っています。 [やや物理より] インデックス 一意 非一意 □代替キーや逆方向エントリとしても扱うかどうか ＃このチェックがある場合、図でAKやIEの表示が可能 インデックスの昇順・降順については、この後の拡張を検討したいと思います。 引用：
確かにその通りですね。 「＜＜」と「＞＞」を削除し、「＜」「＞」ボタンでは複数移動するように改善したいと思います。 引用：
応援とてもうれしく思います。ありがとうございます。 |
| kangol | 投稿日時: 2008-10-30 16:18 |
新米 登録日: 2008-6-16 居住地: 投稿: 7 |
Re: ER図の記述について kangolです。
5.4を試してみました。 やはり少しおかしな感じです。 制約とリレーションとインデックスが混ざっている印象です。 １．ユニーク制約 ユニーク制約は表に対する制約であるため、通常は表に対する ALTER文で付与します（表作成時のCREATE TABLEでも構いません）。 『ALTER TABLE nnn ADD CONSTRAINT mmm UNIQUE (ooo)』 ２．インデックス インデックスは表とは独立したオブジェクトのため、CREATE INDEXで作成します。 『CREATE INDEX ppp ON nnn(ooo)』 現在のJUDEではここが混ざっていてUNIQUE制約だけ付ける ことが出来ず、生成されるDDLも以下のようになっています。 『CREATE UNIQUE INDEX ppp ON nnn(ooo)』 このDDLは表へのユニーク制約とインデックスを１コマンド で実行しますが、後日片方だけ解除する方法もありません。 ３．リレーション 外部キーの設定においてインデックスやユニーク制約は 必須ではありません。 『ALTER TABLE nnn ADD CONSTRAINT qqq FOREIGN KEY (rrr) REFERENCES sss(ttt)』 このnnnテーブルのrrrが参照しているsssテーブルのtttが プライマリキー以外を指定可能として欲しいのです。 実現方法として表と表をリレーションしてもプライマリキー 固定とするのではなくカラム選択の自由があればいいと思い ます。 始めに要望した3番目のリレーションの件から途中でインデ ックスやユニーク制約の話に広がったことで混乱させたの かもしれないですが、個別の対応をお願いします。 p.s INDEX作成時に表示を物理モードにしていても属性候補の カラムが論理名で表示されます。不具合かと思います。 |
| (1) 2 » | |
| スレッド表示 | 新しいものから | 前のトピック | 次のトピック | トップ |
| 投稿するにはまず登録を | |
