データベーススペシャリスト試験午後1午後2対策

勉強テクニック 午後1&午後2
選択問題で選択する分野を固定する
 データベーススペシャリスト試験は出題分野が固定されていることが多い。そのため解答する問題を固定してしまうと過去問演習の時間を短縮させることができる。問題は概ね以下のように出題されるので、時間がない人や、苦手な分野がある人は、解答する問題を固定してしまうことも検討してみよう。
午後1編
 午後1は3問中2問の選択形式だ。これまでは問1と問2が概念設計と論理設計がメインで、問3は性能設計やデータベース運用などがメインだった。しかし、2014年からここ数年ほどクエリの比重が増すとともに問題の傾向もやや変化している。
問1、問2
 これまで問1は基礎理論、問2はデータベース設計に関する問題だったが、2014年からどちらもデータベース設計に関する出題のみになった。
 内容的はさほど変化がなく主に関係従属性、関係スキーマ、ER図、テーブル構造、正規化、候補キーなどを答えさせたりする問題が多いので、基本を抑えていれば特に問題ないだろう。
 ただ一つだけはっきりしているのはクエリに関する出題が増えていることだ。解答にクエリそのものを答えさせる問題もあったり、クエリを読めないと答えられない解答も増えている。
問3
 こちらは従来の物理設計、運用管理、チューニングなどの出題に加え、セキュリティに関する問題が加わることになった。
 また、こちらの問題でもクエリを理解していないと答えられない問題が多く出題されるようになっているのが特徴だ。さらにセキュリティに関する設問が入ってきているのも最近の傾向だろう。
まとめ
 これまでは「基礎理論+設計+性能設計または運用管理」というパターンだったが、2014年からは「設計×2問+性能設計または運用管理またはセキュリティ」というパターンに変化している。
 性能設計、運用管理、セキュリティに関しては苦手な人も多いと思われるため、もし苦手であればデータベース設計に関する問題を2問選択すると決めてしまうのもアリだろう。だが、データベース設計に関する問題が1問しか出題されない年もあったことから、そのようなリスクがあることだけは理解しておこう。
 またクエリを理解しないと解けない問題が増えていることから、相対的にクエリ学習の重要性は増していると考えられる。今後はクエリについても理解するような学習が必要になるだろう。出題されるクエリの問題は一般的なクエリの問題なので学習の難易度はさほど高くないはずだ。
午後2編
 午後2については以下のようになっている。
問1
 ER図や関係スキーマも問われるが、それだけでなく、ビジネスロジックを理解した上でデータの更新手順を問う問題や、データ抽出方法を問う問題、検索時の最適なクエリを記述させる問題、物理設計や性能設計に関する内容も出題される。
 またここ数年、問1はER図や関係スキーマを問われることのない傾向となっている。具体的には、問題文の最初にER図、関係スキーマをすべて提示した上で各種問題が出題されるようになっている。これは論理設計までを提示した上で物理設計、運用、チューニング、クエリに関する問題を出題する意図があるからなのだろう。今後もこれに近い傾向が続くものと思われる。
問2
 ビジネスプロセスを理解し、概念データモデルやテーブル設計をするデータモデリングを問われる問題で、関係スキーマやER図を答えさせる問題だ。こちらはモデリングだけで物理設計に関するような問題は出題されない。これは最近も例年のパターンと変化がない。
まとめ
 どちらを選択するかは考え方次第だが、モデリングが得意なら問2を、苦手なら問1を選択するのがいいだろう。どちらを選択するか決めてしまえば、他方は学習しなくてもよくなるのでかなりの時短になるので、時間がない人は事前に問題文を読んでみてどちらかを選択するか固定してしまうといいだろう。
 業務経験の無い人の場合、一般的にはモデリングのほうが得意であろうことから、問2を選択すると固定してしまえば、過去問演習の時間も短くなると思うので検討してみるといいと思う。
クエリの学習は必要か?
 かつてはそれほどでもなかったが、最近はSQL(クエリ)やそれに近い内容を答えさせる問題が頻出化している。応用情報のデータベース問題でもクエリを答えさせる問題が毎年でるようになっているので、そのような傾向なのだろう。そのためクエリを学習する重要性はかつてより高まっているということはいえると思う。
 また、ER図や関数従属性を表す図を眺めて理解するより、クエリを実際に記述したほうが、それぞれのテーブルがどのように組み合わさって表示させるのか理論的に理解しやすくなるためクエリを勉強することで、よりデータベースに関する理解が深まることは間違いない。
 従って可能ならばクエリを学習することが望ましい。簡単な関数を思い浮かべる程度には学習しておこう。
 しかし、クエリを勉強するには時間がかかる上に初心者の人にとっては難解であり時間もかかることから、もし学習する時間がないと考えるのであればクエリの学習をパスするという選択肢もアリだ。クエリが記述できなくとも、なんとか60%以上は解答できると思われるので、自分の学習状況や残り時間などを考慮してクエリの学習をするかどうか検討しよう。もちろん業務でクエリを記述した経験のある人は、すでに知識は十分と思われるので学習する必要はないだろう。
出題される重要キーワードはほぼ決まっているので慣れが重要
 問題中には過去に何回も問われている問題がある。例えば、正規化、ER図の作成、候補キーを探す問題などである。これらはほとんど例外なく出題されるような問題なので、これを学習することで合格率はかなり上昇すると考えられる。具体的にどのような問題が出題されるかは、情報処理教科書 データベーススペシャリストに記述されているので、午後1を始める前には午後1に関する解答テクニック集を、午後2の前には午後2のテクニック集を読んで理解してから始めるようにしよう。はじめは難しいかもしれないが、その理屈や理論みたいなのを理解してしまえば安定的な得点源となるため、確実にものにするようにしよう。
独特の言い回しを意識する
 このあたりも情報処理教科書に記述されているので、具体的に学んで学習していこう。例えば「支社コードは支社によって一意で決まる」と書いてあれば支社テーブルにある支社コードは支社テーブルの候補キーになることを意味する。
 次に「社員コードは支社ごとに一意に決まる」と書いてあるとする。そうすると、社員テーブルは、支社コード、社員コードが候補キーになるのではないかと推測できる。
 このように「候補キー」であることを示す文章はほぼ定型的に記述されているので、それを学習することが重要だ。
独特の言い回しを暗記する
 言い回しにはもう一つある。それは解答時の言い回しだ。
 例えば「第三正規形である理由を述べよ」みたいな問題がよくあるが、解答時の言い回しはほとんど定型で使い回せるものだ。第三正規形ならば「全ての属性が単一値で、候補キーからの部分関数従属がなく候補キーからの推移的関数従属性もないから」などが定型文にあたる。第一正規形~ボイスコッド正規形まで、すべてに定型文があるが、これらは情報処理教科書に記載されているので暗記すること。
 また正規化していないことで発生する問題についても定型文が存在する。例えば第二正規形で終わっているテーブルは「属性○○が重複して登録される」「事前に属性○○を登録しておくことができない」「属性○○の更新時に整合性がとれなくなる」などだ。これも午後1では頻出ワードになるので覚えておくこと。
概念データモデル
 概念データモデルで必須なのはリレーションシップの「矢印」の記述だ。よく出題される内容なのでこれは絶対に間違えないで記述できるようにしておくこと。一般的にはリレーションシップは1対多の設計になっていることがほとんどなのでほとんど片側矢印で対応できると考えていい。矢印の向きはテーブルに主キーを外部キーとして取り込んでいるかどうかで判別できるので、必ず矢印の方向も間違えずに記述できるようにしておこう。
 ただし、まれに1対1のリレーションシップが存在することがあるので、そのあたりだけ気をつけるようにしよう。
サブタイプ
 サブタイプも必ず理解しなければ概念の一つ。結構出題されるのでこれも理解できるようにしておく。
 サブタイプは基本的にマスタ系に使われることが多い。例えば商品があって自社製造商品か仕入れた商品かなどの違いで一部属性が異なるような場合である。
 同じ商品やサービスなのに属性の異なる商品などの説明があるとサブタイプになっている可能性が高いので検討してみよう。
実際にデータベースをインストールして利用してみる
 主に概念データモデリング系の設問のみ選択すればSQLをしらなくても合格できるかもしれないが、やはり確度を高めるためにSQLにある程度、慣れておくことは重要だと思う。最近はSQLに関する出題も多くなっており、計算に関するロジックなどの知識も必要になるケースがあることから勉強して損はない。
印字する
 午後1と午後2の学習をするにあたって、必ず問題文と解答用紙を印刷しておくようにしよう。この試験の場合、パソコンでPDFを閲覧し解答するのは非常に難しい。なぜなら時間がほんとうに足りないからだ。自分の解答ペースで時間内に間に合うかどうかはPDFではわからない(たぶん間に合わないと思う)。なので印刷し、時計を用意して計測して時間内に解答できるかどうか確かめる必要がある。
 なお、ネットで公開されている解答用紙の一部には、多少問題がある解答用紙が公開されている。答えは4種類なのに2マスしか回答欄がないものが公開されていたりするので、そのあたりだけは気をつけて欲しい。
復習方法
 情報処理教科書の解説を読み、間違った設問に対してなんで間違ってしまったのかを分析するようにしよう。情報処理教科書には、解答を導き出す方法が記述されているので、もういちど最初から解答するようなイメージで問題文と解説を見比べて、自分はなぜその問題文のヒントに気がつかなかったのか、なぜそのような手法などに気がつかなかったのか等を学んでいくようにしよう。
 特にこのwikiで記述している解答パターンはかなり役立つと思うので理解して暗記しておいて欲しい。
あると便利な文房具
シャープペン
 シャープペンシルは製図用のシャープペンと、好みのシャープペンの2種類をもっていくことが望ましい。またシャープペンシルの芯もBとHBなどというように二種類持っていったほうがいいと思う。
 シャープペンは0.5mmで問題ない。最近のシャープペンは自動繰り出し式だったり、回転式だったりして定規で線を引くのが苦手な製品も多い。製図用のシャープペンはペン先で数mm飛び出しており定規で線を引くのがしやすい。またIPAの試験は午前と午後で紙質がかなり違うので、同じシャープペンの芯だと堅すぎたり柔らかすぎたり好みに合わないことがある。そのため、堅さの違う芯を2種類もっていくと対処がしやすい。
テンプレート定規
 テンプレート定規とは、簡単に四角形や円を記述できる定規の総称だ。文房具屋などで販売されている。
 この定規のメリットは、簡単に直角や四角形を描けることだ。例えば概念データモデリングなどで線を引くことがあるが、このとき直角に曲がる線や四角形を書かなければならないことがある。普通の定規だと上下左右の線を4回定規を動かし記述する必要があるが、四角形を書けるテンプレート定規だと、左上の角、右下の角のように2回動かすだけ四角形を記述できるので非常に楽だ。
 またテンプレート定規は薄いものなら、消したい場所の上に定規の穴をあてて、その上から消しゴムで消すことで特定範囲だけをまるごと消せるという使い方もできる。
ノック式消しゴム
 この試験では図形を記述することがあるので、ほんとうに少しだけ、細かな場所を消したくなる場合がある。例えば直線を少し長く書きすぎて、他の線と重なってしまったというような場合だ。このとき普通の消しゴムだと消える範囲が広すぎて、全体をけしてから再度消してしまった場所を上書きするなど面倒になってしまうことがある。
 そこで便利なのがノック式の消しゴムだ。これなら数mmの場所でもらくらく消せるので余分な場所を消してしまう心配がない。ただし、広い範囲をまとめて消すには不向きなので普通の消しゴムも必ず持っていくようにしよう。
解答テクニック 午後1
時間配分を守る
 午後1はとにかく時間との勝負になる。最初のほうで少し戸惑って時間が取られると、それでパニックになってしまい、その後がまったく回答できなくなってしまうことがあるので、とにかく慎重に進めていく事が大事だ。
 テクニックとしては、設問ごとの時間配分をしておくこと。例えば、午後1なら設問1への解答時間を40分と決めておく。そして40分経ったらもう強制的に次の設問に進むようにしよう。できれば同じ設問中でも時間を設定し、一つの問に対して13分というように設定しておく。それを過ぎたら途中でも次の問題に進むようにしよう。
 できなかった問題は後からの残り時間で見直せばいいし、時間がなかったらそれは仕方がないと思って諦めよう。とにかく一つの問題に時間をとられると点数が稼げなくなってしまうから、時間配分を決めてある程度割り切ってどんどん先に進むのも重要だ。
解答テクニック 午後2
設問の構成を最初に調べる
 問題の構成は、おおむね最初に企業の業種や組織、業務プロセス、システムのテーブル構造を文章で説明し、その後に業務の改善要望が記述されているパターンが多い。ほとんどの問題で「現状の業務やシステムの説明→新しい要望の説明」となっていて区切りがつけられている。設問も現状の業務の解説と改善要望は分けられているので、「現状の業務」の説明まで読んだらその部分をまず解答して現状のテーブル構造を確定してしまおう。それから新しい要望に取りかかったほうが効率がいい。
問題文を読みながら会社の仕組み、ビジネスロジックなどを簡単な図でまとめる
 午後1にも午後2にも言えることだが、その会社の組織やビジネスロジックを理解することはとても重要だ。そのため問題文を読みながらその組織の組織図、伝票の作られ方、商品の配送方法などを簡単にメモしながら問題文を読んでいくようにすると、すんなり組織を覚えてることができる。
 例えば、「本社があり、商圏をいくつかの地域に分け、そこに複数の支社がある。配送センターは地域に一つだけある。営業担当は同じ地域の複数の支社に所属することがある。」みたいな記述がある場合には、以下のように簡単な図を作ってまとめる。こうすると頭の中で簡単に整理できる。
DB_001.jpg
問題文とER図、関係スキーマなどの図表を見比べて確認する
 データベーススペシャリストの午後2問題は業務プロセスを文章で説明し、そしてテーブル構造を答えさせようとしている。逆に言えばテーブル構造を文章で説明していることになる。
 説明はおおむねテーブルごとに、それぞれのテーブルについて解説している。なので、もし問題文に関係スキーマ(テーブル)、概念データモデル(ER図)が図や表として記述されているようなら、問題文とそれらの図や表をページをめくり行き来し、問題文中のテーブルの説明と図や表中に記述されているテーブルを比較し記述内容を確認するようにする。
 例えば「企業には複数の支社があり支社コードで識別される」などという説明があれば、おそらく支社テーブルが存在し支社コードが主キーとなっているであろうことがわかる。そしたら関係スキーマやER図を調べて支社テーブルを探して、テーブルがあることの確認と、支社コードが候補キーまたし主キーとして存在していることを確認する。もし支社テーブルに該当するテーブルがなかったり、そのテーブルに支社コード属性がない場合、そのテーブルや属性を答えさせる設問が出る可能性が高い。
問題文へのマーキング
 上記のように問題文と関係スキーマやER図を行き来し、一つ一つ確認していくとおかしな記述があったり、該当するテーブルがなかったりする場合がある。
 テーブルがない場合はひょっとしたら虫食い問題になっている可能性があるので、その部分は非常に重要だ。とりあえず疑問に思いながらも問題文を読み進むわけだが、読み進めるうちに忘れてしまう可能性があるので疑問を感じた部分に下線を引いて欄外に「はてなマーク」を書いておこう。可能なら欄外に「支社テーブルがあるはず?」「主キーとして支社コードがない?」などとメモしておく。こうすると、あとで簡単に見直すことができる。
 また読み進めるとロジック的におかしいなと思われる部分を見つけることもある。例えば将来的に商品の値段を変更する可能性があるのに、その商品の値段の履歴を残すようなテーブル構造になっていないような場合である。これだと商品の値段を変更すると過去の売上げの値段すべてが変更されて金額がおかしくなってしまう。こういうものを見かけたときも下線を引いて「価格変更履歴テーブルは?」などと記述しておく。
解答テクニック 午後1&午後2
問題文を読んでいて疑問に思うパターン
 問題文を読んでいると、これはどうするの?こうでなければおかしいと疑問に感じることがある。その多くは下記のパターンのいずれかに当てはまることが多いので、これらのパターンを覚えておくと何を答えさせようとしているかを理解しやすくなる。
問題文に記述されている属性やテーブルがない
 よくあるパターンのNo1。問題文とER図や関係スキーマを確認し、該当するテーブルや属性があるかどうかを探す。無ければ虫食い問題になっている可能性が高い。
履歴が残せない
 例えば商品マスタに商品金額が記述されているが、売上げ伝票(売上げ明細)に個別の商品金額を記録できないようなパターン。この場合、商品マスタの金額を変更してしまうと過去に売り上げた伝票の商品金額もすべて変更されてしまうことになるので問題になる。売上げ時の金額を残せないというのは問題にされる可能性がある。
正規化されていない
 正規化されていないと同じ情報を重複して登録してしまう可能性がでてくる。例えば商品を販売するたびに売上げ伝票に顧客の名前、住所、電話番号を登録するような場合だ。この場合、顧客の電話番号が変わったりしたとき、過去の売上げ時に入力された顧客情報と整合性がとれなくなるので問題になる。
属性の変更を考慮していない
 営業部員の売上げの成績は保存されるが、売上げ時の営業部員が所属していた支社の情報が記録されないパターン。例えば従業員マスタで営業部員と所属する支社の紐付けがされているとする。そうすれば従業員と支社の紐付けがされているので、営業部員の売上げ成績から支社別の売上げ成績も導きだすことができる。
 しかし会社には異動が付きもの。もし従業員マスタで従業員が異動し現在の所属先の支社に変更されてしまったら、その従業員の過去の売上げも新しい支社の売上げとして計算されてしまうことになる。このように属性が変更されることを考慮しないと、あとから集計したときに値が変化してしまうことがあるので注意が必要である。
 従業員と支社の関係以外にも、商品と商品価格、商品と商品の仕入れ先など、その時々によって変更する可能性があるものをマスタ的に登録していると不整合が生じる可能性があるので、そのあたりを見たときに疑問を感じてチェックしておくことが重要。
わざと冗長に記録させるパターン
 集計などを早く行うために売上げ伝票に売上げ詳細の合計金額などを記録させるパターン。通常、売上げ伝票ごとの金額は売上げ詳細テーブルに記載されている商品金額×販売数の合計を計算して求めるが、詳細が多くなると計算に時間がかかってしまう場合がある。この場合、売上伝票に合計金額を保存しておけば売上げ詳細テーブルの演算を行わなくて済むので計算が早く済む。しかしご発注などのため売上げ詳細テーブルの金額や商品販売数が修正されると合計金額が変わってしまう。そうなると売上げ伝票テーブルに記録した合計金額と数字のズレがでてしまうが、これを考慮したロジックになっていないと問題が発生してしまう。問題文中にそれら整合性をどうするかの説明がないと疑問に感じなければならないパターンだ。
テーブルの新規作成パターン
 午後2の問題を解いていると、ビジネスロジックの改良に伴い、既存のテーブルに新たにテーブルを追加して設計を変更させようとする設問がある。テーブルはだいたい以下のような理由で新たに追加される可能性が高い。このパターンを理解しておくと何を答えさせようとしている問題なのか想像しやすくなるので覚えておくと良い。
他のデータを束ねる
 新たに他のデータをまとめるためのテーブルを新規作成するパターン。例えばカラオケボックスで、通常は一部屋に対して1枚の売上伝票で別々に精算しなければならないものを、グループで複数の部屋を借りたときにまとめて支払いたいというようなパターンだ。飲食店で席が別々になってしまったグループの複数の伝票をまとめて支払いたいなどというようなパターンにも当てはまる。
 この場合には、例えば下記の画像のように新しく「まとめテーブル」などを新規作成し、その「まとめ番号」などを売上げ伝票テーブルに新たに作成したまとめ番号属性に保存することで実現する。こうすると、これまで客室ごとに一枚の伝票だったものが一つのまとめ番号で紐付けされるので複数の部屋でもまとめて支払いが可能になる。
DB_002.jpg
連関テーブル
 業務プロセスの変更で、テーブルのリレーションシップが1対多から、多対多になってしまいそれを表現するために連関テーブルを新規作成するパターン。例えば支社と従業員の関係で、これまで従業員は一つの支社にしか所属していなかったのに、業務プロセス等の変更で従業員が複数の支社に所属するように変更され、支社-従業員が1対多の関係だったものが多対多になってしまったパターンなどが該当する。
 この場合、多対多の関係を表現するために連関テーフルを新規で作成することで対応する。
マスタテーブルとして追加する
 業務プロセスの変更で、新たなマスタテーブルを追加しなければならなくなるパターン。例えば飲食店でこれまで「商品」だけだったものを、料理、ドリンク、セット定食などというように商品カテゴリで商品を分ける必要があり、商品区分マスタなどとして新たなテーブルを作成するパターンなどだ。
 商品区分マスタに区分コード、区分名などの属性を作成し、商品テーブルに新たに商品区分属性を作成して区分コードを保存することで対応する。
サブタイプの追加
 業務プロセスの変更で、新たなサブタイプを作成するパターン。例えば食料品メーカで使用する野菜に関して、これまで通常の野菜と有機野菜のみの区別だったものに、輸入野菜という新たな分類となる野菜を使用するために、輸入野菜を管理する新たな属性を追加する必要になるパターンなどだ。
 この他にも、製造業で自社部品だけでなく他社製造部品も利用するようになり、部品を自社と他社で別の属性で管理する必要になったというパターンや、飲食店で同じレシピの料理だけどセット商品として提供する場合と単品で提供する場合によって異なる属性で管理したいというパターンなどがある。
 主に「同じ商品」なんだけど、製造元が異なったり、提供先や提供方法が異なるため、その場合だけ別々に管理したいというような場合に新たなサブタイプとしてテーブルを新規追加することが必要になるパターンである。
テーブルへのフィールド新規追加パターン
 午後2の問題を解いていると、ビジネスロジックの改良に伴い、既存のテーブルに新たにフィールドを追加して設計を変更させようとする設問がある。フィールドはだいたい以下のような理由で新たに追加される可能性が高い。このパターンを理解しておくと何を答えさせようとしている問題なのか想像しやすくなるので覚えておくと良い。
行の属性を表現するための属性の追加
 商品マスタなどで、その商品に関する属性を追加させるパターン。例えば飲食店で提供する料理を飲み物と料理に区別して売上げを集計したいとか、ホテルの部屋を喫煙室と禁煙室に区別して予約を受け付けたいというパターンだ。
 この場合、料理マスタに「商品区分」などの属性を追加したり、ホテルの部屋を禁煙と喫煙に区別するために部屋マスタに「喫煙区分」を追加するなどが該当する。
集計行を追加するための属性追加
 部品マスタなどで、その部品の在庫数を保存する属性を追加させるパターン。例えば製造メーカでこれまでは半製品の在庫を記録していなかったが業務効率改善のために半製品の在庫数を保存する必要がでてきたなどのパターンだ。
 この場合、半製品マスタに「在庫数」などの属性を追加するなどが該当する。
履歴を残すための属性追加
 商品マスタなどで、その商品の価格の履歴を保存する属性を追加させるパターン。例えば製造メーカでこれまで商品の値段は同じであったがこれからは頻繁に価格を反映させたいので履歴を残しておく必要があるとか、飲食店で一定期間だけ料理を特別価格として安く販売したいので過去の販売金額の履歴を残したいとか、従業員の過去の所属部署を履歴として残しておきたいというパターンだ。
 この場合、商品マスタに「販売開始日」などの属性を追加したり、料理マスタに「販売開始日」などの属性を追加したり、社員マスタに「配属日」などの属性を追加することなどが該当する。
 このパターンは、これまで普通だったただの縦横の表に、突然時系列という時間の流れという概念を取り入れなければならないので発想の転換が必要になり難易度が高い。
 このパターンでは例えば商品価格では、商品の価格を変更するたびに販売開始日を設定して新たに行を作ることになる。従って、例えば{商品コード、販売開始日}が候補キーになる。販売開始日を設定することで、例えば下記の例だと商品コード0001の製品は、2015年01月01日から2015年01月31日まで300円で販売していたことがわかるということになる。
 またこのパターンでは、将来に対する価格変更の予約のようなことも可能になる。例えば、2015年2月1日から新価格で販売することを事前登録しておくということも可能。
DB_003.jpg
正規化に関する解答パターン
 正規化に関する解答パターンも暗記しておくことが望ましい。これらは必ず出題されるので確実に答えられるようにしておこう。
 詳細については&html(<a href="http://amzn.to/2dBC0CQ" target="_blank">情報処理教科書 データベーススペシャリスト</a>)に記述されているので、その説明を読んで理解することが必要。以下は暗記用のチェックシート代わりに。
第一正規形でない理由(正規化されていない理由)
  • 属性○○は属性△△の集合であり単一値ではないため
  • 属性○○が繰り返し項目であり単一値ではないため
第一正規形の理由
  • すべての属性が単一値で、候補キーA、Bの一部であるBに非キー属性のCが部分関数従属するため
  • 非キー属性であるCが候補キーの一部であるBに関数従属し、候補キーに完全関数従属していないから
  • 非キー属性であるCが候補キーの部分集合{A、B}に関数従属し、候補キーに完全関数従属していないから
第二正規形の理由
  • すべての属性が単一値で、候補キーからの部分関数従属がなく、推移的関数従属性A→B→Cがあるため
第三正規形の理由
  • すべての属性が単一値で、候補キーからの部分関数従属がなく、候補キーからの推移的関数従属性もないため
ボイスコッド正規形の理由
  • すべての属性が単一値で、すべての関数従属性が、自明であるか、候補キーのみを決定項として与えられている
第四正規形の理由
  • すべての属性が単一値で、すべての多値従属性が、自明であるか、候補キーのみを決定項として与えられている
第五正規形の理由
  • すべての属性が単一値で、すべての結合従属性が、自明であるか、候補キーのみを決定項として与えられている
正規化されていないと発生する可能性のある問題
  • ○○(例:商品)を事前にマスタとして登録できない
  • 属性○○が冗長になる
  • 属性○○を重複して登録するので不整合が生じる
  • 属性○○が冗長であるため、これらを同時に修正しないと整合性が失われる
  • 属性○○の情報が特定の一行にしか存在しない場合、その行を削除するとその属性の情報が永遠に失われる
結合に関する解答パターン
集計時に外部結合する理由
  • すべての○○(例:店舗)に対して△△(例:売上げ)が存在するとは限らないが、すべての○○ごとに集計して結果を出力するから
コメントを残す

コメントを投稿するには画像の文字を半角数字で入力してください。


画像認証

  • 最終更新:2017-06-01 20:21:38

このWIKIを編集するにはパスワード入力が必要です

認証パスワード