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

共通の文章

データベース設計に関する次の記述を読んで,設問1こ3に答えよ。 A社は,スポーツイベント(以下,大会という)の運営サービスを主催者に提供し ている大会運営サービス会社である。A社では,大会運営システムを新たに構築する ことになり,B君がデータベース設計を任された。 〔大会の登録から参加申込受付の準備まで】 1.主催者 (1①)大会を主催する団体を主催者という。 ②)主催者は,主催者番号で識別し,主催者名,代表者氏名,住所,電話番号, メールアドレスを登録する。| 2.種目と種目分類 (1)フルマラソン,ハーフマラソン,自転車ロードレースなどを種目という。 (2)種目は,種目コードで識別し,種目分類コードで,ランニング,自転車レー スなどに分類する。 3.大会 大会は,大会番号で識別し,大会名,開催年月日,開催場所の都道府県コード, 主催者番号を登録する。 4.運営サービス (1)A社が主催者に提供するサービスを運営サービスという。運営サービスには, 大会に関する告知サービス,大会への参加申込みを受け付けるエントリサービス, 記録計測サービスなどがある。 (2)運営サービスは,運営サービスコードで識別し,運営サービス名,課金単位, 単価を登録する。 (3)主催者は,大会ごとに一つ以上の運営サービスを選択する。A社は,主催者 が選択した運営サービスを登録する。 5.ZY RUE (1)大会において,SMPBEMCOSMARAS RUIN SBUMELY b UE という。主催者は,大会ごどとに一つ以上のエントリ枠を登録する。エントリ枠は, 大会番号とエントリ枠番号で識別し,エントリ枠名,エントリ枠説明,種目コー ー6一 ド,定員,参加費用,募集期間(募集開始年月日募集終了年月日)などを登録 する。 (2)一つの大会において,幾つかのエントリ枠に同じ種目を登録することがある。 例えば,フルマラソンに対して,一般枠,地元優先枠.アスリート優先枠の三つ のエントリ枠を登録することがある。 (3)エントリ枠に対する参加者を決める方式には,先着順と抽選があり,先着順 抽選区分で分類する。抽選の場合は,抽選年月日を登録する。抽選年月日には, 募集終了年月日よりも後の日付を登録する。 (4)エントリ枠には,エントリ枠状態を保持する。エントリ枠状態の取り得る値 には,参加者を決める方式ごとに,先着順の場合は,"募集前',Beh’,'参 加者確定があり,抽選の場合は,“WR,"募集中',抽選中',“参加者確 定がある。 6.アイテム (1)大会で,参加者に配布する参加賞や.、ナンバカード,ICタグなどをアイテム ND, (2)アイテムは,アイテムコードで識別し,アイテム名を登録する。 (3)主催者は,大会ごとに利用するアイテムを複数登録することができる。 〔大会への参加申込みから参加費用の入金まで 1.会員 1)大会の参加希望者は,あらかじめ会員登録をする。 2)会員は,会員番号で識別し,会員氏名,VER,生年月日,住所,電話番号, メールアドレスを登録する。 2.参加申込み及びエントリ枠状態の設定 (1)会員は,参加したい大会に対して,エントリ枠を指定して参加申込みを行う。 (2)会員は,一つの大会について一つのエントリ枠だけ参加申込みできる。 (3)参加申込みは,大会番号,会員番号で識別し,参加申込年月日を登録する。 (4)参加申込みと同時に,エントリ枠の参加申込数も合わせて更新する。 (5)エントリ枠状態は,次のように設定する。 ①エントリ枠の登録においては,初期値を"募集前"にする。 ーッァー ②募集期間中は"募集中'にする。 ③エントリ枠が先着順の場合 ・募集期間が終わったら"参加者確定にする。 ・参加申込数が定員に達したら,募集期間中であっても参加者確定にする。 ④⑧エントリ枠が抽選の場合 ・募集期間が終わり,参加申込数が定員以下だったら"参加者確定"にする。 ・募集期間が終わり,参加申込数が定員を超えていれば抽選中'にし,その 後,抽選年月日に抽選を実施した上で"参加者確定にする。 (6)エントリ枠状態が'募集中'の間だけ,参加申込みを受け付ける。 3.抽選結果の登録 抽選を実施したら,参加申込みに抽選結果を登録する。 4.参加費用の入金及びポイントの付与 (1)参加が確定したら,会員は参加費用を支払う。 (2)A社は,会員の参加費用の支払を確認して入金年月日を登録し,参加費用に 対して一定割合のポイントを会員に付与する。 (3)会員は,保持しているポイントを,1ポイント1円として,参加費用に充て ることができる。 (4)会員は,ポイントを使用する場合,使用ポイントを登録し,参加費用から使 用ポイントを差し引いた額を支払う。 (概念データモデルと関係スキーマの設計〕 B君が設計した概念データモデルを図1に,関係スキーマを図2に示す。 ーg一 運営_- aA A Sl大会 ザーゼネアイテム 人 抽選 エントリ枠 図1概念データモデル(未完成) 主催者(主催者番号,主催者名代表者氏名,住所,電話番号。メールアドレス) 種目分類(種目分類コード,種目分類名) 種目(種目コード,種目名|。|) 運営サービス(運営サービスコード,運営サービス名,課金単位,単価) アイテム(アイテムコード,アイテム名) 大会(大会番号,大会名,|b ],開催年月日,開催場所都道府県コード) 大会運営サービス(大会番号,運営サービスコード) 大会アイテム(大会番号,アイテムコード) LY h Vit(大会番号。エントリ枠番号,エントリ椿名、エントリ枠説明|c|,定員, 参加費用,参加申込数,先着順抽選区分,募集開始年月日,募集終了年月日,エントリ枠状態 抽選エントリ枠(大会番号,エントリ枠番号,抽選年月日 2A(会員番号,SARS,性別,生年月日住所,電話番号。メールアドレス) 参加申込み(| d|,|=|,エントリ枠番号,参加申込年月日,抽選結果, L_7|.|gz|) 会員ポイント(会員番号,ポイント残高) 図2関係スキーマ(未完成) 〔指摘事項 C部長は,概念データモデル及び関係スキーマに対して,次を指摘した。 ・エントリ枠状態と抽選実施を決める決定表が必要である。 ・この決定表は,日付が変わった時点及び参加申込受付時点で評価する。 ーー9ーー この指摘を受けて作成した,日付が変わった時点及び参加申込受付時点で評価する= 決定表を表1に示す。この決定表の各条件の取り得る値は次のとおりである。 なお,()内に略字がある場合,表1は略字で表す。 先着順抽選区分:先着順,抽選 募集期間に対する本日:募集期間よりも前の日(前),募集期間中(中), 募集期間よりも後の日(後) 参加申込数:定員未満(未満),定員以下(以下),定員到達(到達), 定員超過(超過) 抽選年月日に対する本日:抽選年月日よりも前の日(前),当日, 抽選年月日よりも後の日(後) 表1日付が変わった時点及び参加申込受付時点で評価する決定表(未完成) TET =eepe PEEEPE ET ee oe エントリ枠状態を エントリ枠状態をX ‘phe’にする FEE EEEEERE エントリ枠状態を -[-[e te[-[-}tf p [新たな要件の追加〕 1.多段階抽選方式 例えば,地元優先枠,アスリート優先枠,一般枠の三つの枠があり,会員が地元 優先枠又はアスリート優先枠に参加申込みをして落選したら,その後に抽選を行う 一般枠の抽選対象に加えるというような多段階に抽選するサービスを新たに追加す るととになった。 このサービスを実現するために,多段階抽選方式の仕様を次のように決定した。 ・多段階抽選の対象のエントリ枠には,後続のエントリ枠を一つ設定する。 ・後続のエントリ枠が設定されたエントリ枠で落選した会員は,後続するエントリ 枠の抽選対象に加える。 ・エントリ枠の抽選ごとに抽選結果を登録する。 2.ポイント有効期限 ポイントに有効期限を設けることにした。ポイントの有効期限は,付与された日 から1年であり,有効期限を超過したポイントは消失する。ポイントの使用は, 有効期限の近いものから行う。 解答に当たっては,巻頭の表記ルールに従うこと。ただし,エンティティタイプ間 の対応関係にゼロを含むか否かの表記は必要ない。また,関係スキーマの表記又は関 係スキーマに入れる属性名を答える場合,主キーを表す実線の下線及び外部キーを表 す破線の下線を明記すること。 なお,エンティティタイプ間のリレーションシップには"多対多"のリレーション シップを用いないこと。

共通の文章

データベースでのトリガの実装に関する次の記述を読んで,設問1ー3に答えよ。 オフィスじゅう器メーカのY社は,部品の入出庫,発注を行う在庫管理システム を構築している。 (RDBMSの主な仕様 在庫管理システムに用いているRDBMSの主な仕様は,次のとおりである。 1.ISOLATIONレベル 選択できるトランザクションのISOLATIONレベルとその排他制御の内容は,表 1のとおりである。ただし,データ参照時にFOR UPDATE句を指定すると,対象 行に専有ロックを掛け,トランザクション終了時に解放する。 ロックは行単位で掛ける。共有ロックを掛けている間は,他のトランザクション からの対象行の参照は可能であり,更新は共有ロックの解放待ちとなる。専有ロッ クを掛けている間は,他のトランザクションからの対象行の参照,更新は専有ロッ クの解放待ちとなる。 表1トランザクションの1ISOLATIONレベルとその排他制御の内容 TOA データ参照時に共有ロックを掛け,参照終了時に解放する。 データ参照時に共有ロックを掛け,トランザクション終了時に解放する。 データ更新時に専有ロックを掛け,トランザクション終了時に解放する。 索引を使わずに,表探索で全ての行に順次アクセスする場合,検索条件に合致す るか否かにかかわらず全行をロック対象とする。索引探索の場合,索引から読み込 んだ行だけをロック対象とする。 2.トリガ テーブルに対する変更操作(挿入・更新・削除)を契機に.あらかじめ定義した 処理を実行する。 GQ)実行タイミング(テーブルに対する変更操作の前又は後。前者をBEFOREト UH,後者をAFTERトリガという)を定義むすることができる。 (2)列値による実行条件を定義することができる。 (3)トリガ内では,トリガを実行する契機となった変更操作を行う前と後の行を 参照することができる。挿入では操作後の行の内容を,更新では操作前と操作後 の行の内容を,削除では操作前の行の内容を参照することができる。参照するに は,操作前と操作後の行に対する相関名をそれぞれ定義し,相関名で列名を修飾 する。 (4)BEFOREトリガの処理開始から終了までの同一トランザクション内では,全 てのテーブルに対して変更操作を行うことはできない。 (5)トリガ内で例外を発生させることによって,契機となった変更操作をエラー として終了することができる。 〔在庫管理システムのテーブル〕 在庫管理システムの主なテーブルのテーブル構造は,図1のとおりである。索引 は,主キーだけに定義している。 生産ライン(生産ラインコード,…) 部材メーカ(部材メーカコード,会社名,…) 部品(部品番号,部品名,部品単価,発注先部材メーカコード) 在庫GRABS,実在庫数量,引当済数量,基準在庫数量,補充ロットサイズ,発注済フラグ) 出庫要求(出庫要求番号,出庫年月日,処理状況。生産ラインコード) 出庫要求明細(出庫要求番号,部品番号,出庫要求数量) 出庫(出庫番号,出庫要求番号,部品番号,出庫年月日,出庫数量) 発注(発注番号,発注年月日,MBS,発注数量,処理状況) 入庫(入庫番号,入庫年月日,部品番号,入庫数量) 図1主なテーブルのテーブル構造 [在庫管理業務の概要〕 1)組立工場では,複数の生産ラインが稼働し(,それぞれ異なる製品を組み立てて いる。各製品の組立てに必要な部品は倉庫に保管し,必要に応じて生産ラインに出 庫する。 (2)部品は,部品番号で識別する。倉庫内に存在する在庫を,実在庫と呼ぶ、。この うち,出庫対象となったものを,引当済在庫と呼ぶ。 (3)部品の発注の方式は定量発注である。Y社の定量発注では,部品ごとの実在庫 数量から引当済数量を差し引いた値が,基準在庫数量を下回った都度,部品ごとに 決められた部材メーカに対して,決められた数量(補充ロットサイズ)を発注する。 (4)出庫要求では,倉庫に対して部品の出庫を要求する。“出庫要求"テーブル及び “出庫要求明細”テーブルに出庫要求の内容を登録し,“出庫要求"テーブルの処 理状況に要求発生"を記録する。出庫要求番号は,出庫要求の発生順に一意な連 番である。組立てに必要な複数の部品を一つの出庫要求とし,1トランザクション で処理する。生産ラインごとに様々な組合せの部品を要求する。また,部品の要求 は生産ラインでの組立ての状況に応じて任意の契機で発生する。 (5)在庫引当では,出庫要求に応じて,“出庫要求明細"テーブルに指定した部品番 号の部品について出庫要求数量の出庫が可能かどうか判定し,出庫可能であれば “在庫”テーブルの引当済数量を更新する。全ての部品の在庫引当が完了したら, “出庫要求"テーブルの処理状況を"引当実施'に更新する。 在庫引当できない部品が存在した場合は,在庫引当を破棄して処理状況を引当 失敗に更新し,部品が入庫されるのを待って改めて出庫要求する。 (⑥)出庫では,在庫引当が完了した部品を倉庫から搬出する。毎朝,“出庫要求"テ ーブルの処理状況が引当実施のものを対象に実施する。それぞれの部品の出庫 が完了したら,“在庫”テーブルの実在庫数量及び引当済数量を更新し,“出庫要求" テーブルの処理状況を“出庫実施'に更新する。出庫は出庫要求単位に1トラン ザクションで処理し,全ての部品をまとめて出庫する。 (7)発注では,“発注"テーブルの処理状況に"要求発生”を記録し,“在庫”テー ブルの発注済フラグをオンにする。 (8)入庫では,部材メーカから納品される都度,“在庫”テーブルの実在庫数量を更 ML,発注済フラグをオフにする。また,“発注"”テーブルの処理状況を‘AMR 施′に更新する。納品された複数の部品をまとめて,1トランザクションで処理す る。 〔トリガでの在庫引当処理の設計】 出庫要求に連動した在庫引当を実行させたいので,トリガを利用するように処理を 見直すことにした。トリガでの在庫引当処理を図2に示す。 なお,引当失敗の場合は,出庫要求側でロールバックを行った後,“出庫要求"テ ー14一 ーブルの処理状況を“引当失敗に更新する。 “|ア|"テーブルへの行のに対して,BEFOREトリガとAFTERトリ ガを定義する。 BEFOREトリガでは,“"テーブルに対してした行の, 列の値を検索条件に指定して,“|=|"テーブルから[ォ|, を参照する。出庫要求に指定した出庫要求数量と比較して,引当可能か判定し, 不可能ならば契機となった変更操作を引当失敗のエラーにする。 AFTERトリガでは,“|ェエ]"テーブルの[ヵ]を更新する。 図2トリガでの在庫引当処理(未完成) [トリガでの定量発注の設計〕 在庫引当時の定量発注のために,発注の具体的な処理はストアドプロシージャで用 BL,トリガから呼び出すことにした。ストアドプロシージャでは,“発注"テーブ We“在庫”テーブルに変更操作を行う。トリガを定義するSQLを図3に示す。さ らに,図3の内容のレビューを行った。レビューでの指摘内容と対策を表2に示す。 CREATE TRIGGER TR1] 。|UPDATE OF引当済数量ON在庫 REFERENCING1 b|ROW AS CHKROW [|』](CHKROW.SEZE MEHR-CHKROW.引当済数量<CHKROW.基準在庫数量) BEGIN ATOMIC CALL PARTSORDER(CHKROW.部品番号) END 注記1 CHKROWは,トリガを実行する契機となったテーブルに対する変更操作の行を参照す るために定義する相関名を表す。 注記2 CALL PARTSORDERは,発注を行うストアドプロシージャの呼出しを表す。 図3トリガを定義するSOL(未完成) 表2指摘内容と対策(未完成) 在庫引当以外に,でも|発注が繰り返されないように,トリガ内で “Lon”テーブルの列が|在庫を確認する際に,“|ぃい]"テー 更新され,図3で定義したトリガが発動|ブルの|ぇ列の値も判定に加えるこ し,発注が繰り返されることになる。とにした。

共通の文章

部品表の設計及び処理に関する次の記述を読んで,設問1]こ4に答えよ。 E社は,機械メーカである。E社では,RDBMSに構築した生産部品表(以下,部 品表という)を用いて生産管理を行っている。情報システム部門のFさんは,新た に配属されたDB管理者のために,部品表に関する研修を担当することになった。 (RDBMSの主な仕様] QQ)alld,ユニーク索引と非ユニーク索引に分けられる。 (2)DMLのアクセスパスは,RDBMSによって索引探索又は表探索に決められる。 (3)索引探索に決められるためには,WHERE句のANDだけで結ばれた一以上の 等値比較の述語の対象列が,索引キーの全体又は先頭から連続した一つ以上の列 に一致していなければならない。ON句の場合も同様である。 〔部品表の概要〕 部品表は,E社が製造する製品と製品を構成する部品との関係を表すものである。 Fさんは,研修で使用するためにE社の製品を簡略化して表した製品AX,AY及び AZの構成図を図1に示し,次のように説明することにした。 1.品目 (1)品目は,品番で識別し,品目ごとに在庫をもっている。 (2)品目には,製品と,他の部品を使って組み立てられる中間部品,単独で使わ れる単体部品があり,品目区分で分類する。例えば,図1中のAXは製品,P1 及びP2は中間部品,P3,PA及びP9は単体部品である。 2.製品の構成 (1)製品は,複数種類の部品で構成され,構成図は,階層で表現される。製品か らの階層の深さをレベルという。製品のレベルを0として,階層を一つ下るごと にレベルに1を加算する。例えば,製品AXを構成する部品について,レベル1 に部品Pl,P4及びPO,レベル2に部品P2及びPO,レベル3に部品P3がある。 (2)各部品について,当該部品を使う全ての製品の構成図の中で,当該部品が出 現するレベルの最大値を,最も深い階層を示すことから,ローレベルコード (以下,LLCという)という。例えば,図1では,部品P5のLLCは1,HBR ー17一 P9のLLCは3である。 (3)ある品目が他の品目から構成される場合,当該品目を親品目といい,親品番 で識別する。Ek,当該親品目の一つ下のレベルの品目を子品目といい,子品 番で識別する。 (4)親品目1個当たりに使う各子品目の個数を構成数という。例えば,製品AXの 製造に使う各部品の構成数は,次のとおりである。 ①製品AXは,1個当たり,部品P1を2個,MAPA,P9をそれぞれ1個ずつ 使う。 ②部品P1は,1個当たり,部品P2,P9をそれぞれ1個ずつ使う。 @部品P2は,1個当たり,部品P3を2個使う。 AX AY AZ ‘os coーーー P1(2)P4(1)P9Q①)P5 P9 P3 P7 P9 ae cc Je P2 1)P9(1)P2 P4 =rーー 注記製品AXの各部品の()内の数字は,当該部品の親品目1個当たりに使う当該部 品の構成数を示す。製品AY及びAZの部品については構成数を省略している。 図1製品AX。AY及びAZの構成図(未完成) 3.主なテーブルのテーブル構造 E社が生産管理に用いている主なテーブルのテーブル構造を図2に示す。図1に 基づいて登録した“品目”テーブルの行を表1に,“構成テーブルの行を表2に 示す。 BS,各テーブルには主索引だけが定義されている。索引キーが複合列の場合, テーブル構造に示した列の順番で定義される。 構成(親品番,子品番,構成数,…) 在庫(品番,在庫数,引当可能数,…) 図2主なテーブルのテーブル構造(一部省略) ー18一 表1“品目”テーブルの行(一部省略)表2構成テーブルの行(未完成) |ma|ae|曲目区分|LTOI…|構成数|| |ax|AX|製品|0 fe}|AX|Pl|2|…| LA|4[mm|oo fe}|AX Te |42|az|mm|ol…||AK|mw|l 1 1l… |pm|r|emmm[1[-|||ps|ュ|= re|pe|wna[2[=|[ay|re|ュ| |本|ps|Mame[a[=|[az|ps|a[| wma|2[|[a[D=J|2|— 1 5|5 sD |Pe|Pe a||Pt|me|1| |P|7 a|||本|1|… Le|5 mW WPW呈HL|時|2 1… |po|po|memati|8[||PB|ops||| 注記網掛け部分は表示していない。|Ps|Pe|1|…| |Pe|PM|1|…| |Pe|fw|1 しほしを|ek| しPe|PeW|1|-| 〔部品表に対する基本的な処理] 1.正展開処理,逆展開処理及び所要量計算処理の概要 Fさんは,部品表に対する三つの基本的な処理として,正展開処理,逆展開処理 及び所要量計算処理を挙げた。 Q①)正展開処理は,親品目がどの子品目を使っているかを,階層を上から下に1 階層ずつたどることで調べる。 (2)逆展開処理は,子品目がどの親品目に使われているかを,正展開処理とは逆 に,階層を下から上に1階層ずつたどることで調べる。逆展開処理は,ある部品 が廃番に-なったとき,その部品がどの品目に影響するかを調べるときなどに行 われる。 (3③)所要量計算処理は,製品の生産計画に基づいて,各製品の製造に必要な部品 の所要量を計算し,計算した所要量を部品の引当可能数から差し引くことで, 在庫を引き当てる。 2.正展開処理,逆展開処理及び所要量計算処理に用いるSQL Fさんは,部品表に対する三つの基本的な処理に用いられるSQLの構文の例を, 表3に示した。 表3 SQLの構文の例(未完成) 上段:SQLの目的,下段SQLの構文 正展開処理において,1中の製品AZを構成する部品のうち,レベル2までの部品ご との品番と所要量を調べる。 SELECT PNUM,SUM(QTY)SUMQTY FROM( SELECT子品番PNUM,構成数QTY FROM構成WHERE親品番='AZ’ SQL1|UNION ALL I SELECT L2.子品番PNUM,L2.構成数紀1.構成数QTY FROM構成L1| JOIN構成L2 ON in|』=L2.|p] WHERE L1.親品番=AZ)TEMP GROUP BY PNUM ORDER BY PNUM RIC BVT,レベル2に部品P9を使っている全ての製品の品番を調べる。 SQL2|SELECT L1.親品番FROM構成2 JOIN構成L1 ON if。|=|q| JOIN品目ON L1.親品番=品番 WHERE L2.子品番=PQ’AND LLC=9 HPNUMに指定した品目の一つ下のレベルの全ての部品について,品番,構成数及び品 SQr3目区分を調べる。ここで,当該品目の一つ下のレベルの値を,HLLCに設定する。 SELECT子品番,構成数,品目区分FROM構成JOIN品目ON子品番=品番 WHERE親品番=:HPNUM AND LLC>=:HLLC ORDER BY子品番 HPNUMに指定した部品について,所要量をHQTYに設定し,在庫の引当可能数を更新 SQL4|する。 UPDATE在庫SET引当可能数=引当可能数-:HQTY WHERE品番=:HPNUM 注記HPNUM,HLLC及びHQTYは,ホスト変数である。 [所要量計算処理プログラムの概要〕 所要量計算処理プログラムは,表3中のSQL3及びSQL4を用いる。Fさんは,製 品をN個製造する場合の所要量計算処理プログラムの処理手順を,表4に示した。 なお,当該処理は,次の前提で行うものとする。 (1)各部品の所要量の計算は,SQL3を用いて調べた構成数に基づいて,プログラム のロジックで行う。 (2)ISOLATIONレベルは,READ COMMITTEDとする。 (3)製品が複数ある場合,製品の品番順に,製品ごとに手順ゆびて⑥を繰り返す。 (4)在庫は,適切に管理されているので,引当可能数が負の数になることはない。 表4所要量計算処理プログラムの処理手順 手順①製品の品番を設定したSQL3を用いて,当該製品の一つ下のレベルの全ての部品につい て品番,構成数及び品目区分を調べる。 手順①で調べた全ての部品について,部品ごとに製品をN個製造するために必要な当該 手順②|レベルでの所要量を計算し,その所要量を設定したSQL4を用いて,在庫の引当可能数 を品番順に更新する。 前の手順(手順②又は⑤)で在庫を引き当てた全ての部品について,部品ごとに部品の 手順③|品番を設定したSQL3を用いて,当該部品の一つ下のレベルの部品の品番,構成数及び 品目区分を調べる。 ze@手順③を実行した結果,一つでも部品が存在すれば手順⑤に進み,なければ手順⑥に進 む。 手順③で調べた全ての部品について,部品ごとに製品をN個製造するために必要な当該 手順⑤⑥|レベルでの所要量を計算し,その所要量を設定したSQL4を用いて,製品ごとレベルご と部品ごとに,在庫の引当可能数を品番順に更新し,手順③に戻る。 手順⑥|COMMIT文を発行し,他に処理すべき製品があれば手順①に戻り,なければ終了する。 (Fさんの研修内容に対する部長の指示] 表4について,人KK部長から次のような指示があった。 指示1表4中の手順③のSQL3の発行回数を減らすために,手順〇及び③の SQL3で部品の品目区分を調べている。その理由を説明すること。 指示2品目の設計変更において,例えば,製品AXの部品P3を新部品P11に 置き換えるべきところ,誤って部品P1を“構成'テーブルに登録して しまった場合,SQL3の構文中に下線部分の述語が指定されていなけれ ば,プログラムは不具合を起こすことを説明すること。 指示3製品は多品種なので,スループット向上のために所要量計算を製品ごと に分割して並行処理している。しかし,表4の処理手順のままではデッ ドロックが起きるので,プログラムを改良したことを説明すること。