DBデータベーススペシャリスト試験午後Ⅱ

令和2年度10月データベーススペシャリスト午後Ⅱ 問1

事例を読んで設問の答えを考えてから、解説のポイントとIPA公式の解答例・採点講評で確認しましょう。

問題

問1　データベースの設計，実装に関する次の記述を読んで，設問1～3に答えよ。太陽光発電設備，空調設備などの住宅設備メーカであるJ社は，家庭の電気の使用状況を可視化するサービスの提供に向け，節電支援システムの構築を行っている。〔業務の概要〕（1）J社は，太陽光発電機器，配電盤，スマートメータ，空調機器などの機器との通信機能をもつコントローラを提供している。ユーザは，住居にコントローラを設置して，節電支援システムに住居及びコントローラの情報を登録する。（2）コントローラは，J社とネットワーク接続し，住居内の機器から収集した買電，発電，使用電力，機器のログなどの情報をJ社に送信する。J社では，情報をデータベースに蓄積，加工してユーザに節電支援情報を提供する。その一つとして，使用電力量表示画面の例を図1に示す。図1では，使用電力量とその供給元の内訳（買電，発電など）が示される。図1　使用電力量表示画面の例（3）節電支援情報には，日射量を基に算出された標準発電量が含まれる。全国の800観測点で計測された日射量データを外部から取得する。（4）自治体，他の企業からの依頼を受けて，蓄積したデータを統計用に集計し，個人情報を含まないアドホック分析用のデータを抽出して提供する。〔節電支援システムのテーブル構造〕設計済みのテーブル構造を図2に，主な列とその意味・制約を表1に示す。図2　節電支援システムのテーブル構造（一部省略）表1　主な列とその意味・制約〔節電支援システムの処理〕節電支援情報の提供，アドホック分析の処理の例を，表2に示す。表2　処理の例〔RDBMSの仕様〕 1．テーブル・索引（1）RDBMSとストレージ間の入出力単位をページという。（2）同じページに異なるテーブルのデータが格納されることはない。（3）NOT NULL制約を指定しない列には，1バイトのフラグが付加される。（4）列の主なデータ型は，表3のとおりである。（5）索引にはユニーク索引と非ユニーク索引がある。（6）DMLのアクセスパスは，RDBMSによって索引探索又は表探索が選択される。索引探索が選択されるためには，WHERE句又はON句のANDだけで結ばれた一つ以上の等値比較の述語の対象列が，索引キーの全体又は先頭から連続した一つ以上の列に一致していなければならない。（7）索引探索では，ページの読込みはバッファを介して行われ，バッファの置換えはLRU方式で行われる。同じページ長のテーブルは，一つのバッファを共有する。バッファごとにバッファサイズを設定する。（8）索引のキー値の順番と，キー値が指す行の物理的な並び順が一致している割合（以下，クラスタ率という）が高いほど，隣接するキー値が指す行が同じページに格納されている割合が高い。表3　列の主なデータ型 2．ウィンドウ関数 RDBMSがサポートする主なウィンドウ関数を，表4に示す。表4　RDBMSがサポートする主なウィンドウ関数 3．クラスタ構成のサポート（1）シェアードナッシング方式のクラスタ構成をサポートする。クラスタは複数のノードで構成され，各ノードには専用のディスク装置をもつ。（2）ノードへのデータの配置方法には複製，分散の二つがあり，テーブルごとにどちらかを指定する。複製は，各ノードにテーブルの全行を配置する方法である。分散は，一つ又は複数の列を分散キーとし，その値に基づいてRDBMS内部で生成するハッシュ値によって，各ノードにデータを配置する方法である。（3）データベースへの要求は，いずれか一つのノードで受け付ける。要求を受け付けたノードは，要求を解析し，自ノードに配置されているデータへの処理は自ノードで処理を行う。自ノードに配置されていないデータへの処理は，当該データが配置されている他ノードに処理を依頼し，結果を受け取る。〔システムの構成〕（1）複数のAPサーバと複数のDBサーバから成る。ユーザは，APサーバを介して操作を行う。APサーバはいずれか一つのDBサーバにアクセスする。（2）データベースは，シェアードナッシングのクラスタ構成とし，20ノードを配置する。各ノードには同じ仕様のDBサーバを配置する。クラスタ構成によるDBサーバ全体のTPSは，ノード数に比例することを確認している。（3）機器ログ，買電，発電，使用電力の各テーブルは，配置方法を分散にし，住居番号を分散キーに指定する。それ以外のテーブルの配置方法は複製にする。〔データベースの物理設計〕 1．テーブルの行数，所要量見積り次の前提で主なテーブルの行数，所要量を見積もり，表5を作成した。（1）日射量，機器ログ，買電，発電，使用電力は，2年前の1月1日から現在まで，最大3年分のデータを保存する。1年を360日として行数を見積もる。（2）どのテーブルもページ長を2、000バイト，空き領域率を10％とする。（3）見積ページ数は，“見積行数÷ページ当たり平均行数”の小数部を切り上げる。ページ当たり平均行数は，“ページ長×（1－空き領域率）÷平均行長”の小数部を切り捨てる。（4）所要量は，“見積ページ数×ページ長”で算出する。表5　主なテーブルの見積行数・所要量 2．テーブル定義表の作成次の方針に基づいてテーブル定義表を作成した。その一部を表6～8に示す。（1）データ型欄には，適切なデータ型，適切な長さ，精度，位取りを記入する。（2）NOT NULL欄には，NOT NULL制約がある場合だけYを記入する。（3）格納長欄には，RDBMSの仕様に従って，格納長を記入する。（4）索引の種類には，P（主キーの索引），U（ユニーク索引），NU（非ユニーク索引）のいずれかを記入し，各構成列欄には，構成列の定義順に1からの連番を記入する。該当する索引がなければどちらも空欄にする。（5）主キー及び外部キーには，索引を定義する。表6　“買電”テーブルのテーブル定義表表7　“発電”テーブルのテーブル定義表表8　“使用電力”テーブルのテーブル定義表 3．テーブル構造の検討表2の処理1では，ストレージからの読込みに時間が掛かるおそれがあるので，次の前提で読込みページ数の予測を行い，必要であれば対策を講じる。（1）前提・図1の使用電力量表示画面で，年月日の区分を「月」，対応する年月を「2019年4月」，比較対象を「前年の同じ月」として照会を行う。・“買電”，“発電”，“使用電力”の各テーブルには，住居番号当たりの行数は均等で，どのページにも最大行数分の行が格納されているものとする。・アクセスパスは，どのテーブルも索引探索が選択されるものとする。索引のバッファヒット率は，100％とする。（2）予測・表9に使用電力量表示画面における読込みページ数の予測をまとめた。・探索行数は，選択条件に一致する行を求めるために読み込む行数である。・最小読込みページ数は，クラスタ率が最も高い場合の読込みページ数で，“【a】÷【b】”の小数部を切り上げた値に等しい。・最大読込みページ数は，クラスタ率が最も低い場合の読込みページ数で，【c】に一致する。・クラスタ率50％の読込みページ数を平均読込みページ数といい，“（最小読込みページ数＋最大読込みページ数）×50％”の小数部を切り上げる。表9　使用電力量表示画面における読込みページ数の予測（未完成）（3）対策表9の結果から照会の応答時間が長すぎると判断した。そこで，次の対策を行うことで，平均読込みページ数を100以下にすることにした。・照会対象となる電力量を集計した一つ又は複数のテーブルを追加する。・追加したテーブルには，前日までの集計行を夜間バッチ処理で追加する。・当日の電力量は“買電”，“発電”，“使用電力”の各テーブルから求め，それ以外の電力量は追加したテーブルから求める。〔問合せの検討〕 1．表2の処理3の問合せ処理3の問合せ内容を表10に整理し，問合せに用いるSQL文を図3に作成した。問合せ内容は，次の要領で記入し，内容のない欄は“－”にする。（1）行ごとに構成要素となる問合せを記述する。結果を他の問合せで参照する場合は，行に固有の名前（以下，問合せ名という）を付ける。（2）列名又は演算には，テーブルから射影する列名又は演算（MAX関数，AVG関数など）によって求まる項目を“項目名＝［演算の概要］”の形式で記述する。（3）テーブル名又は問合せ名には，参照するテーブル名又は問合せ名を記入する。（4）選択又は結合の内容には，テーブル名又は問合せ名ごとの選択条件，結合の具体的な方法と結合条件を記入する。表10　処理3の問合せ内容図3　処理3の問合せに用いるSQL文（未完成） 2．表2の処理4の問合せ処理3と同様に，処理4の問合せ内容を表11に整理し，問合せに用いるSQL文を図4に作成した。表11　処理4の問合せ内容（未完成）図4　処理4の問合せに用いるSQL文（未完成）〔性能テストの実施〕ピーク時の処理性能を見積もった上で，性能テストを実施して検証する。 1．性能テストの方針（1）DBサーバ2台による2ノードのクラスタ構成のテスト環境を使用する。各DBサーバの仕様は本番のDBサーバと同じにする。また，ページ長が2、000バイトのバッファには，480、000ページ分のサイズを設定する。（2）ピーク時の5分間に，表2中の複数の処理が，それぞれ複数同時にDBサーバ上で実行される状況を模してテストを行い，応答時間を計測して見積りと比較する。処理は，それぞれピーク時の想定に基づきDBサーバごとに50～100の多重度で実行する。（3）表5の見積行数を基に，テスト環境の特性を踏まえて，適切な行数，適切な列値，参照整合性を備えたテストデータを作成する。 2．応答時間の見積り次の前提に基づいて，トランザクション当たりの応答時間見積りを表12にまとめた。（1）ページ当たりのバッファへのアクセス時間は，平均0.1ミリ秒である。（2）ページ当たりのストレージへのアクセス時間は，平均8ミリ秒である。（3）各DBサーバは，本テストにおける最大の同時並行処理数を上回る並行処理能力を備えている。（4）DBサーバ上の実行待ち時間，ネットワーク待ち時間，CPU待ち時間は考慮しない。表12　トランザクション当たりの応答時間見積り 3．テストデータの作成主なテーブルのテストデータの作成要領を表13に示す。表13　主なテーブルのテストデータの作成要領 4．性能テストの結果性能テストの実行結果を図5に示す。図5の処理の実行時間帯の列は，10秒間を表し，網掛け部分は，その処理が1回以上実行された時間帯を表す。応答時間の実測値を表12の見積りと比較したところ，次の差異があった。差異1：処理5は，どの時間帯でもバッファヒット率が90％を超え，応答時間は見積りの約50分の1だった。差異2：処理3は，図5中の①及び②の時間帯で応答時間が見積りよりも長かった。図5　性能テストの実行結果設問1　〔データベースの物理設計〕について，（1），（2）に答えよ。（1）表2の処理2では，比較対象住居を索引内で絞り込むようにしたい。そのために，“住居”テーブルに，主キー，外部キー以外の索引を一つ定義する。索引を構成する列名を定義順に答えよ。（2）“3．テーブル構造の検討”について，次の①～③に答えよ。 ①予測について，本文中の「【a】」～「【c】」に入れる適切な字句を，本文中の用語を用いて答えよ。また，表9中の【d】～【f】に入れる適切な数値を答えよ。 ②対策について，追加するテーブルのテーブル構造を答えよ。解答に当たっては，巻頭の表記ルールに従うこと。なお，“列1番，列2番，列3番，列4番”のように，一定の規則で連続する列名は，“列1番，…列4番”のように間を省略してもよい。また，買電，発電，使用電力を区別する列を用いる場合は，列名を“電力区分”とし，データ型をCHAR(1)とせよ。 ③②のテーブルを使用して使用電力量照会を行う場合の読込みページ数予測を行い，②のテーブルの最小読込みページ数，最大読込みページ数を答えよ。設問2　〔問合せの検討〕について，（1），（2）に答えよ。（1）図3中の【g】～【k】に入れる適切な字句を答えよ。（2）表11中の【l】～【o】，図4中の【p】に入れる適切な字句を答えよ。設問3　〔性能テストの実施〕について，（1），（2）に答えよ。（1）“3．テストデータの作成”について，次の①，②に答えよ。 ①“住居”テーブルの行数は見積行数の10分の1の行数となっている。この行数で本番環境の性能が推測できる理由を50字以内で述べよ。 ②表13の下線部について，地域コードに値を設定する上で留意すべき事項を具体的に50字以内で述べよ。（2）“4．性能テストの結果”の差異1，差異2について，最も可能性が高いと考えられる差異の発生原因を，それぞれ具体的に50字以内で述べよ。

図1　使用電力量表示画面の例。年月日と比較対象を選択し、日ごとの使用電力量を供給元別の積み上げ棒グラフと比較対象の折れ線で示す画面。

図2　節電支援システムのテーブル構造（一部省略）。電力会社、住居、機器、日射量、買電、発電、使用電力などのテーブル名と列構成を示す一覧図。

表1　主な列とその意味・制約。時間帯番号、地域コード、住居番号、各種電力量などの列について、意味や値の範囲を示す表。

表2　処理の例。節電支援システムの処理1から処理5について、抽出・集計・順位付けなどの内容を示す表。

表3　列の主なデータ型。CHAR、NCHAR、NCHAR VARYING、SMALLINT、INTEGER、DECIMAL、DATEの仕様を示す表。

表4　RDBMSがサポートする主なウィンドウ関数。RANK関数とNTILE関数の構文および区画化・順位付け・階級化の動作を示す表。

表5　主なテーブルの見積行数・所要量。地域、住居、配電回路、機器、機器ログ、日射量、買電、発電、使用電力の行数とページ数・容量を示す表。

表6　“買電”テーブルのテーブル定義表。買電テーブルの列名、データ型、NOT NULL、格納長、主キー構成列を示す表。

表7　“発電”テーブルのテーブル定義表。発電テーブルの列名、データ型、NOT NULL、格納長、主キー構成列を示す表。

表8　“使用電力”テーブルのテーブル定義表。使用電力テーブルの列名、データ型、NOT NULL、格納長、主キー構成列を示す表。

表9　使用電力量表示画面における読込みページ数の予測（未完成）。買電、発電、使用電力について結果行数、探索行数、最小・最大読込みページ数を整理した未完成表。

表10　処理3の問合せ内容。処理3について、W1からW4の問合せ名、射影列、参照テーブル、選択条件と結合条件を整理した表。

図3　処理3の問合せに用いるSQL文（未完成）。住居と日射量の距離計算、RANK、平均標準発電量、発電量集計を行う未完成SQL文。

表11　処理4の問合せ内容（未完成）。処理4について、地域別の使用電力量集計、NTILEによる階級化、地域との結合を整理した未完成表。

図4　処理4の問合せに用いるSQL文（未完成）。使用電力と住居を集計し、地域ごとにNTILEで5階級へ分ける未完成SQL文。

表12　トランザクション当たりの応答時間見積り。処理2、処理3、処理5についてアクセスページ数、バッファヒット率、応答時間を示す表。

表13　主なテーブルのテストデータの作成要領。住居、配電回路、買電、発電・使用電力、機器ログ、日射量のテストデータ作成要領を示す表。

図5　性能テストの実行結果。処理2、処理3、処理5が0分台から4分台の各時間帯で実行された状況を網掛けで示す図。

解き方のヒントを見る

条件差と結果差を対応付ける

性能に関する設問では、結果の数値だけを見て原因を決めつけず、比較されている条件のどこが異なり、その違いが処理のどの段階に影響し得るかを一つずつ対応付けて考えることが、根拠のある判断につながります。

この問題で問われていること

確認したい観点は一つです。記述された構成・データ・処理内容のうち、比較対象の間で何が同じで何が違うのかを整理し、その違いと観測された結果の差が論理的に結び付くかどうかを、本文の記述を根拠に確かめてください。

視点

複数の要素が関わる性能の検討では、結果の差を説明する要因の候補がいくつも考えられます。まず比較対象の間で変わっていない前提を押さえ、そのうえで変わった条件を洗い出します。次に、その条件が処理の流れのどこで効き得るかを本文の記述に沿って確かめます。一般論として成り立ちそうに見えるだけの説明と、本文の記述から裏付けられる説明とを区別することが大切です。

確認ポイント

比較されている対象の間で、共通している前提と異なっている条件をそれぞれ本文から拾い出せているか
異なっている条件が、処理の流れのどの部分に影響し得るのかを本文の記述に沿って説明できるか
自分が考えた要因が、一般論だけに頼らず本文中の具体的な記述によって裏付けられているか

正解と解説を見る

解説

大量の時系列データを扱う節電支援システムを題材にした問題です。①索引の構成列の順序、②索引探索で読み込むページ数の見積りと、集計テーブル追加による改善、③CROSS JOIN・RANK・NTILE を使った問合せ、④縮小したテスト環境の妥当性と、性能テストで実測値が見積りと食い違った原因の分析が問われています。いずれも、本文中の RDBMS の仕様（索引探索の条件、ページ長、クラスタ率、LRU 方式のバッファ共有）を数値に当てはめて考えます。

問題の全体像

J社は、コントローラから分単位で送られてくる買電・発電・使用電力・機器ログを蓄積し、使用電力量表示画面（図1）や統計分析を提供するシステムを構築しています。データベースは20ノードのシェアードナッシング型クラスタで、機器ログ・買電・発電・使用電力の各テーブルは住居番号を分散キーにしてノードに分散配置します。出題趣旨によれば、この問題で問われるのは、物理データモデルの設計、適切な索引の設計と評価、テストの計画と実施、処理性能の基礎数値に基づく妥当性評価の4つです。設問1は索引と読込みページ数の見積り・改善、設問2は処理3・処理4の SQL、設問3は性能テストのデータ作成と、結果が見積りと食い違った原因の分析です。採点講評では、問1全体の正答率は低く、特に設問1(2)と設問3が低かったと述べられています。

設問1(1)

処理2の比較対象住居は「同じ地域」「同じ世帯区分」「同じ地域かつ同じ世帯区分」の3通りです。RDBMS の仕様(6)により、索引探索が選ばれるのは、等値条件の列が索引キーの全体、または先頭から連続する列に一致する場合だけです。一方、地域コードは住居テーブルの外部キーなので、方針(5)によってすでに地域コード単独の索引があります。そのため新しく定義する索引は、先頭を世帯区分、2番目を地域コードにすれば足ります。こうすると「世帯区分だけ」は先頭列で、「世帯区分と地域コード」は索引キー全体で、それぞれ索引の中で絞り込めます。公式解答例でも「世帯区分，地域コード」の順です。採点講評では、構成列の定義順を考慮しない解答が散見されたと指摘されています。順序まで含めて答える必要があります。

設問1(2)(①)

a・b・c：最小読込みページ数は、クラスタ率が最も高く、対象行が連続したページに詰まっている場合の値なので「探索行数÷ページ当たり平均行数」の切上げになります。最大読込みページ数は、クラスタ率が最も低く、1行ごとに別のページを読む場合の値なので、探索行数と一致します。公式解答例でも、a が探索行数、b がページ当たり平均行数、c が探索行数です。

d：使用電力テーブルの主キー索引は（住居番号，回路番号，年月日，時，分）です。照会では回路番号を指定しないため、索引探索に使える等値条件は先頭列の住居番号だけです。したがって、その住居の全期間の行をすべて探索します。探索行数は「1日500件×360日×3年＝540、000行」で、表5の54、000、000、000行÷100、000住居とも一致します。公式解答例の d も 540、000（行）です。同じ考え方で、表9の発電の探索行数43、200も、発電テーブルの住居当たり全行数（4、320、000、000÷100、000）になっています。

e：ページ当たり平均行数は 2、000×(1－0.1)÷20＝90行です。最小読込みページ数は 540、000÷90＝6、000 ページになります。

f：最大読込みページ数は探索行数と同じ 540、000 ページです。公式解答例も e＝6、000、f＝540、000 です。この結果、平均読込みページ数は (6、000＋540、000)×50％＝273、000 ページとなり、対策が必要だと判断されます。

設問1(2)(②)

図1のグラフは、日ごとの買電・発電・使用電力の電力量を表示します。追加するテーブルは、分単位の明細を日単位に集計したものにすれば、照会で読む行数を大幅に減らせます。設問の指示どおり、買電・発電・使用電力を「電力区分」列で区別すれば、1つのテーブルにまとめられます。公式解答例は「日別計（住居番号，年月日，電力区分，電力量）」で、主キーは住居番号・年月日・電力区分（実線の下線）です。住居番号を先頭にしているので、指定住居の等値条件で索引探索ができます。回路番号は住居単位の集計に不要なため含めていません。前日までの集計行は夜間バッチで追加するという本文の対策とも整合します。

設問1(2)(③)

日別計の平均行長は、住居番号 INTEGER 4バイト＋年月日 DATE 4バイト＋電力区分 CHAR(1) 1バイト＋電力量 DECIMAL(10、3) 6バイト＝15バイトです（すべて NOT NULL の想定でフラグなし）。ページ当たり平均行数は 2、000×0.9÷15＝120行になります。

照会は2020年3月25日に2019年4月を指定しているので、当日分は含まれず、すべて日別計から読みます。探索行数は次の合計です。

・当月（2019年4月、30日分）の買電・発電・使用電力：30日×3区分＝90行

・比較対象（2018年4月）の使用電力：30日×1区分＝30行

合計は120行です（1年360日の前提で1か月＝30日）。

したがって、最小読込みページ数は 120÷120＝1、最大読込みページ数は探索行数と同じ120になります。公式解答例も最小1、最大120です。平均読込みページ数は (1＋120)×50％＝60.5 を切り上げて61となり、目標の100以下を満たすことも確認できます。

設問2(1)(g)

表10の W1 の③に「①と②の結果の直積」とあります。直積を求める結合は CROSS JOIN なので、g には CROSS が入ります。距離の条件は WHERE 句で指定しています。公式解答例も CROSS です。

設問2(1)(h)

W2 のランクは「距離を昇順に並べた順位」です。RANK() の ORDER BY には W1 で求めた列の「距離」を指定します。対象は指定された1住居・1時点だけなので、PARTITION BY は不要です。公式解答例も「距離」です。

設問2(1)(i)

W3 では、ランクが2以下の地点の標準発電量の平均を「平均標準発電量」として求めます。最後の SELECT で A.平均標準発電量と参照しているので、別名が必要です。公式解答例は「AVG(標準発電量) AS 平均標準発電量」です。

設問2(1)(j)

j は W3 と W4 の両方で使われています。どちらも「住居番号，年月日，時ごと」の集約（W3 は平均、W4 は合計）なので、集約関数と並べて選択している列でグループ化します。公式解答例は「GROUP BY 住居番号，年月日，時」です。

設問2(1)(k)

発電テーブルには、回路番号ごと・分ごとの行が1時間に複数あります。W4 の時間発電量は「住居番号，年月日，時ごとの発電量の合計」なので、SUM で集計し、最後の SELECT で参照する別名を付けます。公式解答例は「SUM(発電量) AS 時間発電量」です。

設問2(2)(l)

W1 は地域コードごとに集計しますが、使用電力テーブルには地域コードがありません。そのため、①で選択した使用電力の行を住居テーブルと住居番号で結合し、住居の地域コードを得る必要があります。図4でも B.地域コードを参照しています。公式解答例は「①の結果と住居を住居番号で内結合」です。

設問2(2)(m)

図4の W3 は「AVG(合計使用電力量) AS 平均使用電力量 … GROUP BY 地域コード，階級番号」です。これを表11の「項目名＝[演算の概要]」の形式で書きます。公式解答例は「平均使用電力量＝[地域コード，階級番号ごとの合計使用電力量の平均]」です。

設問2(2)(n)

最後の問合せでは、W3 の結果全体に地域名を付けて出力します。W3 に対する選択条件はありません。表10の最終行「W3の全行を選択」と同じ書き方で、公式解答例も「W3の全行を選択」です。

設問2(2)(o)

出力項目の地域名は地域テーブルにあるため、①の結果（W3）と地域テーブルを地域コードで結合します。公式解答例は「①の結果と地域を地域コードで内結合」です。

設問2(2)(p)

処理4は、地域ごとに合計使用電力量の大きい方から順序付けし、5階級に分けます。表4の NTILE の構文に当てはめると、区画化列は PARTITION BY 地域コード、階級化列は ORDER BY 合計使用電力量 DESC（大きい順なので降順）です。公式解答例は「PARTITION BY 地域コード ORDER BY 合計使用電力量 DESC」です。採点講評では、ウィンドウ関数の構文を正しく理解していない解答が散見されたと指摘されています。DESC の付け忘れや句の順序に注意してください。

設問3(1)(①)

着目点は、分散テーブルの分散キーが住居番号であることです。本番は住居100、000件を20ノードに分散するので、1ノード当たり約5、000住居分です。テストは10、000件を2ノードに分散するので、同じく1ノード当たり約5、000住居分になります。DBサーバの仕様も本番と同じで、クラスタ全体の TPS はノード数に比例することが確認済みです。したがって、1ノード分の性能から本番の性能を推測できます。公式解答例の要旨は「分散するテーブルは住居番号が分散キーであり、ノード当たりの行数とDBサーバの仕様が同じだから」です。50字以内では「分散キー＝住居番号」「ノード当たり行数が同じ」「サーバ仕様が同じ」を入れるのが基本です。

設問3(1)(②)

本番では地域1、000件・住居100、000件なので、1地域当たり平均100住居です。テストでは住居を10分の1にしているため、何も考えずに地域コードを割り振ると1地域当たり約10住居となります。その結果、地域単位で比較・集計する処理2や処理4の対象行数が本番と大きく変わってしまいます。公式解答例には「地域当たりの住居数が実データに近い比率で分散するように値を設定する」と「1地域当たりの住居数が100となるように値を設定する」の2つが箇条書きで併記されています。両方を書く必要があるのか、どちらか一方でよいのかは公式資料からは判断できないため、ここでは断定しません。両者に共通するのは、地域当たりの住居数を本番相当にし、性能テストの結果を本番に近づけるという観点です。採点講評では、性能テストの実施を考慮した解答が期待されていたのに、システム機能の観点での解答が散見されたと述べられています。参照整合性など機能面ではなく、性能に影響するデータ分布の観点で具体的に書くことが大切です。

設問3(2)(差異1)

表13では、機器ログを「住居番号，年月日順に」追加しています。処理5は住居番号と年月日を指定して機器ログを読むので、主キー索引の順序と行の物理的な並びがほぼ一致し（クラスタ率が高い）、少ないページで必要な行を読めます。そのためバッファヒット率が上がり、応答時間が見積りを大きく下回りました。本番では多数の住居のログが時刻順に混ざって追加されるため、このような並びにはなりません。公式解答例の要旨は「“機器ログ”テーブルは、住居番号、年月日順に行を追加したことで、クラスタ率が高くなったこと」です。採点講評では、バッファヒット率に言及しただけの解答が多かったと指摘されています。原因として、データの投入順とクラスタ率を書くことが求められます。

設問3(2)(差異2)

図5で①と②の時間帯を見ると、処理3と処理2が同時に実行されています。処理2は1トランザクション当たり5、000ページを読み、バッファヒット率は40％と低い処理です。これを50～100の多重度で実行すると、バッファの480、000ページ分を大きく圧迫します。同じページ長のテーブルは1つのバッファを共有し、置換えは LRU 方式なので、処理3が参照するページが追い出され、処理3のヒット率が見積りの90％を下回ったと考えられます。公式解答例の要旨は「処理2の実行によって、同時に実行される処理3が参照するページがバッファから追い出されたこと」です。採点講評では、処理が並走している点だけに言及した解答が目立ったと指摘されています。処理2の特性（大量ページの読込み）と、RDBMS の仕組み（共有バッファ・LRU による追い出し）まで結び付けて書くことが求められます。

学習のポイント

特に次の3点を押さえてください。(1) 索引探索に使える条件は、索引キーの先頭から連続する列に対する等値比較に限られること。(2) 読込みページ数は、最小が「探索行数÷ページ当たり平均行数」、最大が探索行数に等しいこと。(3) データの投入順で決まるクラスタ率や、同じバッファを共有する処理どうしの追い出しによって、実測値が見積りからずれること。

出典：独立行政法人情報処理推進機構（IPA）令和2年度10月データベーススペシャリスト試験午後Ⅱ 問1（公式資料：問題冊子（PDF）／解答例／採点講評）

令和2年度10月 データベーススペシャリスト 午後Ⅱ 問1

問題