「情報処理試験まとめ/データベーススペシャリスト試験の勉強法まとめ/午後1&2対策」の編集履歴（バックアップ）一覧に戻る

情報処理試験まとめ/データベーススペシャリスト試験の勉強法まとめ/午後1&2対策 - (2015/10/29 (木) 19:42:38) のソース

&topicpath()&aname(top)
#divclass(pageTitle){データベーススペシャリスト試験　解答テクニック}
**目次
#contents_line(level=3,sep=　/　)
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
**はじめに
***はじめに
　モバイル版が表示されてしまう人は画面最下部のPC版はこちらをクリックで見やすいページが表示されます。
　主に問題を解答するためのパターンや定石、よくある考え方などをまとめてみました。
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
**関連ページ
#ls3(情報処理試験まとめ)
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
**参考書
#divclass(h5){参考書の選び方、お勧め参考書}
　データベーススペシャリストの参考書は大きくわけて学習用とテクニック習得用にわかれる。見分け方は、データベースの基本から解説されている参考書と、主に試験のテクニックを解説している参考書とで区別ができる。
　データベースに関する知識が無い人は学習用とテクニック解説用の参考書の両方を購入し、すでに一定のデータベースに関する知識がある人はテクニック解説用の参考書のみを購入するのがおすすめ。
#divclass(h5){2016年学習用参考書}
　データベースの仕組みなども解説している参考書。データベースの開発経験の無い人、データベースについての知識が無い人は購入しよう。
#html2()
{
<iframe src="http://rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=matowiki-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=B016W1WKWQ" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>
}
#html2()
{
<iframe src="http://rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=matowiki-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=B0141XEUNO" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>
}
#html2()
{
<iframe src="http://rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=matowiki-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=4813262112" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>
}
#divclass(h5){2016年テクニック学習用参考書（特におすすめ、絶対に購入すべし）}
　主に解答方法などのテクニックを解説している参考書。午後1、午後2に関するテクニックが満載で過去問に対する説明もとても丁寧に行われている。過去問に対してかなり詳しく解説しているので、問題集も購入する必要はなくこの一冊で完結する。購入して決して損をしない一冊。
&html(<iframe src="http://rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=matowiki-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=4798143219" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>)
**解答時のテクニック 午後1
***時間配分を守る
　午後1はとにかく時間との勝負になる。最初のほうで少し戸惑って時間が取られると、それでパニックになってしまい、その後が全然駄目になってしまうことがあるので、とにかく慎重に進めていく事が大事だ。 
　テクニックとしては、設問ごとの時間配分をしておくこと。例えば、午後1なら設問1への解答時間を40分と決めておく。そして40分経ったらもう強制的に次の設問に進むようにしよう。できれば同じ設問中でも時間を設定し、一つの問に対して13分というように設定しておく。それを過ぎたら途中でも次の問題に進むようにしよう。 
　できなかった問題は後からの残り時間で見直せばいいし、時間がなかったらそれは仕方がないと思って諦めよう。とにかく一つの問題に集中してしまうと点数が稼げなくなってしまうから、時間配分を決めてある程度割り切ってどんどん先に進むのも重要だ。
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
**解答時のテクニック 午後2
***設問の構成を最初に調べる
　問題の構成は、おおむね最初に企業の業種や組織、業務プロセス、システムのテーブル構造を文章で説明し、その後に業務の改善要望を記述するパターンが多い。ほとんどの問題で「現状の業務やシステムの説明→新しい要望の説明」となっていて区切りがつけられている。設問も現状の業務の開設と改善要望の問いは分けられているので、現状の業務の説明まで読んだらその部分をまず解答して現状のテーブル構造が確定してしまおう。それから新しい要望に取りかかったほうが効率がいい。
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
***問題文を読みながら会社の仕組み、ビジネスロジックなどを簡単な図でまとめる
　午後1にも午後2にも言えることだが、その会社の組織やビジネスロジックを理解することはとても重要だ。そのため問題文を読みながらその組織の組織図、伝票の作られ方、商品の配送方法などを簡単にメモしながら問題文を読んでいくようにすると、すんなり組織を覚えてることができる。
　例えば、「本社があり、商圏をいくつかの地域に分け、そこに複数の支社がある。配送センターは地域に一つだけある。営業担当は同じ地域の複数の支社に所属することがある。」みたいな記述がある場合には、以下のように簡単な図を作ってまとめる。こうすると頭の中で簡単に整理できる。
#center(){&ref(20150308_001.jpg)}
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
***問題文とER図、関係スキーマなどの図表を行き来して確認する
　データベーススペシャリストの午後2問題は業務プロセスを文章で説明し、そしてテーブル構造を答えさせようとしている。逆に言えばテーブル構造を文章で説明していることになる。
　説明文はおおむねテーブルごとに、それぞれのテーブルについて解説している。なので、もし問題文に関係スキーマ（テーブル）、概念データモデル（ER図）が図や表として記述されているようなら、問題文とそれらの図や表をページをめくり行き来し、問題文中のテーブルの説明と図や表中に記述されているテーブルを比較し記述内容を確認するようにする。 
　例えば「企業には複数の支社があり支社コードで識別される」などという説明があれば、おそらく支社テーブルが存在し支社コードが主キーとなっているであろうことがわかる。そしたら関係スキーマやER図を調べて支社テーブルを探して、テーブルがあることの確認と、支社コードが候補キーまたし主キーとして存在していることを確認する。もし支社テーブルに該当するテーブルがなかったり、そのテーブルに支社コード属性がない場合、そのテーブルや属性を答えさせる設問が出る可能性が高い。
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
***問題文へのマーキング
　上記のように問題文と関係スキーマやER図を行き来し、一つ一つ確認していくとおかしな記述があったり、該当するテーブルがなかったりする場合がある。 
　テーブルがない場合はひょっとしたら虫食い問題になっている可能性があるので、その部分は非常に重要だ。とりあえず疑問に思いながらも問題文を読み進むわけだが、読み進めるうちに忘れてしまう可能性があるので疑問を感じた部分に下線を引いて欄外に「はてなマーク」を書いておこう。可能なら欄外に「支社テーブルがあるはず？」「主キーとして支社コードがない？」などとメモしておく。こうすると、あとで簡単に見直すことができる。 
　また読み進めるとロジック的におかしいなと思われる部分を見つけることもある。例えば将来的に商品の値段を変更する可能性があるのに、その商品の値段の履歴を残すようなテーブル構造になっていないような場合である。これだと商品の値段を変更すると過去の売上げの値段すべてが変更されて金額がおかしくなってしまう。こういうものを見かけたときも下線を引いて「価格変更履歴テーブルは？」などと記述しておく。
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
**解答パターン　午後1＆午後2
***問題文を読んでいて疑問に思うパターン
　問題文を読んでいると、これはどうするの？こうでなければおかしいと疑問に感じることがある。その多くは下記のパターンのいずれかに当てはまることが多いので、これらのパターンを覚えておくと何を答えさせようとしているかを理解しやすくなる。
#divclass(h5){問題文に記述されている属性やテーブルがない}
　よくあるパターンのNo1。問題文とER図や関係スキーマを確認し、該当するテーブルや属性があるかどうかを探す。無ければ虫食い問題になっている可能性が高い。
#divclass(h5){履歴が残せない}
　例えば商品マスタに商品金額が記述されているが、売上げ伝票（売上げ明細）に個別の商品金額を記録できないようなパターン。この場合、商品マスタの金額を変更してしまうと過去に売り上げた伝票の商品金額もすべて変更されてしまうことになるので問題になる。売上げ時の金額を残せないというのは問題にされる可能性がある。
#divclass(h5){正規化されていない}
　正規化されていないと同じ情報を重複して登録してしまう可能性がでてくる。例えば商品を販売するたびに売上げ伝票に顧客の名前、住所、電話番号を登録するような場合だ。この場合、顧客の電話番号が変わったりしたとき、過去の売上げ時に入力された顧客情報と整合性がとれなくなるので問題になる。
#divclass(h5){属性の変更を考慮していない}
　営業部員の売上げの成績は保存されるが、売上げ時の営業部員が所属していた支社の情報が記録されないパターン。例えば従業員マスタで営業部員と所属する支社の紐付けがされているとする。そうすれば従業員と支社の紐付けがされているので、営業部員の売上げ成績から支社別の売上げ成績も導きだすことができる。
　しかし会社には異動が付きもの。もし従業員マスタで従業員が異動し現在の所属先の支社に変更されてしまったら、その従業員の過去の売上げも新しい支社の売上げとして計算されてしまうことになる。このように属性が変更されることを考慮しないと、あとから集計したときに値が変化してしまうことがあるので注意が必要である。
　従業員と支社の関係以外にも、商品と商品価格、商品と商品の仕入れ先など、その時々によって変更する可能性があるものをマスタ的に登録していると不整合が生じる可能性があるので、そのあたりを見たときに疑問を感じてチェックしておくことが重要。
#divclass(h5){わざと冗長に記録させるパターン}
　集計などを早く行うために売上げ伝票に売上げ詳細の合計金額などを記録させるパターン。通常、売上げ伝票ごとの金額は売上げ詳細テーブルに記載されている商品金額×販売数の合計を計算して求めるが、詳細が多くなると計算に時間がかかってしまう場合がある。この場合、売上伝票に合計金額を保存しておけば売上げ詳細テーブルの演算を行わなくて済むので計算が早く済む。しかしご発注などのため売上げ詳細テーブルの金額や商品販売数が修正されると合計金額が変わってしまう。そうなると売上げ伝票テーブルに記録した合計金額と数字のズレがでてしまうが、これを考慮したロジックになっていないと問題が発生してしまう。問題文中にそれら整合性をどうするかの説明がないと疑問に感じなければならないパターンだ。
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
***テーブルの新規作成パターン
　午後2の問題を解いていると、ビジネスロジックの改良に伴い、既存のテーブルに新たにテーブルを追加して設計を変更させようとする設問がある。テーブルはだいたい以下のような理由で新たに追加される可能性が高い。このパターンを理解しておくと何を答えさせようとしている問題なのか想像しやすくなるので覚えておくと良い。
#divclass(h5){他のデータを束ねる}
　新たに他のデータをまとめるためのテーブルを新規作成するパターン。例えばカラオケボックスで、通常は一部屋に対して1枚の売上伝票で別々に精算しなければならないものを、グループで複数の部屋を借りたときにまとめて支払いたいというようなパターンだ。飲食店で席が別々になってしまったグループの複数の伝票をまとめて支払いたいなどというようなパターンにも当てはまる。
　この場合には、例えば下記の画像のように新しく「まとめテーブル」などを新規作成し、その「まとめ番号」などを売上げ伝票テーブルに新たに作成したまとめ番号属性に保存することで実現する。こうすると、これまで客室ごとに一枚の伝票だったものが一つのまとめ番号で紐付けされるので複数の部屋でもまとめて支払いが可能になる。
#center(){&ref(20150310_001.jpg)}
#divclass(h5){連関テーブル}
　業務プロセスの変更で、テーブルのリレーションシップが1対多から、多対多になってしまいそれを表現するために連関テーブルを新規作成するパターン。例えば支社と従業員の関係で、これまで従業員は一つの支社にしか所属していなかったのに、業務プロセス等の変更で従業員が複数の支社に所属するように変更され、支社－従業員が1対多の関係だったものが多対多になってしまったパターンなどが該当する。
　この場合、多対多の関係を表現するために連関テーフルを新規で作成することで対応する。
#divclass(h5){マスタテーブルとして追加する}
　業務プロセスの変更で、新たなマスタテーブルを追加しなければならなくなるパターン。例えば飲食店でこれまで「商品」だけだったものを、料理、ドリンク、セット定食などというように商品カテゴリで商品を分ける必要があり、商品区分マスタなどとして新たなテーブルを作成するパターンなどだ。
　商品区分マスタに区分コード、区分名などの属性を作成し、商品テーブルに新たに商品区分属性を作成して区分コードを保存することで対応する。
#divclass(h5){サブタイプの追加}
　業務プロセスの変更で、新たなサブタイプを作成するパターン。例えば食料品メーカで使用する野菜に関して、これまで通常の野菜と有機野菜のみの区別だったものに、輸入野菜という新たな分類となる野菜を使用するために、輸入野菜を管理する新たな属性を追加する必要になるパターンなどだ。
　この他にも、製造業で自社部品だけでなく他社製造部品も利用するようになり、部品を自社と他社で別の属性で管理する必要になったというパターンや、飲食店で同じレシピの料理だけどセット商品として提供する場合と単品で提供する場合によって異なる属性で管理したいというパターンなどがある。
　主に「同じ商品」なんだけど、製造元が異なったり、提供先や提供方法が異なるため、その場合だけ別々に管理したいというような場合に新たなサブタイプとしてテーブルを新規追加することが必要になるパターンである。
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
***テーブルへのフィールド新規追加パターン
　午後2の問題を解いていると、ビジネスロジックの改良に伴い、既存のテーブルに新たにフィールドを追加して設計を変更させようとする設問がある。フィールドはだいたい以下のような理由で新たに追加される可能性が高い。このパターンを理解しておくと何を答えさせようとしている問題なのか想像しやすくなるので覚えておくと良い。
#divclass(h5){行の属性を表現するための属性の追加}
　商品マスタなどで、その商品に関する属性を追加させるパターン。例えば飲食店で提供する料理を飲み物と料理に区別して売上げを集計したいとか、ホテルの部屋を喫煙室と禁煙室に区別して予約を受け付けたいというパターンだ。
　この場合、料理マスタに「商品区分」などの属性を追加したり、ホテルの部屋を禁煙と喫煙に区別するために部屋マスタに「喫煙区分」を追加するなどが該当する。
#divclass(h5){集計行を追加するための属性追加}
　部品マスタなどで、その部品の在庫数を保存する属性を追加させるパターン。例えば製造メーカでこれまでは半製品の在庫を記録していなかったが業務効率改善のために半製品の在庫数を保存する必要がでてきたなどのパターンだ。
　この場合、半製品マスタに「在庫数」などの属性を追加するなどが該当する。
#divclass(h5){履歴を残すための属性追加}
　商品マスタなどで、その商品の価格の履歴を保存する属性を追加させるパターン。例えば製造メーカでこれまで商品の値段は同じであったがこれからは頻繁に価格を反映させたいので履歴を残しておく必要があるとか、飲食店で一定期間だけ料理を特別価格として安く販売したいので過去の販売金額の履歴を残したいとか、従業員の過去の所属部署を履歴として残しておきたいというパターンだ。
　この場合、商品マスタに「販売開始日」などの属性を追加したり、料理マスタに「販売開始日」などの属性を追加したり、社員マスタに「配属日」などの属性を追加することなどが該当する。
　このパターンは、これまで普通だったただの縦横の表に、突然時系列という時間の流れという概念を取り入れなければならないので発想の転換が必要になり難易度が高い。
　このパターンでは例えば商品価格では、商品の価格を変更するたびに販売開始日を設定して新たに行を作ることになる。従って、例えば｛商品コード、販売開始日｝が候補キーになる。販売開始日を設定することで、例えば下記の例だと商品コード0001の製品は、2015年01月01日から2015年01月31日まで300円で販売していたことがわかるということになる。
　またこのパターンでは、将来に対する価格変更の予約のようなことも可能になる。例えば、2015年2月1日から新価格で販売することを事前登録しておくということも可能。

#center(){&ref(20150309_001.jpg)}
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
***正規化に関する解答パターン
　詳しくは情報処理教科書に記述されているので、その説明を読んで理解することが必要。以下は暗記用のチェックシート代わりに。
#divclass(h5){第一正規形でない理由（正規化されていない理由）}
-属性○○は属性△△の集合であり単一値ではないため
-属性○○が繰り返し項目であり単一値ではないため
#divclass(h5){第一正規形の理由}
-すべての属性が単一値で、候補キーＡ、Ｂの一部であるＢに非キー属性のＣが部分関数従属するため
-非キー属性であるＣが候補キーの一部であるＢに関数従属し、候補キーに完全関数従属していないから
-非キー属性であるＣが候補キーの部分集合｛Ａ、Ｂ｝に関数従属し、候補キーに完全関数従属していないから
#divclass(h5){第二正規形の理由}
-すべての属性が単一値で、候補キーからの部分関数従属がなく、推移的関数従属性Ａ→Ｂ→Ｃがあるため
#divclass(h5){第三正規形の理由}
-すべての属性が単一値で、候補キーからの部分関数従属がなく、候補キーからの推移的関数従属性もないため
#divclass(h5){ボイスコッド正規形の理由}
-すべての属性が単一値で、すべての関数従属性が、自明であるか、候補キーのみを決定項として与えられている
#divclass(h5){第四正規形の理由}
-すべての属性が単一値で、すべての多値従属性が、自明であるか、候補キーのみを決定項として与えられている
#divclass(h5){第五正規形の理由}
-すべての属性が単一値で、すべての結合従属性が、自明であるか、候補キーのみを決定項として与えられている
#divclass(h5){正規化されていないと発生する可能性のある問題}
-○○（例：商品）を事前にマスタとして登録できない
-属性○○が冗長になる
-属性○○を重複して登録するので不整合が生じる
-属性○○が冗長であるため、これらを同時に修正しないと整合性が失われる
-属性○○の情報が特定の一行にしか存在しない場合、その行を削除するとその属性の情報が永遠に失われる
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
***結合に関する解答パターン
#divclass(h5){集計時に外部結合する理由}
-すべての○○（例：店舗）に対して△△（例：売上げ）が存在するとは限らないが、すべての○○ごとに集計して結果を出力するから
**コメント
#comment()
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
----
#right(){&lastmod()&aname(bottom)}
#right(){&trackback()}