データベーススペシャリスト 2021年 秋期 午後I 問題

共通の文章

データベース設計に関する次の記述を読んで,設問1ー3に答えよ。 B社は,複数の加盟企業向けに共通ポイントサービスを運営している。今回,その 基盤のシステム(以下,ポイントシステムという)を再構築することになり,デー タベース設計を開始した。 [ポイントシステムの概要] 1.会員 |会員は,B社が発行したポイントカードの利用者であり,会員コードで識別する。 2.加盟企業 (1)加盟企業は,B社と共通ポイントサービス加盟の契約をした企業であり,加盟 企業コードで識別する。コンビニエンスストア,レストランチェーンなだど様々 な業種の企業がある。同じ加盟企業と複数回の契約をすることはない。 (2)加盟企業は複数の店舗をもつ。店舗は,加盟企業コードと店舗コードで識別 する。 3.加盟企業商品と横断分析用商品情報 (1)加盟企業商品 ①加盟企業が販売する商品を,B社から見て加盟企業商品と呼ぶ。 @加盟企業は,商品をポイントシステムに登録するときに,当該加盟企業の 商品コード(以下,加盟企業商品コードという),商品名(以下,加盟企業商 品名という),JANコードを登録する。加盟企業商品は,加盟企業コードと加 盟企業商品コードで識別する。 ③加盟企業商品コードは再利用されないが,加盟企業商品名とJANコードは 再利用されることがある。また,JANコードが設定されない商品もある。 (2)横断分析用商品情報 ①横断分析用商品情報は,複数の加盟企業が同じ商品を扱つている場合に同 一商品であると認識できるようにするものである。横断分析用商品情報には, 横断分析用商品コードと横断分析用商品名を設定し,横断分析用商品コード で識別する。横断分析用商品名は一意になるとは限らない。 ②B社は,加盟企業商品が追加される都度,既に同じ商品の横断分析用商品が ーァー 登録済みかどうかを確認し,登録済みと判断すればその横断分析用商品コー ドを,登録済みでないと判断すれば新たな横断分析用商品コードを加盟企業 商品に設定する。 ③横断分析用商品コードの設定には,加盟企業商品の登録から数日を要する 場合がある。 〔ポイントの概要)〕 1.ポイント ポイントは,加盟企業の販促のために会員に与える点数である。 2.ポイントの利用 (1)会員は,自分のポイント残高を上限として,購入金額の一部又は全てをポイ ントで支払うことができる。利用したポイント(以下,利用ポイントという) は,支払時にポイント残高から減算する。 (2)ポイントは,全ての加盟企業の店舗で利用できる。 (3)利用ポイントを支払ごとに記録する。1回の支払はレシート番号で識別する。 3.ポイントの付与 1)会員がポイントカードを提示して支払をすると,その支払で付与するポイン トを記録する。ポイントカードの提示がなければこの記録を作成しない。 Q)付与ポイントを記録した時点では,付与ポイントの記録は会員のポイント残 高に加算しない。ポイント残高への加算は後述の日次バッチで行う。 (3)ポイントには,商品ごとの購入金額に対して付与するものと,支払方法ごと の支払金額に対して付与するものがある。 ①購入商品ごとの付与ポイント ・商品の購入金額(購入数X商品単価)にポイント付与率を乗じて計算する。 ・ポイント付与率は,通常は全加盟企業共通で決められている基準ポイント 付与率を適用するが,後述のクーポンの利用によって変わることがある。 ②支払方法ごとの付与ポイント ・支払においては,現金,ポイント利用,電子マネー利用など,1回の支払で 複数の支払方法を併用できる。 ・支払方法ごとの付与ポイントは,各支払方法での支払金額に:,ポイント付 = 与率を乗じて計算する。 ・各支払方法に対するポイント付与率は,ポイント設定で決めている。ポイ ント設定はポイント設定コードで識別し,ポイント付与率,適用期間をも つ。ポイントを付与する支払方法にポイント設定を対応付ける。同じポイ ント設定を,複数の支払方法に対応付けることがある。 (4)付与ポイントは,小数第3位まで記録する。 (65)会員がポイントで支払った分にもポイントを付与する。 4.付与ポイントのポイント残高への加算 (1)毎日午前0時を過ぎると,支払ごとの付与ポイントの記録から,支払日時が前 日の分を日次バッチで抽出し,集計して会員のポイント残高に加算する。 (2)購入商品ごとの付与ポイントと支払方法ごとの付与ポイントを加算し,小数 点以下を切り捨てたものが支払全体の付与ポイントとなる。 5.ポイントの後付け GQ)会員がポイントカードを忘れた場合,会員が申告すると店員は支払時のレシ ートに押印する。会員がこのレシートを1か月以内にこの店舗に持って行き,ポ イントカードを提示すると,その支払で付与するポイントを記録する。 (2)付与ポイントの記録は,レシートが発行された日時の記録となる。 [クーポンの概要〕 1グーポン (1)B社は,クーポンという販促手段を用意している。加盟企業は,自社の店舗に 会員を呼び込むために,クーポンを企画する。 (2)クーポンは,会員に配布する紙片である。会員が支払時にクーポンを提示す ると,クーポンに設定されたポイント付与率を適用する。店舗は,提示された クーポンを回収する。 (3)クーポンの企画単位にクーポンコードを付与する。 (4)クーポンは,企画した加盟企業の店舗だけで利用できる。 (5)クーポンには,利用期間を設定している。 (6)設定できるクーポンには,適用対象となる店舗を限定したクーポン,AW 象となる商品を限定したクーポン,及び,店舗も商品も限定しないクーポンが =§= ある。ただし,商品の購入数を限定したクーポンは設定できない。 (7)会員は,クーポンコードが異なる複数のクーポンを1回の支払で利用できる。 (8)クーポンの効果を測るために,クーポンがどの支払で利用されたか分かるよ うに記録する。 2.クーポンの配布方法 (1)クーポンを企画した加盟企業は,B社に料金を支払い,クーポンの配布対象に したい会員の抽出条件をB社に伝える。 (2)会員の抽出は,支払時のポイント付与の記録を用いて行う。抽出条件には, ある期間に特定の店舗を利用した,特定の商品を一定以上の金額分購入した, 特定の支払方法で一定以上の金額を支払っつた,などがある。 (3)B社は,条件に合う会員を抽出し,クーポン配布リストとして登録する。会員 の抽出は,日次バッチで行う。 (4)クーポン配布リストに登録されている会員が,全加盟企業のいずれかの店舗 を利用した場合に,クーポンを発行する。同じ会員に同じクーポンを2回発行す ることはない。 (5)クーポンには,配布上限数と配布期間を設定している。 [概念データモデルと関係スキーマの設計〕 概念データモデルを図1に,関係スキーマを図2に示す。 図1概念データモデル(未完成) 店舗(加盟企業コード,店舗コード,店舗名,所在地) 会員(会員コード,会員名,入会日,住所,性別,生年月日,ポイント残高) 加盟企業商品(加盟企業コード,加盟企業商品コード,JANコード,加盟企業名,契約開始日 契約終了日,加盟企業商品名,横断分析用商品コード,横断分析用商品名) 支払(レシート番号,会員コード,|。|,|b ],支払日時,利用ポイント) 支払方法明細(レシート番号,支払方法コード,|c|,付与ポイント) 購入商品明細(レシート番号,加盟企業コード,加盟企業商品コード,|q|,商品単価 付与ポイント) 支払方法(支払方法コード,支払方法名,|。|) ポイント設定(ポイント設定コード,適用開始日,適用終了日,|f|) クーポン設定(クーポンコード,クーポン名,企画加盟企業コード,配布開始日, 配布終了日,利用開始日,利用終了日,ポイント付与率,|gz|) クーポン設定対象店舗(ターポンコード,加盟企業コード,店舗コード) クーポン設定対象商品(クーポンコード,加盟企業コード,加盟企業商品コード) クーポン配布(|h|,|ij|,配布済フラグ,配布日時) クーポン利用(|_j|,|k|) 図2関係スキーマ(未完成) 解答に当たっては,巻頭の表記ルールに従うこと。ただし,エンティティタイプ間 の対応関係にゼロを含むか否かの表記は必要ない。 なお,エンティティタイプ間のリレーションシップとして“SHS”のリレーショ ンシップを用いないこと。エンティティタイプ名及び属性名は,それぞれ意味を識別 できる適切な名称とすること。

共通の文章

データベースの実装に関する次の記述を読んで,設問1ー3に答えよ。 クレジットカード会社のC社では,キャッシュレス決済の普及に伴いカード決済シ ステムのオンライントランザクションの処理量が増えている。情報システム部のFさ んは,将来の処理量から懸念される性能低下の対策を検討することになつた。 [RDBMSの主な仕様] 1.アクセス経路,区分化,再編成 (1)アクセス経路は,RDBMSによって表探索又は索引探索に決められる。表探索 Clk,索引を使わずに先頭ページから順に全行を探索する。索引探索では, WHERE名中の述語に適した索引によって絞り込んでから表の行を読み込む。 (2)テーブルごとに一つ又は複数の列を区分キーとし,区分キーの値に基づいて 物理的な表領域に分割することを区分化という。 (3)区分方法にはハッシュとレンジの二つがある。どちらも,テーブルを検索す るSQL XM WHERE名の述語に区分キー列を指定すると,区分キー列で特定し た区分だけを探索する。 ①ハッシュは,区分キー値を基にRDBMSが生成するハッシュ値によって一定 数の区分に行を分配する方法である。 ②レンジは,区分キー値の範囲によって区分に行を分配する方法である。 (4)テーブル又は区分を再編成することによって,行を主キー順に物理的に並び 替えることができる。また,各ページ中に指定した空き領域を予約することが できる。 (5)INSERT文で行を挿入するとき,RDBMSは,主キー値の並びの中で,HAT の主キー値に近い行が格納されているページに空き領域があればそのページに, なければ表領域の最後のページに格納する。最後のページに空き領域がなけれ ば,新しいページを表領域の最後に追加する。 2.データ入出力とログ出力 (1)データとログはそれぞれ別のディスクに格納される。同じディスクに対し同 時に入出力は行われないものとする。 (2)データ入出力とログ出力は4000バイトのページ上単位に行われる。 =b= (3)データバッファはテーブルごとに確保される。 (4)ページをランダムに入出力する場合,SQL処理中のCPU処理と入出力処理は 並行して行われない。これを同期データ入出力処理と呼び,SQL処理時間は次 の式で近似できる。|. SQL処理時間=CPU時間+同期データ入出力処理時間 (5)ページを順次に入出力する場合,SQL処理中のCPU処理と入出力処理は並行 して行われる。これを非同期データ入出力処理と呼び,SQL処理時間は次の式 で近似できる。ここで関数MAXは引数のうち最も大きい値を返す。 SQL処理時間=MAX(CPU時間,非同期データ入出力処理時間) (6)行を挿入,更新,削除した場合,変更内容がログとしてRDBMSに一つ存在す るログバッファに書き込まれる。ログバッファが一杯の場合,トランザクショ ンのINSERT文,UPDATE文,DELETE文の処理は待たされる。 (7)ログは,データより先にログバッファからディスクに出力される。これをロ グ出力処理と呼ぶ、。このとき,トランザクションのコミットはログ出力処理の 完了まで待たされる。ログ出力処理は,次のいずれかの事象を契機に行われる。 ①ログバッファが一杯になった。 @トランザクションがコミット又はロールバックを行った。 @あるテーブルのデータバッファが変更ページによって一杯になった。 [カード決済システムの概要〕 Lorn ele 主なテーブルのテーブル構造を図1,将来の容量見積りを表1に示す。各テーブ ルの主キーには索引が定義されており,索引キーを構成する列の順はテーブルの 列の順と同じである。 オーソリ履歴(カード番号,利用日,オーソリ連番,加盟店番号,利用金額, 審査結果,請求済フラグ,請求日,…) 図1主なテーブルのテーブル構造(一部省略) ー15一 表1主なテーブルの将来の容量見積り 2.オーソリ処理(オンライン処理) オーソリ処理は,会員がカードで支払う際にカード有効期限,与信限度額を超 過していないかなどを判定する処理である。判定した結果,可ならば審査結果を ‘YY i,否ならば"N'に設定した行を“オーソリ履歴"テーブルに挿入する。 オーソリ処理は最大100多重で処理される。“オーソリ履歴"テーブルには直近5 年分を保持する。 3.利用明細抽出処理(バッチ処理) 請求書作成に必要な1か月分の利用明細の記録を“オーソリ履歴"テーブルから 抽出しファイルに出力する。 [参照処理の性能見積り] 将来の処理時間が懸念される利用明細抽出処理のSQL文を,図2に示す。 FROMオーソリ履歴A,加盟店B WHERE A.審査結果='Y'AND A.利用日BETWEEN:hv1 AND:hv2 AND A.加盟店番号=B.加盟店番号 注記ホスト変数hv1,hv2は,請求対象月の初日と末日をそれぞれ表す。 図2利用明細抽出処理のSQL文 Fさんは,利用明細抽出処理の処理時間を,次のように見積もった。 1.このSQL文での表の結合方法を調べたところ,“オーソリ履歴"テーブルを外側, “加盟店”テーブルを内側とする入れ子ループ法だった。“オーソリ履歴"テーブ ルのアクセス経路は表探索だったので,| 。|ページを非同期に読み込む。 2.ディスク転送速度を100Mバイトノ秒と仮定すれば,|』|ページを非同 期に読み込むデータ入出力処理時間は,|b|秒である。 ー16一 3.カード数を1,000万枚,カード・月当たり平均オーソリ回数を80回,審査結果 が全て可であると仮定すると,“オーソリ履歴"テーブルの結果行数は, | 。 ]行である。これに掛かるCPU時間は,96,000 CHS. 4.この結合では,外側の表の結果行ごとに“加盟店”テーブルの主キー索引を索 引探索し,“加盟店”テーブルを1行,ランダムに合計|q|回読み込む。 5.索引はバッファヒット率100%,テーブルはバッファヒット率0%と仮定すれば, "加盟店”テーブルを合計で| e|ページを同期的に読み込むことになる。 同期読込みにページ当たり1ミリ秒掛かると仮定すれば,同期データ入出力処理時 間は|f|秒でぁる。 6.内側の表の索引探索と結合に掛かるCPU時間は,1結果行当たり0.01ミリ秒持 かると仮定すれば,|gz|秒でぁる。 7.外側の表のCPU時間は96,000秒,内側の表のCPU時間は|g|秒,内側 の表の同期データ入出力処理時間は|f|秒なので,SQL文の処理時間を |』|秒と見積もった。 処理時間が長くなることが分かったので時間短縮のため,次の2案を検討した。 1“加盟店”テーブルのデータバッファを増やしバッファヒット率100%にする。 案2“オーソリ履歴"テーブルの利用日列をキーとする副次索引を追加する。 (“オーソリ履歴"テーブルの区分化 Fさんは,上司であるG氏から,次の課題の解決策の検討を依頼された。 課題1月末近くに起きるオーソリ処理のINSERT文の性能低下を改善すること 課題2将来懸念される利用明細抽出処理の処理時間を短縮すること 課題3月初に行う“オーソリ履歴"テーブル再編成の処理時間を短縮すること Fさんは,課題を解決するために,“オーソリ履歴"テーブルを区分化することに し,区分キーについて表2に示す3案を評価した。いずれの案も60区分に行を均等 に分配する前提であり,図2のSQL文を基に区分化に対応したSQL文を作成した。 作成したSQL文のWHERE句を図3に示す。利用明細抽出処理及び再編成について, アクセスする総ページ数が最小になるようにジョブを設計した。このときジョブは 必要に応じて並列実行させる。 表2課題ごとに各案を評価した結果(未完成) ATE 利用日(1か月を1区 Wai:0 iF:© 評価:x評価:O評価:〇 課題2|ジョブ当たり60区分,|ジョブ当たり[|区分,|ジョブ当たり区分, 24億ページを探索|[_|ページを探索|ロページを探索 評価:〇評価:O評価:O 注記1〇:課題を解決する。X:課題を解決しない。 注記2網掛け部分は表示していない。 WHERE A.審査結果='"Y AND A.利用日BETWEEN:hv1 AND:hv2 AND A.カード番号BETWEEN:hv3 AND:hv4 AND A.加盟店番号=B.加盟店番号 注記1ホスト変数hv1,hv2は,請求対象月の初日と未日をそれぞれ表す。 注記2ホスト変数hv3,hv4は,カード番号の範囲(レンジ)の始まりと終わりをそれぞれ表す。 図3区分化に対応したSQL文のWHERE 4) [更新処理の多重化〕 “オーソリ履歴"テーブルの請求済フラグと請求日を更新する処理も同様に,将 来の処理時間が懸念された。更新処理のSQL文を図4に示す。更新処理はバッチ処 理であり,カーソルを使用して1.000行を更新するごとにコミットする。 UPDATEオーソリ履歴SET請求済フラグ='Y,請求日=:hv1 WHERE利用日BETWEEN:hv2 AND:hv3 ANDカード番号BETWEEN:hv4 AND:hv5 注記1ホスト変数hv1は,請求日を表す。 注記2ホスト変数hy2,hv3 lt,請求対象月の初日と末日をそれぞれ表す。 注記3ホスト変数hy4,hv5は,カード番号の範囲(レンジ)の始まりと終わりをそれぞれ表す。 図4更新処理のSQL文 Fさんは,次のように,区分化と併せて,更新処理を多重化することにした。 1.“オーソリ履歴"テーブルについて,カード番号,利用日の順の組で区分キー とし,レンジによって区分化する。 2.区分ごとのジョブで更新処理を多重化する。 3.更新処理を多重化しても競合しないように,各区分を異なるディスクに配置し, データバッファを十分に確保する。

共通の文章

テーブルの移行及びSQLの設計に関する次の記述を読んで,設問1,2に答えよ。 A社は,不動産賃貸仲介業を全国規模で行っている。RDBMSを用いて物件情報検 索システム(以下,検索システムという)を運用している運用部門のKさんは,物 件情報を検索するSQL文を設計している。 (REY AT LOE) 検索システムは,物件を管理するシステムを補完するシステムであり,社内利用 者が接客するとき,当該システムの"物件"テーブルを利用している。 1.社内利用者の接客業務の概要 (1)物件を探している借主に対して,当該借主の希望に近い物件を探す支援を行 い,借主と貸主との間の交渉・賃貸契約の仲介を行う。 (2)物件の貸主に対して,物件の審査を行う。当該貸主に長期の空き物件がある 場合,周辺の競合物件の付帯設備(以下,設備という)の設置状況を調査し, 当該空き物件に人気の設備を増強することなど,物件の付加価値を高める対策 の助言を行うこともある。 2.“物件”テーブル 1)A社が仲介する全ての物件を,物件コードで一意に識別する。 (2)物件の沿線,最寄駅,賃料,間取りなどの基本属性を記録する列がある。 (3)エアコン,オートロックなどの設備が設置されているかどうかの有無を記録 する列があり,一つの物件に最大20個の設備の有無を記録できる。 (4)記録されている20個の設備について,どの設備もいずれかの物件に設置され ているが,20個全ての設備が設置されている物件は限られている。 (5)設備に流行があるので,テーブルの定義を変更し,記録する人気の設備を毎 年入れ替える処理を行っている。この処理を物件設備の入替処理と呼んでいる。 (6)"物件"”テーブルの全ての列にNOT NULL制約を指定している。 3.“物件”テーブルのテーブル構造,主な列の意味と制約及び主な統計情報 “物件”テーブルのテーブル構造を図1に,主な列の意味・制約を表1に, RDBMSの機能を用いて取得した主な統計情報を表2に示す。 ー20一 物件(物件コード,物件名,沿線,最寄駅,賃料,間取り,向き,専有面積,筑年数, 都道府県,市区町村,エアコン,オートロック,…,物件登録日) 図1“物件'テーブルのテーブル構造(一部省略) 表1“物件"テーブルの主な列の意味・制約(一部省略) ok inte—MAT 3 物件から利用可能な沿線のうち代表的な沿線の名前 物件から利用可能な駅のうち代表的な駅の名前 tek、。|当該設備が設置されているかどうかの有無を示す値 表2"物件"テーブルの主な統計情報 物作コード dt 1,600,000 4.検索システムの課題 Kさんは,社内利用者に聞取り調査を行い.その結果を二つの課題にまとめた。 ①)“te”テーブルの各設備の有無を示す列(以下,総称して設備列という) の数は不十分で,借主からの問合せに十分に対応できていない。追加したい設 だ 備は,テレワーク対応,宅配ボックス,追い尊き風呂などがあり,現在の20個 を含め,全部で100個ある。将来,増える可能性がある。 (2)設備の設置済個数が分からない。例えば,借主から物件に設置されているエ アコンについて問合せがあったとき,設置されている正確な個数が分からず, 別の詳細な物件設備台帳を調べなければならない。 (物件の設備に関する調査及び課題への対応 1.物件の設備に関する調査 Kさんは,現在検索できる設備の組合せを述語に指定したSQL文を調査した。 そのSQL文の例を,表3に示す。そしてKさんは,SQL文の結果行を保存するフ ァイルの所要量を見積もる目的で,表3の各SQL文の結果行数を見積もった。 表3設備の組合せを述語に指定したSQL文の例(未完成) SQL文の構文上段:目的,下段:構文見積もった結果行数 沿線が〇人人線であり,DO,設備にエアコンとオートロックの両方 einがある物件を調べる。 SELECT物件コード,物件名FROM物件WHERE沿線='〇ム線" AND(エアコン=’Y ANオートロック='Y’) 沿線が〇AA線であり,かつ,設備にエアコン又はオートロックのい SQL2 ずれかがある物件を調べる。 SELECT物件コード,物件名FROM物件WHERE沿線='〇A線Ld 4 AND(エアコン=’Y ORA—-kOwy=’Y) 設備にエアコンとオートロックの両方がある物件を沿線ごとに集計 した物件数が,全物件数に占める割合を百分率(小数点以下切捨 て)で求める。 sai WITH TEMP(TOTAL)AS(SELECT COUNT(*)FROM物件)400 |SELECT沿線,FLOOR(*100/|=|) FROM物件CROSS JOIN TEMP WHEREエアコン=’Y ADオートロック=’Y GROUP BY 注記FLOOR関数は,引数以下の最大の整数を計算する。 2.物件の設備に関する課題への対応 Kさんは,物件の設備に関する課題に対応するため,次の2案について長所及び 短所を比較した結果,案Bを採用することにした。 ZA物件"テーブルにエアコン人台数列を追加する。 案B追加・変更するテーブルのテーブル構造を,図2に示すとおりにする。 ・“設備"”テーブルを追加する。 ・図1に示した"物件”テーブルを“新物件"”テーブルに置き換える。 ・“物件設備"”テーブルを追加する。 設備(設備コード,設備名) 新物件(物件コード,物件名,沿線,最寄駅,賃料間取り,向き,専有面積築年数, 都道府県,市区町村,物件登録日) 物件設備(物件コード,設備コード,設置済個数) 2追加・変更するテーブルのテーブル構造 設備コードは,全設備を一意に識別するコードで,そのうち20個は,"物件"+ ーブルの各設備列に対応させた。また,“設備”テーブルの設備名の列値に"物件" テーブルの設備列名をそのまま設定し,今後追加される設備名を含めて重複させ ないことに決めた。 3.テーブルの移行 Kさんは,追加・変更するテーブルへの移行を,次のような手順で行った。 ①)“設備",“新物件"及び“物件設備"”テーブルを定義した。 (2)"物件"テーブルから設備列20個を除いた全行を,“新物件"テーブルに複写 Xs (3)“設備テーブルに100個の設備を登録した。エアコン又はオートロックを登 録するSQL文の例を,表4のSQL4に示す。 (4)“物件設備"テーブルには“物件"”テーブルにある設備に限って行を登録し た。エアコン又はオートロックがある行を登録するSQL文の例を,表4のSQL5 に示す。ここで,設置済個数列に1を設定し,正確な個数を移行後に設定するこ どとにした。 (5)テーブルの統計情報を取得した。主な統計情報を表5に示す。 表4設備テーブル又は“物件設備"”テーブルに登録するSQL文の例(未完成) SQL文の構文 INSERT INTO設備VALUES('A1','エアコン') SQL4[INSERT INTO設備VALUES('A2オートロック”) INSERT INTO物件設備(物件コード,設備コード,設置済個数) SQL5 SELECT|。]FROM物件WHERE[5 SELECT[as|FROM物件WHERE[ie| 表5追加・変更したテーブルの主な統計情報(未完成) 人人 wine|rgmngnn|人コード 物件設備ー 注記網掛け部分は表示していない。 [テーブルの移行の検証] Kさんは,テーブルの移行を次のように検証し,新たなビューを定義した。 1.SQL文の検証 テーブルの移行の前後でSQL文が同じ結果行を得るか検証するため,移行前の SQL X(表3のSQL1,SQL2)に対応する移行後のSQL文を,それぞれ表6の SQL6,SQL7のとおりに設計した。そして,“1.物件の設備に関する調査"で保存 したファイルを用いて,SQL1とSQL6の結果行,SQL2とSQL7の結果行がそれぞ れ一致することを確認した。 表6移行後のSQL MOM(未完成) SQL KOH SELECT B.物件コード,B.物件名 FROM新物件B 物件設備BS1 ON B.物件コード=BS1.物件コードAND B.沿線=’OAR SQL6|| 。|設備SI ON BS1.設備コード=S1.設備コードAND 物件設備BS2 ON B.物件コード=BS2.物件コード 設備S2 ON BS2.設備コード=S2.設備コードAND|ij| SELECT DISTINCT B.物件コード,B.物件名 FROM新物件B SQL7物件設備BS ONB.物件コード=BS.物件コードAND B.沿線="OAR |g|設備$ON BS.設備コード=$.設備コードAND|」| 2.ビューの定義 Kさんは,"物件"”テーブルの定義を削除した後でも実績のあるSQL文を変更す ることなく使いたいと考えている。そのために“IE”テーブルにあった沿線列, かつ,エアコン列とオートロック列の両方を表示するビュー物件”を,図3のと おりに定義した。 SELECT B.物件コード,B.沿線, CASE WHEN THEN ELSE END ASエアコン, CASE WHEN[|THEN ELSE END ASオートロック FROM新物件B ーー物件設備BS2 ON B.物件コード=BS2.物件コードAND| 物件設備BS1 ON B.物件コード=BS1.物件コードAND|o| 注記網掛け部分は表示していない。 図3ビュー“物件”の定義(未完成)