【より良い】データモデリング【モデルを】
モデリングツールっていくらくらいすんの? visioって6万くらいでしょ? ほかのは? ageるな! ヴォケッ!! ドラゴンボール厨が寄ってくるだろ! 光る雲をつきぬけ フライ亜ウェー 体中に広がるパノラマー ドラゴンボール厨うざいが >>17-19 の流れに思わず笑ってしまった。 ワダサン<--------------------幹部 尊敬される ttp://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/vsent7/html/dvcondatadesign.asp 独学でDB設計を勉強するのに、お勧めの書籍などありますか? また、練習方法とかあったら教えてください。 >>26 勉強したいデータベース製品を絞り込むことから はじめたほうがいいよ。 あとDBと書くと今の時期 ドラゴンボール設計って感じに 見られてしまう。。。(わけないか) >>26 ずばりAccess。会社でOracleのCDがゲットできるなら家のPCにインストル してそれで遊ぶことも出来ます。この場合もAccessと併用して取り扱うと 能率が向上します (SQL PLUSかナニかでクエリーを投げる→出てきた結果とAccessで覗き見ている テーブルのデータを比較等) 会社にOracleなどのソフト類がない場合,自宅で練習にはとりあえずAccessでしょう。 自分で買ってもそれなりに安い (そうしなくても大概は会社にCDあるからそれを自宅のPCに 以下自粛) のとヘルプがしっかりしているから。 Access‐Oracle間はクエリーの命令式等多少の違いはありますが 基本的な取り扱い方はほぼ同じです。 データベース設計の一番の肝は データをどう整理していくか なので (俺の意見ですがどうなんですかね)表領域の取り方とかそういう カコイイことは色々習熟してから手をつけたほうがいいでしょう。 >>26 DB2 でも勉強できるよ。 公的資格もオラオラと同様にあるし。 >>30 ,31 Oracleは、勉強しようとおもって一時OTN Pro入ってたから、 開発用ライセンスを持ってます。 勉強したいのは、DBに依存しない部分についてです。 このスレタイにあるような、モデリングなんかを覚えたいのですが・・・ Accessも、Office2000 Proがあるので、触れる環境ではあるし、 ちょっとしたものなら作れます。 正規化なんかもちょっとはかじりました。 しかし、その前の段階をどうやって勉強すればいいのかわからないんです。 DFDなんかも覚えてみたはいいものの、どこでどう使えばいいのかもよくわからないし・・・ >>32 DB2は、見たことすらないです・・・ ∧_∧ ∧_∧ ピュ.ー ( ・3・) ( ^^ ) <これからも僕たちを応援して下さいね(^^)。 =〔~∪ ̄ ̄ ̄∪ ̄ ̄〕 = ◎――――――◎ 山崎渉&ぼるじょあ どこぞで紹介されてた WEB+DB Pressの11号「RDBMS再入門」中々参考になった。 お勧め。 >>36 へ〜・・・ってォィ!完売じゃねぇかYO! ttp://www.gihyo.co.jp/magazines/wdpress/archive/Vol11 >> 37 まじで。 数日前に近くの書店で見かけて買ったんだけど。 渋谷のBook1にもあったと思う。 T字形の勉強をしたいのだがお勧めの本やサイトありますか? >>40 T字型?このスレで紹介されてた書籍に載ってたような・・・? 今手元にないんで、あとでISBNとか晒す。 (⌒V⌒) │ ^ ^ │<これからも僕を応援して下さいね(^^)。 ⊂| |つ (_)(_) 山崎パン IFED1Xで質問があるんですけど、いいですか? 1)モデルをカテゴリー化するときってどんなときですか? パートと従業員の例だと解りやすいのですが、逆にこれだと区分つけた方が 理解しやすくないですか? 2)1:NのリレーションでNが依存エンティティの時、Nの外部キーって必ず主キーにしなくては駄目? 教えて君で申し訳ないですけど、よろしくお願いします。 1)漏れはカテゴリ化はしない。 2)依存だと主キーになっちゃうだろうな。漏れはいつも非依存で設計してる。 どっちも漏れ流なので、IDEF1Xの正道としてどうかというのはわからん。 ER Creator http://www.modelcreator.com/ ってどうでつか? $150 程度と手頃そうなんでつが。 うう、ER Creator ファイルを xml で保存するのはいいが、文字を S-JIS ベタで 埋め込んでしまう。 SVG Catsがあるなら、Dynamic Drawがないのはおかしー気がする。 http://www.molips.com/jp/ 1足500円だけど色々組み合わせで3足なら1000円とかの靴下とかって どういう風に単品在庫&売上管理してのでしょうか? 単純に店員が人力でディスカウントという名の売上レコードを挿入するだけだと ミスは多そうだし、粗利率や回転率なんかも後々で必要になるとややこしい話になりそうなので 以下のようなこと考えてるのですが、王道みたいなのがあれば教えて下さい。 *売上明細テーブル* 品番 名 基本単価 値引 値引後単価 個数 金額 値引コード 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円 売上明細.金額など正規化でわざわざテーブルに値を保存しなくてもいいものも 説明の為含めています、あしからず。 >>50 わからんけど、それはデータベースのやることじゃなくて、 売上げ管理ソフトのプログラムがやることではなかろうか。 >>51 そうです。実際の値引き額のSETは 売上げ管理ソフトのプログラムからUPDATE系のストアドなどを叩こうと思うのですが データモデリングで王道のサンプルみたいながあれば知りたかったのです。 あとマクドナルドのバリューセットなんかはどうなってるのだろう? とかはデータモデリングの範疇じゃありませんか? とりあえず、上記に載ってる本のどれか買って色々なSample見てみます。 >>52 なんかセット用のフィールドを作った気がする。 詳しいことは忘れた。 UMLでモデリングをして、データベースの構造をER図で書こうとすると、 クラス図とは、全く違ったものになると思うのですが、 UMLとER図の連携?というのは、どうなのでしょうか? まったく別物として考えるのでしょうか? たまに、本で、クラス図を利用して、データベースを、表現したりしているものもあるのですが、 どのような、使い分けをするものなのでしょうか? 安くて、日本語が通って、よい(ER)モデリングツールってないでつか? 以下の2つはよさげなんだけど、日本語のハンドリングにちょっと難点があり。 ■DDS-Lite http://www.chillisource.com/ http://www.dds-lite.com/ 現在正式リリースされているのはライト版のみ。フルセットの Pro バージョンは 開発中。現在、ダウンロード版が特売価格で $79.95 ライトバージョンでも、DFDを扱える。(でもリーバースエンジニアリング機能はない) ER図の日本語表示はなんとかなるが、ダイアログはだめ。 リソースはいろんなところに分散していて直すのが面倒。 また、無理矢理2バイトコードをぶちこむと落ちることがある。(うーむ) ■CaseStudio2 http://www.casestudio.com/ フルセット版で $329 ER、DFD (ライト版は DFD 非対応) ER 図そのものに日本語の表示は可能なものの、ダイアログボックスが全滅 リソースいじろうとしたが、変な実装で、フォント名かえると、起動できない。 DDS-Lite は、エンティティ名に日本語通らない(そんなもんに2バイトコード使うなってか) だけで、日本語のハンドリング問題なかったよ。安いんで、とりあえずレジスト。 使い物になるかな? >>50-53 三足セットを別商品にして\1,000の単価をつけ、 三足セットの内訳「靴下×3」を部品表構造で表現するのは? >>50 在庫と商品を別テーブルにすればいいんじゃないかな? DATARUN 忘れられてる? データの発生源から entity を抽出してゆく方法は、 目からうろこでした。 DATARUN は独自表記だから日本じゃ流行らない。 渡辺幸三著「業務別データベース設計のためのデータモデリング」に継承属性に関する説明があるが、 正規化違反せずに実装する例が示されていません。継承属性を含むモデルを正規化違反せずに実装する 例を示せる人いますか?(もちろん著者は示せるだろうが)教えてください。例えば、p153 図5●将来の日別在庫推移 を管理する、における(商品C)は継承属性を含むモデルとして挙げられます。 >>64 トリガーとか使って関連テーブルから 読み込ませるとか? データモデリングに関しての いいホームページとかないですかねえ? ITアットマークとか見てるのですが モデリングに関してはなかなかないですね。 MSDNのARCHのVISIOを使ってるんだけど、 これ、リバースエンジニアリングしたのをさわった後、 実際にテーブル構造を書き換えるにはどうすればいいのでしょうか? T字型ERで教えていただきたいのですが、 会社で社員が部門に所属しているのを表すとき、 社員(社員コード、氏名) 部門(部門コード、部門名) 所属(社員コード、所属部門コード) のようになるようなんですが、T字型でないERの場合は 社員(社員コード、氏名、所属部門コード) 部門(部門コード、部門名) となると思うのです。 T字型ERでは所属というのを設ける理由はなにでしょうか? >>69 社員が一人が複数の部署に配属される場合以外は あまり必要がないような気がしますね。 >>69 社員と部門の間に依存関係が存在するかどうかの違い。 部門に所属しない社員が許容されるならば、必然的に上の形になる。 所属部門コードにNULLを許して下の形の社員テーブルとする場合は、 概念スキーマ上の社員と所属を結合したものと考える。 あとは>>70 の言う通り、所属の主キーを何にするかによっても 表現するものが変わる。 ありがとうございます。 データの状況や考え方次第ということですね。 >>71 うーん、納得できないなあ。 部門に所属しない社員がいるとしても、社員が最大ひとつの部門にしか 所属できないとしたら、概念レベルでも「所属」は必然的ではないと思うな。 概念レベルでそういうエンティティを設けてそのまま実装したら、 ひとりの社員が複数の部門に所属しないための余計なコードを書かなきゃ いけなくなるからね。 >>73 >概念レベルでそういうエンティティを設けてそのまま実装したら、 >ひとりの社員が複数の部門に所属しないための余計なコードを書かなきゃ >いけなくなるからね。 なんで?制約で表現できると思うのだが。 >>74 「所属」にどんな制約を組み込めば、 複数の部門に所属する社員が登録されるのを 避けれるんだろう。 >>76 社員キーをユニークにするんじゃだめなんか? あれ?T字型では「所属」のユニークキーは 社員コード+所属部門コード になるんではないのかな。 もしユニークキーが社員コードだけだと すると、「所属」ってのは「社員」とキー がいっしょってことになるな。 所属部門コードがNULLではありえないなら 「所属」って意味ないような気がするんだが。 >>77 >もしユニークキーが社員コードだけだと >すると、「所属」ってのは「社員」とキー >がいっしょってことになるな。 >所属部門コードがNULLではありえないなら >「所属」って意味ないような気がするんだが。 「社員」「部門」はエンティティ、「所属」は「社員」と「部門」間の リレーションシップを表現している。 意味がないと思うなら、>>71 の言う通り、論理設計の段階で 結合してしまえば良い。 >>69-78 そのモデルだと所属が変わったときにその事実がどこにも残らないだろ。 モデリング対象の会社に社員の所属変更があるのなら、 配属イベント(配属コード、社員コード、部門コード、配属日)を置く。 そこから所属(=指定日付における所属状態)がすべて再現できる。 >>79 そりゃ要件しだいだな。 履歴が必要ならそういう設計もするだろうが、必要ないなら 徒にトランザクション性能を下げるだけだし。 結局のところ、業務分析した結果にそれが現れるかどうかだろう。 Kさん 好循環 Aさん 悪循環 (健康体) (喘息) 1.(神が喘息であるかないかを決める) 2.K 喘息でない人 A 喘息の人は は体力がある 体力がなくなる 3.K A 行動力、 五感(嗅覚)が鈍り感性が変化する 4.K&A 神は異常な感性の人間は本来人に迷惑をかけ るから外に出てはいけないと思っている。 5.K 変化なし A アトピーになる 6.K 正常な感性 A 外に出なくなりさらに異常な感性になる 7.K 正常な人間 A 異常な人間(レッテル) >>80 は業務分析と設計の区別がついていないのか? 「業務分析」の結果に配属履歴が現れるかどうかは、「業務」によって決まる。 だから「モデリング対象の会社に社員の所属変更があるのなら」と言ってる。 業務は個別アプリケーションの都合で変わりはしないからな。 分析結果に履歴形式が現れた場合に、実際に履歴テーブルとして実装するかどうかは 設計段階で決めることで、トランザクション性能云々はこのときに考えること。 >>69-78 はそういうことを踏まえずに、 配属イベントをすっとばして所属の話だけをしてるから、 それはおかしいっつってんの。 >>82 >「業務分析」の結果に配属履歴が現れるかどうかは、「業務」によって決まる。 これは問題ないが、 >だから「モデリング対象の会社に社員の所属変更があるのなら」と言ってる。 ここがおかしい。所属変更があるということとその履歴が必要というのは 要件としてイコールじゃないから。 だから>>79 が最初に言っている >そのモデルだと所属が変わったときにその事実がどこにも残らないだろ。 これが必要かどうか次第なわけ。 実際、一人の社員が複数の部署に所属し得るという事実を表現するのには >>69 のモデルで十分だし、それは所属変更がありうるとしても変わらない。 >実際、一人の社員が複数の部署に所属し得るという事実を表現するのには >>>69 のモデルで十分だし、それは所属変更がありうるとしても変わらない。 うーん、やっぱり設計と業務分析の区別がついてないね? >>69 のは、テーブル設計(設計の成果物)としては有りだが、 モデル(業務分析の成果物)としてはおかしいんだよ。 ここはモデリングのスレだろ。 >>>69 のは、テーブル設計(設計の成果物)としては有りだが、 >モデル(業務分析の成果物)としてはおかしいんだよ。 おーい、>>69 が業務分析だと言っている香具師がどっかにいたか? もしかして「モデリング」=「業務分析」とか? つか、>>84 にとっては「業務分析」と「テーブル設計」の間って ないのかよ? >ここはモデリングのスレだろ。 そう。データモデリングのな。 >おーい、>>69 が業務分析だと言っている香具師がどっかにいたか? T字ERを>>69 自身が持ち出しているんだから、分析の文脈で捉えるのが自然だろ。 >もしかして「モデリング」=「業務分析」とか? > >つか、>>84 にとっては「業務分析」と「テーブル設計」の間って >ないのかよ? ??? なんでこう話がかみ合わないかな…。 もしかして>>85 はT字ERを知らないんじゃない? なんか、「業務分析」と分析フェーズ全体をごっちゃにしてないか? T字型ERは業務分析だけで使うもんじゃないだろうに。 まぁそれは言葉の問題だとしても、分析フェーズのoutputってのは 要求分析を経てシステム境界等が明確に定義されているべきもの なんで、要件と無関係に>>79 のような断言はできるはずがない。 純粋に業務分析の話ならば、社員の所属変更というごく一般的な プロセスについてなんらかの言及ができてもおかしくはないと思うが、 誰も最初から>>69 がそういう意味での業務分析のことだと思って いないし、>>69 自身そのつもりじゃないだろう。 もともと業務分析じゃないものを「業務分析としておかしい」と言われ ても意味不明だし。 とりあえず>>84 の >>>69 のは、テーブル設計(設計の成果物)としては有りだが、 >モデル(業務分析の成果物)としてはおかしいんだよ。 これだけじゃ何も言っていないのと同じだから、具体的にどう おかしいのか説明してくれないかい? 確かに俺はT字型ERは使ったことがないしよく知らないけど、 業務分析から設計までスムーズに落とし込めるという謳い文句の T字型ERで、逆にそこのところの明確な切り分けをどのように 行うのか興味があるしな。 遅くなってすまん。 >誰も最初から>>69 がそういう意味での業務分析のことだと思って >いないし、>>69 自身そのつもりじゃないだろう。 そうか、>>69 自身が業務分析のつもりが全くないということが、 まだサワリの段階だったら十分ありえるわけだね。了解。 具体的にどうおかしいのかの説明かあ。 困ったな、俺にとっては自明なことなんだよ。T字型ERを算数にたとえると、 「算数では1+1=10になるようなのですが、なぜ10になるのですか?」 という質問のどこが具体的にどうおかしいのか、と聞かれてるような感覚。 でも「1+1は算数では2が答えだから、10になるという仮定は違うよ」という 言い方は算数を知らない人には絶対うまく伝わらないよね? なので、どう説明したらいいものかと。 うまくできるかわからんが、T字型ERの体系をざっくり解説してみようか? 別に、T字型ERマンセー、って主張するわけでもしたいわけでもないけれど、 変な誤解(>>69 のいう「所属」がT字型ERで普通に導かれる、というような)は 解きたいとは思うんだ。 あぁ、道理で話が噛み合わなかったわけだ。 >>79 の「配属イベント」が必要という話じゃなくて、>>69 の「所属」が 余計だという話をしてたわけね。 >なので、どう説明したらいいものかと。 要は「T字型ER」での「業務分析の成果物」にはなんらかの「禁則」が あって、>>69 はそれに反している、ということだろう?それを一言で 指摘してもらえば済む話かと思ったんだが。 というか、具体的に、ってのは >変な誤解(>>69 のいう「所属」がT字型ERで普通に導かれる、というような)は >解きたいとは思うんだ。 というようなことををはっきり書いてもらえばそれでよかったんだが。 >要は「T字型ER」での「業務分析の成果物」にはなんらかの「禁則」が >あって、>>69 はそれに反している、ということだろう? そういうこと。回りくどくてすまん。 T字型ERってのは業務モデリング手法であって、 実装については何ら言及していないと理解してる。 T字型でモデリングした後、実装で 社員コード・名前・部門コード 部門コード・部門名 なんて実装もありだと思われ −−−−−−−−−−−−−−−−−−−−−− T字型マンセーの解説キボン >>91 もう一回ちゃんと本を読め 論理モデルと物理モデルの乖離を否定するのがT字形だぞ >>92 それは幻想と思ってる。もう3回読んだよ(ry プライマリーキーがどれになるかがわからないリソースや イベントの例に悩んでいてこう結論つけた。このまま実装す るなら全テーブルに連番でも振らないと実装出来ない予感。 DWH(データマート)やチューニングの話がミスディレクション になってるんだよきっと。佐藤さんは推理小説好きなんだろう 「論理データベース論考」のP198にこうある ・対照表を実装するのかしないのか、という点を判断する ・サブセットについては、最上位のセットと・・するのかを判断 ・VEについては、派生源のentityに戻して実装するのか・・判断 結局、実装では属人性を排除出来ていないじゃん(w まあそれでT字形の偉大さが毀損されると思わないけど、 本だけでチャレンジした人はきっとSDIにコンサルを依頼 するしかないのかも。毎度あり〜 連番? ビジネスに出てこないアイデンティファイアを導入したらアウトでしょ。 どういうので悩んでいたのか言ってみて? 俺は論理データベース論考は何十回か通読したけど、 SDIやヒューネットのコンサルもセミナーも受けてない。 考え方を身に付けるのが目的だから、 特定のツールを売り込まれたりしたら嫌だし。 確かに、実装の属人性排除はT字形ERの謳い文句には入ってないね。 DBMS側の技術導入で実装には新しい解が出てくるから、普遍化できない。 (例えば今ならサブセットはORDBMSのテーブル継承で実装できるとか。) だから、実装にあまり突っ込まないT字ER手法の態度は真っ当だと思うが、 実装まで全部を体系化して欲しいと思う人には物足りないかもね。 >95 実用書でなく単なる学者のたわごとだと言ってるのかな? 何十回も通読しないとわからないのは実用書ではないからね。 そうか。3回読んだだけで、他人に説法できるほど理解できるのか。 神か仏だな。 まぁ、神や仏は他人を馬鹿にしたりはしないが。 俺は知ってるけど、お前ら馬鹿だなという書き込みほど役に立たないものは無い。 >>97 > まぁ、神や仏は他人を馬鹿にしたりはしないが。 神や仏でもないし他人を馬鹿にした覚えはないが。 今日佐藤さんに聞くと、T字形を大幅に変更したらしいよ。 今年には新書を出すと言われてたので楽しみ。実装につい ても言及して欲しいといっておいたけど、どうなる事やら。 また数十回読むのでしょうか。大変ですね。 >>91 > T字型でモデリングした後、実装で > 社員コード・名前・部門コード > 部門コード・部門名 > なんて実装もありだと思われ ちょっとマジレスすると、サブセットを上位テーブルに実装 するのは「アリ」だが、対照表を上位に実装するのはルール 違反だと思われます。 T字形って、プライマリーキーを意識せず実装するっての が信条のように思ってます。DBによって違うでしょうが、 連番を振ってプライマリーにするのも「アリ」でしょう(多分)。 >>98 > 今日佐藤さんに聞くと、T字形を大幅に変更したらしいよ。 > 今年には新書を出すと言われてたので楽しみ。実装につい > ても言及して欲しいといっておいたけど、どうなる事やら。 へぇ〜。新書が楽しみだ。期待したいな。 渡辺幸三ってひとの本がすごいっておもうんですがどう? ウルトラマンとガンダムどっちが強いかって喧嘩してる子供と同じだな 銀の弾など無いんだし、お前がそれで納得のいく仕事ができればそれでいいじゃないか… >>102 探しているのは銀の弾ではなくガンド・ロア クラスの兵器かと。 DBDesigner使ってる人少ないのか?オープンソースの良ツール なんだが。 http://fabforce.net/dbdesigner4/ メニューとか英語なのは痛いが、一応日本語も(難あり)使えるし、 モデリングには結構いいツールなんで、使ってみてくれ。 Delphi使える人とか、日本語化してくれると尚良いなぁ。 日本語使いたきゃ別のツール使うんじゃない? SIとかさ。 シンプルな商品マスタはこんなのでしょう 〔商品M〕 商品C 販売単価 仕入単価 ~~~~~~ ABC \300 \200 カラー・サイズがないならこれで充分でしょう。 ところがこれで販売管理を作って運用すると 大変な事がわかります。商品数が5000件もある ならまず間違いなく運用出来ません。 −−−−−−−−−−−−− 年1回半分ほども単価変更が発生すると徹夜 作業になってしまうのです。さてどうしましょ? >>106 長年の疑問だが、商品マスタの単価の扱いは、どうするのがベストなのだろう。 COBOLの時代なら、同一レコードに単価項目を2つ(新旧)持ち、適用年月日 で判断するというのが一般的だったけど。 厳密に正規化すれば、単価は、商品マスタとは別に、 商品単価マスタ{商品コード、適用年月日、単価}を作ることになるけど、 この場合、適用年月日の判断が入るため、SQL一発で単価を取得できない。 そこで、ストアド・ファンクション使ったりするのだけど、内部的には結局カーソル 処理を行うことになる。 一方、旧来のCOBOL的なレイアウトだと、OracleならDecode関数で、一発取得 可能となる。他の製品でも、これは、可能だろう。 ただし、単価の履歴は2世代しか管理できない。 要件にもよるだろうけど、この辺、みんなどうしてるのかな。 >この場合、適用年月日の判断が入るため、SQL一発で単価を取得できない。 なんで? >>108 >厳密に正規化すれば、単価は、商品マスタとは別に、 >商品単価マスタ{商品コード、適用年月日、単価}を作ることになるけど、 「単価」を繰返し項目ととらえないなら、正規化違反じゃないよ エンティティをリソースとイベントに分ける考え方からいうと、 全項目に日付を入れるとイベントに近くなってしまう ホストだと、過去データの洗い換えするためにそういう実装 することがあるけど、バッチ処理をなくす方向で考えた方が、 パソコン(鯖)向きだと思う >>109 え、できるの? できるなら、ぜひそのSQLを教えて欲しい。 >>110 >「単価」を繰返し項目ととらえないなら、正規化違反じゃないよ 漏れもそう考えてたんだけど、最近、佐藤正美氏の本を読んで(まだ理解が浅いけど)、 むしろ、商品単価エンティティはeventと考えるべきなのかなという気がしている。 「eventの定義は、「DATE」が帰属するentityである、とする。」だそうだ。 読み違いの可能性も強いが・・・・。 別にT字型ER手法をマンセーするつもりはないけど、佐藤氏の本は色々考えさせられる。 >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.適用年月日 ) >>112 Thanks!!! 確かに、やってみると出来る! でも、理屈が理解できん(泣 Exists、Not Existsを勉強し直そう。 read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる