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

共通の文章

次の記述を読んで,設問に答えよ。 基板上に電子部品を実装した電子機器の製造受託会社であるA社は,自動車や家電 などの製品開発を行う得意先から電子機器の試作品の製造を受託し,電子部品の調 達と試作品の製造を行う。今回,調達システムの概念データモデル及び関係スキー マを再設計した。 ?[現行業務)】 1.組織 (1)組織は,組織コードで識別し,組織名をもつ。組織名は重複しない。 (2)組織は,階層構造であり,いずれかーーつの上位組織に属する。 2.役職 役職は,役職コードで識別し,役職名をもつ。役職名は重複しない。 3.社員 (1)社員は,社員コードで識別し,氏名をもつ。同姓同名の社員は存在し得る。 (2)社員は,いずれかの組織に所属し,複数の組織に所属し得る。 (3)一部の社員は,各組織において役職に就く。同一組織で複数の役職には就か ない。 (4)社員には,所属組織ごとに,業務内容の報告先となる社員が高々1名決まっ ている。 4.得意先と仕入先 (1)製造受託の依頼元を得意先,電子部品の調達先を仕入先と呼ぶ。 (2)得意先と仕入先とを併せて取引先と呼ぶ。取引先は,取引先コードを用いて 識別し,取引先名と住所をもつ。 (3)取引先が,得意先と仕入先のどちらに該当するかは,取引先区分で分類して いる。得意先と仕入先の両方に該当する取引先は存在しない。 (4)仕入先は,電子部品を扱う商社である。A社は,仕入先と調達条件(単価, ロットサイズ,納入可能年月日)を交渉して調達する。仕入先ごとに昨年度調 達金額をもつ。 ーァー (5)得意先は,昨年度受注金額をもつ。 5.品目 (1)試作品を構成する電子部品を品目と呼び,電子部品メーカー(UF,メーカ ーという)が製造している。 ①品目は,メーカーが付与するメーカー型式番号で識別する。メーカー弄式 番号は,メーカー間で重複しない。 ②メーカー各社が発行する電子部品カタログでメーカー型式番号を調べると, 電子部品の仕様や電気的特性は記載されているが,単価やロットサイズは記 載されていない。 (2)品目は,メーカーが付けたブランドのいずれかーつに属する。 ①ブランドは,ブランドコードで識別し,ブランド名をもつ。 ②仕入先は,幾つものブランドを扱っており,同じブランドを異なる仕入先 から調達することができる。仕入先ごとに,どのブランドを取り扱っている かを登録している。 (3)品目は,品目のグループである品目分類のいずれかーつに属する。品目分類 は,品目分類コードで識別し,品目分類名をもつ。 6.試作案件登録 (1)得意先にとって試作とは,量産前の設計検証,機能比較を目的に,製品用途 ごとに,性能や機能が異なる複数のモデルを準備することをいう。得意先から モデルごとの設計図面,品目構成,及び製造台数の提示を受け,試作案件とし て次を登録する。 DQ試作案件 ・試作案件は,試作案件番号で識別し,試作案件名,得意先,製品用途,at 作案件登録年月日をもつ。 @モデル ・モデルごとに,モデル名,設計図面番号,製造台数,得意先希望納入年月 日をもつ。モデルは,試作案件番号とモデル名で識別する。 @モデル構成品目 ・モデルで使用する品目ごとに,モデル1台当たりの所要数量をもつ。 ④試作案件品目 ー8一 ・試作案件で使用する品目ごとの合計所要数量をもつ。 ・通常,品目の調達はA社が行うが,得意先から無償で支給されることがある。 この数量を得意先支給数量としてもつ。 ・合計所要数量から得意先支給数量を減じた必要調達数量をもつ。 7.見積依頼から見積回答入手まで (1)品目を調達する際は,当該品目のブランドを扱う複数の仕入先に見積依頼を TT On ①見積依頼には,見積依頼番号を付与し,見積依頼年月日を記録する。また, どの試作案件に対する見積依頼かが分かるようにしておく。 ②仕入先に対しては,見積依頼がどの得意先の試作案件によるのか明かすこ とはできないが,得意先が不適切な品目を選定していた場合に,仕入先から の助言を得るために,製品用途を提示する。 ③品目ごとに見積依頼明細番号を付与し,必要調達数量,希望納入年月日を 提示する。 ④仕入先に対して,見積回答時には対応する見積依頼番号,見積依頼明細番 号の記載を依頼する。 (2)仕入先から見積回答を入手する。見積回答が複数に分かれることはない。 ①入手した見積回答には,見積依頼番号,見積有効期限,見積回答年月日, 仕入先が付与した見積回答番号が記載されている。見積回答番号は,仕入先 間で重複し得る。 ②見積回答の明細には,見積依頼明細番号,.メーカー型式番号,調達条件, 仕入先が付与した見積回答明細番号が記載されている。回答されない品目も ある。見積回答明細番号は,仕入先間で重複し得る。 ③見積回答の明細には,見積依頼とは別の複数の品目が提案として返ってく ることがある。その場合,その品目の提案理由が記載されている。 ④見積回答の明細には,一つの品目に対して複数の調達条件が返ってくるこ とがある。例えば,ロットサイズが1,909個の品目に対して,見積依頼の必要 調達数量が300個の場合,仕入先から,ロットサイズ1,000個で単価9.5円, ロットサイズ1個で単価2円,という2通りの見積回答の明細が返ってくる。 8.発注から入荷まで ー9一 (1)仕入先からの見積回答を受けて,得意先と相談の上,品目ごとに妥当な調達 条件を一つだけ選定する。 ①選定した調達条件に対応する見積回答明細を発注明細に記録し,発注ロッ ト数,指定納入年月日を決める。 ②同時期に同じ仕入先に発注する発注明細は,試作案件が異なっても,1回の 発注に東ねる。 ③発注ごとに発注番号を付与し,発注年月日と発注合計金額を記録する。 (2)発注に基づいて,仕入先から品目を入荷する。 ①入荷ごとに入荷番号を付与し,入荷年月日を記録する。 ②入荷の品目ごとに入荷明細番号を発行する。1件の発注明細に対して,入荷 が分かれることはない。 ③入荷番号と入荷明細番号が書かれたシールを品目の外装に貼って,製造担 当へ引き渡す。 【利用者の要望] 1,品目分類の階層化 品目分類を大分類,中分類,小分類のような階層的な構造にしたい。当面は3階 層でよいが,将来的には階層を増やす可能性がある。 2.仕入先からの分納 ー部の仕入先から1件の発注明細に対する納品を分けたいという分納要望が出て きた。分納要望に応えつつ,未だ納入されていない数量である発注残ロット数も 記録するようにしたい。 [現行業務の概念データモデルと関係スキーマの設計] 現行業務の概念データモデルを図1に,関係スキーマを図2に示す。 ー10一 L\ 取扱いロ 構成品目 図1現行業務の概念データモデル(未完成) 社員所属(社員コード,社員氏名,社員所属組織コード,社員所属組織名社員所属上位組織コード, 社員所属上位組織名社員役職コード,社員役職名,報告先社員コード,報告先社員氏名) 取引先(取引先コード,取引先名,取引先区分住所) 得意先(取引先コード,昨年度受注金額 仕入先(取引先コード,昨年度調達金額 ブランド(ブランドコード,ブランド名) 品目分類(品目分類コード,品目分類名) 品目(メーカー漠式番号,プランドコード,品目分類コード) 取扱いブランド(取引先コード,ブランドコード) 試作案件(試作案件番号,試作案件名,取引先コード,製品用途,試作案件登録年月日 モデル(モデル名,| 』|,製造台数,得意先希望納入年月日設計図面番号) モデル構成品目(モデル名| 』|,メーカー型式番号,1台当たりの所要数量) 試作案件品目(試作案件番号,メーカー型式番号合計所要数量,|5|) 見積依頼(見積依頼番号見策依頼年月日,) 見積依頼明細(見積依頼番号見積依頼明細番号,メーカー型式番号,必要調達数量,希望納入年月日) 見積加答(見策依頼番号,見積回答番号,見積有効期限,見策回答年月日) 見策回答明細(見積回答明細番号,見生依頼明細番号単価,納入可能年月日,|q]) 発注(発注番号,発注年月日,発注合計金額 発注明細(発注番号,発注明細番号指定納入年月日|e|) 入荷(入荷番号,入荷年月日) 入荷明細AGES,入荷明細番号,発注番号,発注明細番号) 図2現行業務の関係スキーマ(未完成) 解答に当たっては,巻頭の表記ルールに従うこと。ただし,エンティティタイプ 間の対応関係にゼロを含むか否かの表記は必要ない。エンティティタイプ間のリレ ーションシップとして“多対多"のリレーションシップを用いないこと。属性名は. 意味を識別できる適切な名称とすること。関係スキーマに入れる属性を答える場合 主キーを表す下線,外部キーを表す破線の下線についても答えること。

共通の文章

ホテルの予約システムの概念データモデリングに関する次の記述を読んで,設問 に答えよ。 ホテルを運営するX社は,予約システムの再構築に当たり,現状業務の分析及び新 規要件の洗い出しを行い,概念データモデル及び関係スキーマを設計した。 〔現状業務の分析結果] 1.ホテル (1)全国各地に19のホテルを運営している。ホテルはホテルコードで識別する。 (2)客室はホテルごとに客室番号で識別する。 (3)客室ごとに客室タイプを設定する。客室タイプはホテル共通であり,BEY イプコードで識別する。客室タイプにはシングル,ツインなどがある。 (4)館内施設として,レストラン,ショップ,プールなどがある。 2.会員 利用頻度が高い客向けの会員制度があり,会員は会員番号で識別する。会員に は会員番号が記載された会員証を送付する。 3.旅行会社 X社のホテルの宿泊予約を取り扱う複数の旅行会社があり,旅行会社コードで識 別する。 4.予約 (1)自社サイト予約と旅行会社予約があり,予約区分で分類する。 (2)自社サイト予約では,Bld X社の予約サイトから予約する。旅行会社予約で は,客は旅行会社を通じて予約する。旅行会社の予約システムからX社の予約 システムに予約情報が連携され,どの旅行会社での予約かが記録される。 (3)1回の予約で,客は宿泊するホテル,客室タイプ,泊数,客室数,BAAR, チェックイン予定年月日を指定する。予約は予約番号で識別する。 (4)宿泊時期,予約状況を踏まえて,予約システムで決定した1室当たりの宿泊 料金を記録する。 (5)客が会員の場合,会員番号を記録する。会員でない場合は,予約者の氏名と 住所を記録する。 ー13一 5.宿泊 客室どとのチェックインからチェックアウトまでを宿泊と呼びホテル共通の 宿泊番号で識別する。 6.チチエックタイン フロントで宿泊の手続を行う。 (1)予約有の場合には該当する予約を検索し,客室を決め,宿泊を記録する。泊 数,宿泊人数,宿泊料金は,予約から転記する。泊数,宿泊人数,宿泊料金が 予約時から変更になる場合には,変更後の内容を記録する。 (2)予約無の場合には泊数,宿泊人数,宿泊料金を確認し,客室を決め,宿泊を 記録する。 (3)宿泊者が会員の場合,会員番号を記録する。ただし,予約有の場合で宿泊者 が予約者と同じ場合,予約の会員番号を宿泊に転記する。 (4)一つの容室に複数の会員が宿泊する場合であっても記録できるのは,代表者 1人の会員番号だけである。 (5)宿泊ごとに宿泊者全員の氏名,住所を記録する。 (6)客室のカードキーを宿泊客に渡し,チェックイン年月日時刻を記録する。 1,チェエックアウト フロントで客室のカードキーを返却してもらう。チェックアウト年月日時刻を 記録する。 8.精算 (1)通常,チェックアウト時に宿泊料金を精算するが,客が希望すれば,予約時 又はチェックイン時に宿泊料金を前払いすることもできる。 (2)宿泊客が館内施設を利用した場合,その場で料金を支払わずにチェックアウ ト時にまとめて支払うことができる。館内施設の利用料金は予約システムとは 別の館内施設精算システムから予約システムに連携される。 9.会員特典 会員特典として,割引券を発行する。券面には割引券を識別する割引券番号と 発行先の会員番号を記載する。割引券には宿泊割引券と館内施設割引券があり, 割引券区分で分類する。1枚につき,1回だけ利用できる。割引券の状態には未利 用,利用済,有効期限切れによる失効があり,割引券ステータスで分類する。 =1= (1)宿泊割引券 ①会員の宿泊に対して,次回以降の宿泊料金に充当できる宿泊割引券を発行 し,郵送する。1回の宿泊で割引券を1枚発行し,泊数に応じて割引金額を変 える。旅行会社予約による宿泊は発行対象外となる。発行対象の宿泊かどう かを割引券発行区分で分類する。 ②予約時の前払いで利用する場合,宿泊割引券番号を記録する。1回の予約で 1枚を会員本人の予約だけに利用できる。 ③ホテルでのチェックイン時の前払いし,チェックアウト時の精算で利用する 場合,宿泊割引券番号を記録する。1回の宿泊で1枚を会員本人の宿泊だけに 利用できる。 (2)館内施設割引券 ①館内施設割引券を発行し,定期的に送付している会員向けのダイレクトメ ールに同封する。館内施設の利用料金に充当できる。チェックアウト時の精 算だけで利用できる。 ②チェックアウト時の精算で利用する場合,館内施設割引券番号を記録する。 1回の宿泊で1枚を会員本人の宿泊だけに利用できる。宿泊割引券との併用が 可能である。 [新規要件 会員特典として宿泊時にポイントを付与し,次回以降の宿泊時の精算などに利用 できるポイント制を導入する。ポイント制は次のように運用する。 (1)会員ランクにはゴールド,シルバー,ブロンズがあり,それぞれの必要累計泊 数及びポイント付与率を決める。ポイント付与率は上位の会員ランクほど高くす る。 (2)毎月末に過去1年間の累計泊数に応じて会員の会員ランクを決める。 (3)チェックアウト日の翌日午前9時に宿泊料金にポイント付与率を乗じにたポイン トを付与する。この場合のポイントの有効期限年月日は付与日から1年後である。 (4)宿泊料金に応じたポイントとは別に,個別にポイントを付与することがある。 この場合のポイントの有効期限年月日は1年後に限らず,任意に指定できる。 (5)ポイントを付与した際に,有効期限年月日及び付与したポイント数を未利用ポ =i= イント数の初期値として記録する。 (6)ポイントは宿泊料金,館内施設の利用料金の支払に充当でき,これを支払充当 と呼ぶ。支払充当では,支払充当区分(POR,チェックイン時,チェックアウ ト時のいずれか),ポイントを利用した予約の予約番号又は宿泊の宿泊番号を記 録する。 (7)ポイントは商品と交換することもでき,これを商品交換と呼ぶ。商品ごとに交 換に必要なポイント数を決める。ホテルのフロントで交換することができる。交 換時に商品と個数を記録する。 (8)支払充当,商品交換でポイントが利用される都度,その時点で有効期限の近い 未利用ポイント数から利用されたポイント数を減じて,消し込んでいく。 (9)未利用のまま有効期限を過ぎたポイントは失効し,未利用ポイント数をOCT る。失効の1か月前と失効後に会員に電子メールで連絡する。失効前メール送付 日時と失効後メール送付日時を記録する。 (10)ポイントの付与,支払充当,商品交換及び失効が発生する都度,ポイントの 増減区分,増減数及び増減時刻をポイント増減として記録する。具体例を表1に 示す。 表1ポイント増減の具体例 2023年3月31日現在 Sa|増減|ポイント|ポイントポイント有効期限未利用商品|gay 番号|連番|増減区分|増減数増減時刻年月日ポイント数|コードna: Fraoor||人5|3,000]2ozn-or-ze oosoofamaa-or-an[of-|-|=| Provo|eg|人gm|2,000]2oz0-0r-25 96:09|2egz724|of-|-[= |mi|eees|seiasem|-3000|2425i895|-|-|-|=|-| 7061|Ce4|mace|500|022025i6:9|—|-|iml24ル|3 wi|es|seam|soo]eoas-or-z2 wio[-|-|-|=|=| |7Wg|ei|人|3000|2000-06-14 0:09|298-06q3|ree|-|-|= eg|ee|seme|2,000)amrem mel-|-|=|=[=| 注記"一"は空値であることを示す。 [概念データモデルと関係スキーマの設計] 1.概念データモデル及び関係スキーマの設計方針 (1)概念データモデル及び関係スキーマの設計は,まず現状業務について実施し, その後に新規要件に関する部分を実施する。 (2)関係スキーマは第3正規形にし,多対多のリレーションシップは用いない。 (3)概念データモデルでは,リレーションシップについて,対応関係にゼロを含 むか否かを表す“O”Rit“O”は記述しない。 (4)サブタイプが存在する場合,他のエンティティタイプとのリレーションシッ プは,スーパータイプ又はいずれかのサブタイプの適切な方との間に設定する。 2.[現状業務の分析結果〕)に基づく設計 現状の概念データモデルを図1に,関係スキーマを図2に示す。 [«=|ー 割引券||was L\ハ 予約有.BBB 図1現状の概念データモデル(未完成) ホテル(ホテルコード,ホテル名) 客室タイプ(容室タイプコード,容室タイプ名,定員数) 客室(ホテルコード,SEBS,) 旅行会社(旅行会社コード,旅行会社名) 会員(会員番号,メールアドレス,KS,生年月日,電話番号,BERS,住所) 予約(予約番号,予約者氏名,住所,予約区分,チェックイン予定年月日,泊数,客室数,宿泊人数, 1室当たり宿泊料金,予約時前払い金額,SARS,) 宿泊(宿泊番号,予約有無区分,泊数,宿泊人数,宿泊料金チェックイン時前払い金額 館内施設利用料金チェックアウト時精算金額,割引券発行区分,チェックイン年月日時刻, チェックアウト年月日時刻,会員番号,) 予約有宿泊(宿泊番号,) 割引券発行対象宿泊(宿泊番号,割引券発行済フラグ) 宿泊者(宿泊番号,宿泊者明細番号,氏名住所) 割引券(割引券番号,割引券区分,割引券名,割引金額,有効期限年月日,発行年月日 割引券ステータス,会員番号) 宿泊割引券(割引券番号,発行元宿泊番号) 館内施設割引券(割引券番号,ダイレクトメール送付年月日) 図2現状の関係スキーマ(未完成) 3.[新規要件〕】に関する設計 新規要件に関する概念データモデルを図3に,関係スキーマを図4に示す。 図3新規要件に関する概念データモデル(未完成) 会員(会員番号,メールアドレス,BS,生年月日,電話番号郵便番号,住所,会員ランクコード, 過去1年累計泊数) 会員ランク(会員ランクコード。,会員ランク名,) 商品(商品コード,) ポイント増減(会員番号,ポイント増減連番,) ポイント付与(会員番号,ポイント増減連番,失効前メール送付日時) ポイント失効(会員番号,ポイント増減連番,) 支払充当(会員番号,ポイント増減連番,予約番号,宿泊番号,) 商品交換(会員番号,ポイント増江連番,|サ|) 図4新規要件に関する関係スキーマ(未完成) 解答に当たっては,巻頭の表記ルールに従うこと。また,エンティティタイプ名, 関係名,属性名は,それぞれ意味を識別できる適切な名称とすること。関係スキー マに入れる属性名を答える場合,主キーを表す下線,外部キーを表す破線の下線に ついても答えること。

共通の文章

る次の記述を読んで,設問に答えよ。 ハウス栽培農家向けの農業用機器を製造・販売するB社は,農家のDXを支援する 目的で,RDBMSを用いたハウス栽培のための観測データ分析システム(以下,分析シ ステムという)を構築することになり,運用部門のCさんが実装を担当した。 [業務の概要〕 1.BS,08,農事日人 (1)顧客は,ハウス栽培を行う農家であり,顧客IDで識別する。 (2)園場は,農家が農作物を育てる場所の単位で,MAIDで識別する。園場には ーつの農業用ハウス(以下,ハウスという)が設置され,トマト,イチゴなど の農作物が1種類栽培される。 (3)圏場の日出時刻と日没時刻は,BORE,緯度,標高によって日ごとに変 わるが,あらかじめ計算で求めることができる。 (4)日出時刻から翌日の日出時刻の1分前までとする日付を,農事日付という。 農家は,農事日付に基づいて作業を行うことがある。 2.制御機器・センサー機器,統合機器,観測データ,積算温度 (1)圧場のハウスには,ハウスの天窓の開閉。カーテン,暖房,海水などを制御 する制御機器,及び温度(気温),湿度,水温,地温日照時間,RRAAIR 度などを計測するセンサー機器が設置される。 (2)顧客は,園場の一角に設置したB社の統合環境制御機器(以下,統合機器と いう)を用いて,ハウス内の各機器を監視し,操作する。もし統合機器が何か 異常を検知すれば,顧客のスマートフォンにその異常を直ちに通知する。 (3)統合機器は,各機器の設定値と各センサー機器が毎分計測した値を併せて記 録した1件のレコードを,B社の分析システムに送り,蓄積する。分析システ Alt,蓄積されたレコードを観測データとして分析しやすい形式に変換し,at 測された日付ごと時分ごと較場ごとに1行を"観測"テーブルに登録する。 (4)農家が重視する積算温度は,1日の平均温度をある期間にわたって合計した もので,生育の進展を示す指標として利用される。例えば,トマトが開花して =BO から完熟するまでに必要な積算温度は,1,999-1,199Cてといわれている。 (5)分析システムの目標は,対象にする賠場を現状の190賠場から段階的に増や し,将来1,009 Mi CHR 5年間の観測データを分析できることである。 [分析システムの主なテーブル]〕] Cさんが設計した主なテーブル構造を図1に,主な列の意味・制約を表1に示す。 また,"観測"テーブルの主な列統計,索引定義,制約,表領域の設定を表2に示す。 顧客(顧客ID,WARA,連絡先情報,…) fis,(Hite 1D,Bin,顧客ILD,RE,経度,標高,…) 園場カレンダ(標準日付,賠場ID,日出時刻,日没時刻,日出方位角,日没方位角) 観測(観測日付,観測時分,園場ID,農事日付,分平均温度,分日照時間,機器設定情報,…) 図1テーブル構造(一部省略) 表1主な列の意味・制約 意味制約 標準日付1日の区切りを,9時6分9秒から23時59分59秒までとする日付 観測日付,彫場内の各種センサーが計測したときの標準日付と時分。時分は,9時9分から 観測時分23時59分までの1分単位 1日の区切りを,園場の日出時刻から翌日の日出時刻の1分前までとする日付 分平均温度|ハウス内の温度(気温)の1分間の平均値 表2観測”テーブルの主な列統計,索引定義,制約,表領域の設定(一部省略) 主索引副次索引_ ia 4B 4a enc TEE Ce i a Porras Te|rl eos 画p cr)3s|i1 mR emerツョたり人 ||sz|ぐー2半たり和有数 FOREIGN KEY(観測日付,(it 1D)REFERENCES BHD|ab—Alay|ey 9(標準日付,岡場ID)ON DELETE CASCADE ヽ立ャーーーin 注記網掛け部分は表示していない。 (RDBMSの主な仕様〕 1.行の挿入・削除,再編成 (1)行を挿入するとき,表領域の最後のページに行を格納する。最後のページに 空き領域がなければ,新しいページを表領域の最後に追加し,行を格納する。 (2)最後のページを除き,行を削除してできた領域は,行の挿入に使われない。 (3)再編成では,削除されていない全行をファイルにアンロードした後,初期化 した表領域にその全行を再ロードし,併せて索引を再作成する。 2.区分化 (1)テーブルごとに一つ又は複数の列を区分キーとし,区分キーの値に基づいて 表領域を物理的に分割することを,区分化という。 (2)区分方法には次の2種類がある。し ・レンジ区分:区分キーの値の範囲によって行を区分に分配する。 ・ハッシュ区分:区分キーの値に基づき,RDBMSが生成するハッシュ値によって 行を一定数の区分に分配する。区分数を変更する場合,全行を再分配する。 (3)レンジ区分では,区分キーの値の範囲が既存の区分と重複しなければ区分を 追加でき,任意の区分を切り離すてともできる。区分の追加,切離しのとき, 区分内の行のログがログファイルに記録されることはない。 (4)区分ごとに物理的に分割される索引(以下,分割索引という)を定義できる。 区分を追加したとき,当該区分に分割索引が追加され,また,区分を切り離し たとき,当該区分の分割索引も切り離される。 〔観測データの分析〕 1.観測データの分析 分析システムは,農家の要望に応じて様々な観点から観測データを分析し,そ の結果を農家のスマートフォンに表示する予定である。Cさんが設計した観測デー タを分析するSQL文の例を表3のSQL1に,結果行の一部を後述する図2に示す。 表3観測データを分析するSQL文の例(未完成) Serio Been SQL1 WITH R(園場ID,農事日付,日平均温度,行数)AS( SELECT*FROM R =GE= 2.SQL文の改良 顧客に表3のSQL1の日平均温度を折れ線グラフにして見せたところ,知りたい のは日々の温度の細かい変動ではなく,変動の傾向であると言われた。そこでCさ Ald,折れ線グラフを滑らかにするため,表4のSQL2のように改良した。SQL2が 利用した表3のSQL1の結果行の一部を図2に,SQL2の結果行を図3に示す。 表4改良したSQL文 SOL文の構文(上段:目的下段:構文) 指定した賠場と農事日付の期間について,日ごとの日平均温度の変動傾向を調べる。 WITH R(M38 1D,農事日付,日平均温度,行数as(||) SQL2|SELECT農事日付,AVG(日平均温度)OVER(ORDER BY農事日付 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)AS X FROM R WHERE賠場ID=:h1 AND農事日付BETWEEN:h2 AND:h3 注記1ホスト変数のh1には了賠場IDを,h2には期間の開始日(2923-92-91)を,h3には終了日 (2023-02-10)を設定する。 注記2網掛け部分は,表3のSQL1のRを求める問合せと同じなので表示していない。 Loo|sw|se[=|[me|還ヨー Poo|ama[we[=|[meee[TT Loo|sem|we[| Loo|sew|we[| oo|www|me[=| oo|ww|me| Poo|www|we[=| |oo|mww|we[=| Poo|www|me[=| Loo|ae|mm[=| 注記日平均温度は,小数第1位まで表示した。注記1 Xは,小数第1位まで表示した。 注記2網掛け部分は表示していない。 図2 SQL1の結果行の一部図3 SQL2の結果行(未完成) 3.積算温度を調べるSQL文 農家は,栽培している農作物の出荷時期を予測するために積算温度を利用する。 —_23ーー Cさんが設計した積算温度を調べるSQL文を,表5のSQL3に示す。 表5積算温度を調べるSQL文(未完成) SOL文の構文(上段:目的,下段:構文) 指定した農事日付の期間について,園場ごと農事日付ごとの積算温度を調べる。 WITH R(4%1D,農事日付,日平均温度,行数)AS(||) sol 3|SELECT mise 10,農事日付,SUM(|f|) OVER(PARTITION BY[is|ORDER BY ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)AS積算温度 FROM R WHERE農事日付BETWEEN:h1 AND:h2 注記1ホスト変数のh1とh2には積算温度を調べる期間の開始日と終了日を設定する。 注記2網掛け部分は,表3のSQL1のRを求める問合せと同じなので表示していない。 [“観測”テーブルの区分化〕 1.物理設計の変更 Cさんは,大容量になる“観測”テーブルの性能と運用に懸念をもったので,次 のようにテーブルの物理設計を変更し,性能見積りと年末処理の見直しを行った。 (1)表領域のページ長を大きくすることで1ページに格納できる行数を増やす。 (2)園場IDごとに農事日付の1月1日から12月31日の値の範囲を年度として, その年度を区分キーとするレンジ区分によって区分化する。 |(3)新たな彫場を追加する都度,当該園場に対してそのときの年度の区分を1個 追加する。 2.性能見積り 表5のSQL3について,表2に示した副次索引から100日間の観測データ144,000 行を読み込むことを仮定した場合の読込みに必要な表領域のページ数を,区分化 前と区分化後のそれぞれに分けて見積もり,表6に整理して比較した。 表6区分化前と区分化後の読込みに必要な表領域のページ数の比較(未完成) 比較項目区分化前区分化後 ページ当たりの行数(ページ長)4行(4,.099バイト)16行(16,000バイト) 3.年末処理の見直し 5年以上前の不要な行を効率よく削除し,表領域を有効に利用するための年末処 理の主な手順を,区分化前と区分化後のそれぞれについて検討し,表7に整理した。 表7区分化前と区分化後の年末処理の主な手順の比較(未完成) ee 注記二重引用符で囲んだ名前は,テーブル名を表す。 oe 2.2.観測”に翌年度の区分を追加する。 1.*周場カレンダ"に翌年の行を追加する。|1.“BALI”CBEOREBEMT SZ. 5