フクの非日常

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

春はデータベーススペシャリスト

次、データベーススペシャリスト受けます。

これまで春の情報処理といえばSW、ESだったけれど
めでたく両方とも目標達成することができた。
これに満足してスキルの向上を止めてしまえば途端に時代に取り残されてしまう。
そこで継続的に業界動向へキャッチアップすること、専門分野の拡大を目標とし、
今回はデータベーススペシャリスト(DB)を受験することにした。
春の試験はプロマネ(PM)も科目にあるが、DBの方が要件、設計に
注目した範囲のため、より実用的と考えられる。

DB試験は見たところ「要件」「仕様」「設計」といった、上位工程の
作業を取り扱った話題が多い。これらの要素はデータベースに限らず
通信、組み込みでも本質的には同じなためより高い要求レベルの
実現のためにはぜひとも身に付けておくべき技術である。
要件や、仕様レベルを整理するにあたり、UMLの表記法が使われている。
これも時代の流れとしてUMLが認められて前面にでてきたことを意味している。
表記法のツールとしてのUMLだけでなく、UMLの概念もあわせて身につけることを
今回4月19日までのテーマとして取り組んでいきたい。

目標は、一発合格。
SQLは苦手なので実際にキーボードを叩いて身に付けることが必要そう。

情報処理教科書 データベーススペシャリスト 2009年度版 (情報処理教科書)情報処理教科書 データベーススペシャリスト 2009年度版 (情報処理教科書)
(2008/09/17)
三好 康之山下 真吾

商品詳細を見る
スポンサーサイト

データベーススペシャリスト過去問分析(1)

平成19年 午前 
問15 演繹推論の説明として、適切なものはどれか。

 ア 与えられた事例から、一般的法則を導き出す推論方法である。
 イ 与えられた事例の類似性によって、未知の事実を推定する推論方法である。
 ウ 幾つかの前提や公理などと推論規則から結論を導き出す推論方法である。
 エ 過去に経験した事例から類似の問題を探して適用し、結論を導き出す推論方法である。


情報処理に限らず帰納法、演繹法という言葉は一般的に使われている。
知っていれば解答できる問いではあるが、あえて一歩先を目指し、
帰納、演繹が使えることによって、IT業の中で何ができるのかを考えよう。

帰納法は、オブジェクト指向的考え方の中で必要性がでてくる。
ある集合を「クラス」という概念でくくる場合、帰納的考え方をする。
たとえば、「うどん、そば、スパゲティ」があったときに
これらを表すには何という言葉を使ったら良いか、ということである。
(ちなみに、『麺類』、とか『メニュー(食事)』とか、そんなくくりを付ける)
問題文中の「ア」が帰納法の説明である。

ちなみに、問いの答えは「ウ」。
演繹は設計やデバッグで思考の積み上げを行うときに自然と使っている思われる。
逆に、演繹を意識して考えると設計・デバッグが上手く行くのではないだろうか。

'うなぎ'の'あじ'は?

データベース入門中。
昨年買っていた「日経ソフトウエア」にDBの特集記事がちょくちょく載っていた。
「そのうちねー」と思って流していたDBの話も今なら実感を持って読める。
2008.10は「必ずわかる!データベース」~これさえ読めば基礎はバッチリ

日経ソフトウエア 2008年 10月号 [雑誌]日経ソフトウエア 2008年 10月号 [雑誌]
(2008/08/23)
不明

商品詳細を見る


さらっと流すと、「PostgreSQL」のインストールガイドの1章、
DBを叩いてみる2章と、Javaでデータベースプログラミングを行う3章の構成だ。
SQLを叩く練習をしたいので、例のごとく3章はご無礼して2章までやってみた。
ま、ちかぢか必要になるのだが直近はSQLを叩くところを身に付けていこう。

まず、PostgreSQLのインストール。ガイドに従ってさっくり入れる。
これまでやってきたMySQLはコマンドラインから全てSQLを叩いてきたが
PostgreSQLはGUIのメニューが使える。

家計簿をつけるためのaccount_bookテーブルをつくり、データを追加する。
左上の窓にSQL文を入力し、実行ボタンで走り出す。
postgres_1.jpg

結果を表示するクエリ。結果が下の窓にでてくる。
Windowsの別ウィンドウとして開くことができる。
postgres_2.jpg

本書では、「シーケンス」をつくり主キーを連番で振る仕組みが紹介されている。
「あじ」を追加する同じクエリを発行すると。。。
postgres_3.jpg

IDが別で複数のレコードを追加することができた。
postgres_4.jpg

PostgreSQLを使った単一のテーブルへのアクセスを使った演習はここまで。
複数テーブルを使った制御はまたまた次回へ持ち越しと。
今回は、PostgreSQLを入れて叩いたところがポイントかなー。
次、いってみよう。

データベースの気持ちになって

データベースのアクセスには手順がある。RDBMSが違えど、基本は同じ。
まずログインする。
次に、データベースへ接続(Connect)する。
その後でテーブルに対してSELECTだの叩けるようになる。

一つ疑問に思ったこと。
それは

 「どうしてConnectが必要なの?」

である。
これは、どうやら初心者ならではの疑問と想像するが、
初心者だからこそ持てる疑問で実は、案外深いかもしれない。。
知ってる人からすると、あたりまえの「手順」なのだが、、、

Connectが必要な理由をWebで検索をするが、そんな話題は見つからない。
みなConnectさえできればよいから、その文法が載っているだけなのだ。
探しても見つからなければ、考えるしかない。
DBアクセスにはどうしてConnectが必要なのか。
理由があるはずだ。
しばし、思考。。。

思いついた理由、その1.
異なるデータベースの中に、同じ名前のテーブルが複数存在するから、
接続先を指定する必要がある。ほんとかなぁ・・・?

理由、その2.
データベースを指定しないと、全部のデータベースを見に行かないといけないから大変。
だから、触る分のデータベースを指定するのかな。
RDBになってデータベースの分割の流れになってからこうなったのかも?

理由、その3.
。。。思いつかなかった。
でもまあ、上の2つの理由で必要そうな気はしてきたよ。


他にも知ってる人にとってはあたりまえだけど、
なんでだろう~?って思うことはたくさんありますよ。

2つのテーブルを同じフィールド名で連結するとき、
WHERE句でTABLE1.USER_ID = TABLE2.USER_ID
みたいに書くじゃない?
そのときどっちを左、どっちを右に書くのが作法なのかな、と。
書き方によって検索のパフォーマンスが違ってくるとか心配じゃない?

3つのテーブルを同じフィールドで連結するときは、
WHERE TABLE1.USER_ID = TABLE2.USER_ID
AND TABLE1.USER_ID = TABLE3.USER_ID
とかするでしょう。
これが、TABLE2.USER_ID = TABLE3.USER_IDは書かなくてよいのかしら。

てなことを悩んだりしてます。
つまり、お作法全般を知りたいのだな。

DB 関数従属性とは。

春の情報処理まで2週間をきり、試験勉強も大詰め。
午後の問題に取り組み中。

午後問題のパターンはだいたい決まっていて、
作りかけのE-R図を完成させるだの、
テーブル定義に主キー、外部キーを付けて完成させるだの、
DBを完成させるのが良く出題されるのだ。

で、その中で肝になるのが、【関数従属性】というワケで。
あるフィールドが決まると、それに従って他のフィールドが決まるとする。
そいつらを「関数従属性がある」というわけだ。
たとえば、(社員番号、氏名、性別)というテーブルがあったりすると、
社員番号が決まると氏名、性別が一意に決まってくる。
こんなときに社員番号→氏名、社員番号→性別、なんて書いたりする。

あー、そうね。あるある、すると社員番号がキーになるんだ。
って言えば理解は早い。
それを「関数従属性」なんて仰々しい名前がついてるから、よーわからん!
となるのかもしれない。
関数従属性が何者かはやっとわかった。後は、設問の中からどれとどれが
関数従属性がある、ってのを読み取らないといけないんだよね。
これがまた、たいへん。
「一意である」「~するごとに」「同じ~をすることができない」などがキーワードのもよう。
もうすこし分かると面白くなってきそう。

DB 候補キーを捜せ。

候補キー、そのまえに。キーとは何かの理解が必要だ。

キーとは、テーブルの行を一意に特定できるフィールド、またはその集合のこと。
(社員番号、氏名、性別、基本給)なんてテーブルを作ると、
フィールド全体を指定すれば当然行は決まる。
{社員番号,氏名,性別,基本給}なんてのはキーの一つ。

これだと行の特定に意味が無い項目を含んでいるので、
ムダをはぶいたものが、候補キーになるのだ。
性別は2種類だし、基本給が同じ人は同期には多いでしょう。
氏名は同姓同名の人がいるので、これらで行の特定はできません。
よって、社員番号だけが候補キーとなりますよ。
候補キーの中で、一番良く使うのを主キーといいます。
候補キーが1つしかないと、社員番号が自然と主キーになりますね。

つまり。
キー>候補キー>主キー
みたいな関係なのかしら。

候補キーを捜せ。と問われたときには何をしたら良いのか。
主キーのようにずばっと「これだな」と直感でわかるものではなさそうだ。
テーブルの行を特定できる組み合わせで、無駄が無いもの。
という条件で地道に消しこみをしていく必要がありそうね。

情報処理の試験問題はテーブルが複雑でとてもたいへん。
病歴{患者番号,入院日,入院区分,診療科,カルテ番号,
    主治医コード,主病名コード,退院日,退院区分}
から候補キーを捜せ、と問われたとき。泣きたくなります。

問題文にはフィールドの関数従属図が付いていて、コレだけでは解けないんですが。
ほら、でてきた。昨日の「関数従属」なんですよ。
{患者番号,入院日}→入院区分
なんてのが条件として追加されてます。
要は、関数従属の左側(決定項というらしい)が把握できて、
それだけでレコードが特定できるか、って判断を進めていけばよい。
と、いうはやすし、おこなうはがたしなのですが。

関数従属性に候補キー。とても地味な話ですが、きっと基礎は重要。
ヒットを打つための素振りと思ってこつこつやっていきますよ。

DB 部分関数従属性と推移的関数従属性を列挙せよ。

関数従属性とは、Xが決まるとYが決まるといった関係をさす。
X→Yとしたときに、Xが決定項、Yが被決定項である。
Xは1つの要素の場合もあれば、1つ以上の要素からなる集合の場合もある。
1つのときは話が簡単。
1つ以上のときがあるので、話が長くなる。そこで部分関数従属性が登場する。

候補キーが再び登場。
関数従属性があり、決定項に該当する要素がテーブル全体を一意に決定することが
できるとき、候補キーと呼んでいた。
この候補キーの一部が、被キー項目を被決定項とする関数従属性を持つ場合
部分関数従属性がある、と言う。

記号の羅列のような文章を書いてしまったが、例を挙げるとこういうことだ。
会社にサークル活動があって、サークル員というテーブルを作るとしよう。

 サークル員(社員番号,氏名,部署,年度,所属サークル)

社員は年度ごとに所属サークルを選んで活動するので、{社員番号,年度}が候補キーである。
候補キーの中の社員番号は、社員番号→{氏名,部署}という関数従属性を持つので、
部分関数従属性がある、という。
この場合、社員番号に関わる関数従属性を外に出して(社員テーブルとして分けて)

 社員(社員番号,氏名,部署)
 サークル員(社員番号,年度,所属サークル)

とするのが良いのかな。

推移的関数従属性は、候補キーでない集合の中に関数従属を含んでいるもの。
こちらも関数従属を外だしする対象となる模様。

部分関数従属性や、推移的関数従属があると、
テーブルの更新や削除のときに不整合を起こしてしまう。
テーブルの正規化を考える上で、部分関数従属、推移的関数従属が必要であると理解した。


DB 第○正規形であること。

関数従属、候補キー、部分関数従属、推移的関数従属は何のため?
それは、テーブルを正規化するために必要な考え方だった。
各正規形には段階があって、第○正規形を満たす条件があって、
それを満たしていなければ、その一つ手前の正規形である。
第一正規形を満たしていなければ、「正規化されていない」と分類される。
連邦軍の階級で言えば、「民間人」みたいなものか。

第一正規形を満たす条件は、「単一の値をとる」。
第一正規形にするには「繰り返しを排除する」。
などと解説されていますが。言葉ではさっぱりわからんですね。
(売上、明細1、明細2、明細3)といったテーブルは明細が繰りかえしでてきますので、
(売上、明細)にして、レコード3件にする、といったらなんとか理解の範囲。

第二正規形のための条件は、部分関数従属を排除する。
候補キーに関連する関数従属を外だしするといった感じ。

第三正規形のための条件は、推移的関数従属を排除する。
非キー項目の中で関数従属を排除すること。

反対に、テーブルを見て、このテーブルは今どこまで正規化されているか問われることも多い。
それに答えるには、テーブル内の関数従属を全て見つけ、候補キーを特定し、
関数従属は候補キーだけなのか、候補キーの一部が決定項になるのか、
非キー項目が決定項になるのかを調べると、第三正規形までが区別できる。

実際に正しく判断するのは難しいけれど、ここまではなんとか話についてきた。
こうやってテーブルを正規化できると、ようやくヒット一本打てた感じがする。
ボイスコッド、第四正規形、第五正規形などが続くらしい。
まだまだ大変。

DB 関数従属性とテーブル正規形のまとめ

ここ数日でやっと関数従属性とは何か、テーブルの第○正規形の条件がわかってきた。
あとは実践による理解度チェックが必要だ。
これらの問題は、午後Iの選択問題のうち、1番めでよく問われる。
平成20年、19年、18年とさかのぼって見ているが、18年の問題は
ずばり設問で候補キーと、部分関数従属、推移的関数従属、テーブルの正規形を
問うているので、理解度チェックにはよい問題だった。

実際解いてみて、話について行けるようになったのは進歩だと思う。
以前だと、推移的関数従属とかキーワードが出てくると頭痛がしだしたものだ。。。
で、正解は出せたのかというと、候補キーの抽出で不正解があった。
主キーと、候補キーの違いを今一度はっきりさせておくことが必要そうだ。
候補キーを選び出すのは、なかなか難しいようだ。

候補キー:
 スーパーキーの中で極小のもの。
 タプルを一つに特定するのに無駄な条件を一切含んでいないもの。

だそうだ。
属性が多いテーブルだと、候補キーも自然と多くなるし、
関数従属もあるため正規化も下がってくる傾向があるのだろうー。

さて、DB試験は来週だが。
今回は試験改正後の1回目なのでなにかと要注意な点がある。
午後Iは問題数、選択数が少なくなった。
4問中3問選択だったのが、3問中2問選択に変わっている。
これまで、DB基礎、DB設計、SQL、性能/セキュリティ
というパターンが定着していたのだが、今回はどうなるのか。
DB基礎とSQLが無くなることはないだろうから、、、、
DB基礎がDB設計を取り込んだカタチになるのだろうか。

SQLはカーソルだとか、ロールの話が出てくるとちょっと困る。
性能改善とかインデックスの話などもちょっと弱い。
まあ、焦ってもしかたがないか。
まずおさえるべきははDB基礎とDB設計。
それからSQLの構文を応用的なところまで拡張していき、
索引/チューニング/監査まで抑えていこう。


DB 関係代数の「さしすせそ」

「関係代数」って、なーんだ!?
Wikiで調べたけど、定義自体が難解で理解できなかった。。
集合論と一階述語論理、ってなんだろうー。

難しい話はわからないが、「関係=Relational」はRDBMSの「R」なのね。
RDBMSを使うときに表だとか、テーブルだとかを使うのだけれど、
その表やテーブルの「関係」を足したり、引いたり、掛けたり、割ったりするのが「代数」だと。

 集合演算        :和、差、積、直積
 関係代数独自の演算 :射影、選択、結合、商

ぱっとどんな演算になるか想像が付かないが、
集合の図を描いたり、実際のSQL文と照らし合わせると、、、

 和=OR演算
 積=AND演算
 差=WHERE NOT EXIST
 結合=SELECT FROM A, B WHERE(選択条件)
 選択=SELECT WHERE(選択条件)
 射影=SELECT DISTINCT

なるほどと思うところがある。
SELECTのDISTINCTはこんな意味があったのか、とね。

基本的な構成要素は「和、差、結合、選択、射影」だそうだ。
「さ=差、し=射影、す=和(す=う=Union)、せ=選択、そ=結合(そ=お=Join)」
と覚えよう。

DB DDLとDMLと

DBにログインしました。
さあテーブルにデータを入れましょう、のそのまえに。

DDLのCREATE文でテーブルを定義するのがはじめの一歩。
データ定義言語のDDLはテーブルの大枠を決めるもの。
CREATE/DROPでテーブルを作ったり、破棄したり。
CREATE/DROPで作るものは、TABLE、VIEW、ROLE。
VIEWはTABLEを選択、結合した結果を参照用に見せるためのもの。
条件によって更新することもできる。
ROLEはテーブルの参照、更新権限を定義するもの。
給与テーブルなど、全員に参照権限は与えないし、
人事情報は本人だけに更新権限を与えたいなど、細かく設定していく。
情報セキュリティの要求が厳しい昨今、RDBMSも権限機能を持つのだな。

権限付与・破棄のGRANT、REVOKEはDDLに含まれる。
OracleMasterなんかではDCL(データ制御言語)に含まれていたが、
情報処理試験ではDDLとするそうだ。
分類の話だからどっちでもよい気はするが。。

DML(データ制御言語)が叩けるようになるのはこれから。
SELECT、INSERT、UPDATE、DELETE。
主役はSELECTだねー。

そして、思わぬ伏兵がCURSOR。
「カーソルなんて要らないじゃん!」
って思っていたけれど、やっと使い方が分かった。
普通にRDBMSにログインしてSELECT文を叩くと、結果が複数行表示される。
C言語などのプログラムからSQL文を叩く場合、
複数行得られた回答をどうやって処理するのか?
その答えがCURSORなのである。

繰り返し処理で、カーソルから1行取得して処理し、次の行を取得する。
行が無くなるまで実施、という処理なのだ。
そういえば、SQLを使ったプログラムではループで結果を取り出していたけど
このカーソルと同じことをやってたんだね、とやっと気が付く。

あとはCOMMITとROLLBACK。
これらはトランザクション制御でかなり重要。

試験に臨むにあたり、SQL構文の暗記は必須事項である。

 GRANT A ON B TO C
 DECLARE A CURSOR FOR B
 SELECT A FROM B JOIN C ON D
 UPDATE A SET B WHERE

GRANTの後はONだっけ、TOだっけ、とか
DECLAREの後はCURSORだっけ、カーソル名だっけ、とか
SQLを書くときに構文を確認すれば良いだけなので、実際には暗記の必要はない。

問題冊子にSQLの構文くらいさらっと記載してくれれば、
構文の暗記なんかに余計な労力を割かなくて済むのだが。
SQLくらい空で書けなくてはDB技術者の資格無し、という
暗黙のメッセージと受け取っておくことにする。

DB DBMSはロック、コミット、ロールバックで

DBMSで考慮が必要なものは、プロセス間の競合と、
エラー発生時のリカバリーの仕組みと見た。
トランザクションに必要なのは、ACID特性と言うからね。

インデックスや分散データーベースのような高速化、効率化はその次のステップとみた。
まずは、いかにして整合性を取るのか、その仕組みを押さえようではないか。

DBMSでよく問われるのがコミットとロールバック。
テーブルに行を追加したり、削除したりと変更を加えても、
COMMITするまでは実際のDBには反映されない。
隣の人(トランザクション)に叩いたコマンドの結果を見せたいならば、
COMMITを済みである必要がある。
逆に、COMMITせずにROLLBACKを叩くとテーブルは元の通り。
ちょっとだけ触るときに便利。

障害発生時にはロールバックとロールフォワードか。
どっちがどっちか良く忘れるのだが、ロールバックは処理の途中で障害が起きたときに使う。
端末叩いているときにエラーで落ちたら、ロールバックしてやりなおしと思えばよろし。
障害発生時に、トランザクションが終了しているのであれば、ロールフォワードを使う。
障害が起きたところまで進んでよいのでフォワードな感じかと。

ロックの種類は共有ロックと占有ロック。
共有ロック同士は共存できるが、占有ロックは他のロックと共存できない。
デッドロックの回避には、資源のロックの順序を同じにすると、まず問題なし。
この辺はソフ開というか、応用情報でもしっかり問われる範囲の話。

さきほど。
COMMITするまで隣の人(トランザクション)には見えない、と言い切ったが
実は、隔離水準レベル(ISOLATION LEVEL)に依存するものである。
このレベルを低くすると、他のトランザクションの影響を受けやすい。
コミット前のデータを読むような設定にすることもできる。
何が利点かといえば、コミットされるまで待たなくて良い、つまりロックによる待ちが少なくなる。
しかし、更新後、コミット前のデータを読んだが、やっぱりコミットされなかったとなると、
嘘のデータを読んだことになるので必要なレベルまで隔離レベルを設定する必要がある。
ダーティリード、ノンリピータブルリート、ファントムリードはDBで出てきた話かな。


DB チューニング

DBはチューニングが命である。
と、偉そうなことを言ってしまったが、チューニングを実際にやったことはない。
でも、ジョブの実行時間があまりにも遅い場合は時間的要件を満たさないことがあり、
システムとして致命的な欠陥になる。
チューニングができてこそ、DBスペシャリストの価値があるのではなかろうか。

いつお鉢が回ってくるかわからないので、基本は押さえておこう。
DBの性能を上げるにはいくつもの手段がある。
SQL文の考慮、テーブルに冗長性を持たせる、アクセスするDBを分ける、
サーバー側に処理を持たせるストアドプロシージャを利用する。などなど。

まずは基本の「き」である、SQLをどこまでチューニングできるかを実感するべし。
SQLでチューニングといえば、インデックス。
インデックスは普通に使われてるんで、逆に知らないと困るといえましょう。
インデックスを付けるのは主キーや、外部キー、ORDER BY句の列など。
しかし、
 ・テーブル行数が少ないもの
 ・列が取りうる値の種類が少ない
 ・頻繁に更新されるテーブル
などには設定しても効果が無いか、逆に性能が落ちる場合があるので注意が必要。
WHERE句の書き方によっては、インデックスは使われず、全件検索が走るのでご用心。
左辺に式を書いた場合(WHERE 単価*1.05 >1000)など、全件であるよ。

ところで、以前から疑問に思っていることを一つ。

 WHERE句の条件式は、左右をひっくり返したり、
 ANDやORで条件をつなげる順序は、実行結果に影響があるのか?

テーブルをつなぐ条件式を書くときって、T1.商品名=T2.商品名
なんて書くんだけれど、左右が逆になっても良いのかという疑問である。
結果は同じなんだろうな、というのが今の見解。
速度に差がでるのかは、いまだ疑問。実はチューニングで考慮すべきかもしれない。


DB 前日は予行演習

試験前日の土曜日は、予行演習に充てたい。

まず、午前。普段の出勤する時間に起床して、持ち物チェックを行う。
鉛筆、消しゴム。時計に受験票。会場のチェックも忘れずに。
鉛筆は、シャープペンもよいが、早くマークしたいならHBの鉛筆。
もっと早くマークするには2Bを使うというウラ技もあるが、
訂正するときに黒く残るので諸刃の剣かもしれない。
写真がまだなら、昼に撮りに行こう。散髪までの余裕はないか。

スケジュールを確認しておくこと。試験改正で午前が2つに分かれた。
9:30から50分間で午前I
10:50から40分間で午前II
午後はこれまで通り、90分と120分。

予行演習も、このスケジュールに沿って行いたい。
午前Iが曲者で、これまでのDBの午前問題の範囲で出題されていない、
コンピュータ基礎科学や、ネットワークからも出題される。
ITパスポート、基本情報、応用情報のいずれか、
午前Iのリハーサルとして演習に組み入れよう。
午前IIは、これまでのDB試験の復習をしよう。
採点方式も、素点で評価されるようになった。一問一問を大事にしよう。

昼休みもしっかり取ること。
明日の昼食に何を持っていくのか、おやつは何にするのか決めておこう。
午後の試験も長い。
暖かいお茶、チョコレート、などなどリラックス&集中できるものを準備する。

午後Iも復習をしよう。
3問中2問選択になるが、内容は変わらないはずだ。
問題選択に悩むくらいなら、1と2を回答すると決め打ちしても良いかもしれない。
性能や、データベース監査など苦手な問いだったら3つめの選択肢へ。
最後の午後IIはいかに長文を読み解くか。
過去問を読み、いかに早く問題業務の要件を押さえるかに注力しよう。
最後の2時間、途中で思考を中断しないように。リラックス&集中を心がける。

ここまでやったら頭はぼろぼろ。
夕食は早めに取って、荷物を鞄に詰めて早く寝よう。
明日起きたら、茶を沸かして持っていく余裕が欲しいかな。

DB 午後II

午後IIは問題が長い。
頭から読んだところで全て頭の中でイメージするのは難しい。
そこで。

MMAPDB.jpg

いつも試験で使っているのはマインドマップ型に問題を整理すること。
問題文を読みながら、片っ端からマインドマップに落としていく。
そうすることで、問題で扱っている業務の塊が見えてくるし、
その範囲内で扱っているキーワードも自ずと記録される。
後から問題文を辿って見なくても、1ページに収まる記録を作ることで
「ああ、ここで出てきた話だったね」
とぱっと見つけることができる。

別に、マインドマップでなくても良い。
設問の内容を整理するには、自分の手を動かして書いた方が良く、
たまたま自分にあったスタイルがこれだった。
SW試験や、エンベデッド試験のときも午後はマインドマップで問題を整理した。
「問題をうまくマップに落とせたら8割がた解ける」
と、実感を持てた。(前の試験では。。。今度はどうかな。)

そうそう。
どこにマインドマップを書くべきか。
とても余白には書ききれないので、問題冊子の『メモ用紙』に書こう。
でも、メモ用紙とは名ばかりで、問題冊子の後ろの余白がメモ用紙になっているだけ。
別に配ってくれるわけではないのだ。
いちいちメモ用紙欄を捲ってメモするわけにはいかないし、どうやって使うんだ?
悩んだ末に、問題冊子から破いて使うことにした。
注意事項に、問題冊子を破ったり、分解してはいけません、とは書いてないからね。

まず問題文が長いから、全体を把握するのが第一歩。
(そのための、マインドマップ!)
そこから、DBの知識を問う問題にブレークダウンする作業をしてから
問題に答えていくと、自ずと答えが見えてくるのではなかろうか。

DBの試験は、パズルのようなところがある。
たとえば、関係スキーマの1つが空欄になっていて、そこを埋めなさいという。
問題文に出てきたキーワードを当てはめていくと、いくつかの欄は埋まる。
しかし、書いてあるキーワードだけでは埋まらない場合がある。
ここからは、DBならではの知識を使って解答しなければならないのだが、
「関係」を読み取って答える必要があるのだ。
これがパズル+αになって難しい。

最近一つ学んだのは、関係(リレーション)を読み取るにはコツがあるのだ、と。
AからBを作ります、って話の筋がストレートなときは、別に問題にならない。
AのうちどれかからBを作りますってなった場合は、AとBは一つのテーブルに収まらない。
多対多の関係になるから、関係テーブルを使って、一対多+一対多の関係に
持ち込まなくてはならない。

試験中にどこまで思い出して、閃いて、答えを書くことができるか。
明日は頭をすっきりさせて、リラックスと集中で頑張るとしよう。

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。