データベーススペシャリスト資格｜2022年10月挑戦ログ　9月15日｜DB実技演習（本試験１カ月前）｜SQL（確認ドリル）

この記事は「データベーススペシャリスト資格に興味はあるが、どのようなものか？どう学ぶのか？」という方向けに、具体的な内容と私自身の挑戦ログをお伝えする。学び中の方や、これから学ぼうとされる方の参考になれば幸いだ。今回は知識およびSQL（確認ドリル）について書く。（SQLはGoogle Big Queryに準拠）

また、考察においてキャリアコンサルタント資格の挑戦ログについても記述する。

DB学習方針（一部再掲）
DB学習ログ
問題129（SQL確認ドリル）
考察
考察のシンプル化と英訳（練習中）
参考資料

DB学習方針（一部再掲）

対策MUSTのもの

午前2対策、TAC講義動画全て視聴⇒完了
午前2対策、TACテキストの問題全て完答⇒3ラリー目まで完了（直前見直し要）
午前2対策、過去5年分の過去問ベースで完答⇒1ラリー目完了、ほぼ全問正解（直前見直し要）
午後対策、TAC講義動画全て視聴⇒完了
午後1対策、”物理＋SQL”問題につき、解き方を把握しておく⇒現在着手中⇒直前にもう一度解く（無理なら頭の中で解く）は必要。定着のため
午後1・午後2対策、論理設計問題につき、時間内に答えを埋める訓練⇒約7つの過去問につき2ラリー目まで完了。1日1回の実技演習として3ラリー目実施中
全般対策、TAC実力テストおよび公開模試の提出⇒提出済、返却待ち（模試は返却あり）
全般対策、R3を午前・午後通しで解いて最終仕上げ⇒未着手

対策BETTERのもの

午前2対策、三好先生の本ベースでも問題を解いておくことで、より幅広く対応⇒未着手
午後対策、過去問パターンや業務基本パターン（三好先生テキスト）の記憶⇒未着手

今後の大まかな計画

午後1″物理・SQL”を1日1問「解き方把握」する（上記MUST№5）
1日1回論理設計実技は続ける（上記MUST№6）
残りの時間で、R3（MUST№8）を行う。（返却され次第、TAC実力テストや公開模試振り返り研究。公開模試は動画もあり（MUST№7）
夜寝る前などスキマ時間かつスマホ・PC利用できないときは、本ベースの学習（BETTER№1,2）

回答プロセス考察（NEW）

共通の回答プロセスとして、「本文・設問・RDBMS仕様・パズル要素」の４点と認識。
まず「本文」とは、本文中で設問について記載している箇所を探すこと。大抵設問１から順に本文も綺麗に並んでいるので、特定しやすい。
次に「設問」とは、設問そのものであり、「〇〇について答えよ」となってる部分。「ｘｘのとき」など前提・制約が課されていることが多く、これが回答を絞り込む情報に成り得る。
次に「RDBMS仕様」とは、設問に関わりのある仕様の記載箇所を探すこと。記載の内容は毎回ほぼ同様で、少しづつ特色があるので、過去問を解きながら慣れるのがベターか。ここの記載はヒントであり制約でもある点に注意。
最後に「パズル要素」とは、穴埋めで既に埋まっている箇所もヒントに、残りを推測して埋めていく作業。実はかなりこれで解ける部分も大きい。
いずれにせよ上記の作業で、答えは一意に特定できるはずなので、それを意識しておくこと。

DB学習ログ

午後1″論理複合”

今回はH26 問1の基礎理論・論理設計・関係代数演算に関する問題を確認。
寝不足かつ体調不良の状態。（育児中の方は”あるある”かもしれないが、長女が風邪をひき家族内感染。くわえて次女が夜泣きにつき交代抱っこ）
状態は良くなかったが、何とか既存のパターンで解けるところはしっかり回答できた。
応用力を身に着けるため、「なぜそうなるのか」の理解をあわせて行いたい。
今回の大事なポイントは３つ。
まず、基礎理論は確実に対応できるようにすること。既に過去問を２パターン（第三正規形、第一正規形）解いたので、これを足掛かりに自信をもってケアレスミスをなくすこと。
次に、論理設計は今まで培ったコツにプラスして、ノウハウを貯めていくこと。今回は「バグ表から工程表に複数の線を引く、バグ表に自己参照の線を引く」２パターン（書き込むパターンとしては、私は初出）が漏れたので、次は出来るようにしたい。
最後に、関係代数演算は基本的なSQLの知識で十分解けるが、今回の問題で慣れておくこと。より正確に、早く解ける。

1日1回論理設計実技

今回は上記で取り組んだ内容に、論理設計を含むので完了。

（1日のうち）残りの時間でやったこと

午前2対策について、三好先生の本ベースでSQLの知識を読み、問題を解いた。

問題129（SQL確認ドリル）

問題文

salesとcustomersテーブルから、販売金額の合計がもっとも多い顧客が居住する都道府県と販売金額合計を求めてください

joinおさらい

salesテーブルは販売金額を管理しているが、顧客情報はuser_idのみである。
いっぽうcustomersテーブルは主キーにuser_idを持ち、都道府県など詳細な商品情報を含む。
そこで、user_idを結合キーにしてsalesテーブルとcustomersテーブルを結合し、そのうえでユーザー別に束ねて、販売金額（revenue）の合計を求める。
具体的には以下のとおり。
なお、結果カラムにuser_idを見せたくない場合、with句で「販売金額の合計がもっとも多い顧客、および販売金額合計」を求めておき、select句で当該顧客の都道府県と合計金額を選択するということもできる。

考察

データベーススペシャリスト資格について。午後1（基礎理論、論理設計、関係代数演算）実技をふまえ、今後意識すべきことを再整理した。また、SQLの確認ドリル（salesとcustomersテーブルから、販売金額合計がもっとも多い顧客が居住する都道府県と、販売金額合計を求める）を解いた。
キャリアコンサルタント資格について、「意思決定の支援」に関する知識を学んだ。意思決定はいわば夢を叶えるプロセスであり、相談者の経験や価値観などに基づく唯一で大事なものだと思う。だからこそ、私自身の思い込みを払拭するためにも包括的な理論の理解は重要と感じた。