難易度：12c SQL試験は難しい?!
12c SQL基礎の試験範囲は、Oracle University（JP）のWebページ「テスト内容チェックリスト」をご覧ください。 これだけを見ると、Oracle以外のデータベースを学習したことのある方や、オラクルマスター資格は保有していないけど、Oracleなら昔っから実務でやっているという方、過去のバージョンでオラクルマスター試験を受験したことのある方は、「これなら楽勝！」とお感じだと思います。
そんな方も、次の項目にどれだけチェックをつけられるか、やってみてください。
-
SELECT句において、単一引用符を含めた列別名を記述する - 入社の古い順に、6番目から10番目の5人だけ表示する
-
ORDER BYで昇順に並べ替えるとき、NULLを先頭に表示する - 日付を英語スペルで表記する
- 同じ部署に所属する複数の社員名を1行1列で表示する
- 1つの副問合せから、2つの列を受け取る
-
SELECT句に副問合せを記述する -
INSERT INTO …… VALUESのVALUES句に副問合せを記述する - 行を削除した時に、その行を参照している他の表の行も一緒に削除する
上記はすべて「できる」ことなのですが、本試験に合格するためには、それを実現するSQL文を自分で記述できるスキルが必要です。
12c SQL基礎の試験は、SQL入門者の試験ではなく、DBAを目指す人のための試験です。そのため、SQL構文の基礎が分かっている程度ではなく、「エンドユーザーから求められている処理がSQLで実現できるかどうかコーディング（SQL文を記述する）できるスキルが求められています。
データベースシステムを管理する環境は、イントラネット環境でアプリケーションを動かしていた時代から、クラウドの時代へと大きく変わり、DBAに求められるスキルも変わりつつあります。 また、データベースが蓄積するデータ量もK（キロ）、M（メガ）からG（ギガ）、T（テラ）へと大規模化しています。そのデータをどう活用するか（ビッグデータの活用）が求められていることもあり、SQL基礎の試験に求められるスキルも高度になったのでしょう。
出題傾向
ビッグデータの活用では、生データをそのまま出力することは少なく、関数を使用してデータを加工することが日常的に行われます。
12c SQL基礎の試験では、「副問合せの使用による問合せの解決」「結合の使用による複数の表のデータの出力」「DML文の使用による表の管理」そして「データ定義言語の概要」という、すべてのカテゴリにおいて、関数を含んだSQL文が出題されます。 その中でも、表1に示す関数は出題されやすいので、基本の使い方を覚えておきましょう。
| CONCAT | LASTDA | TO_CHAR |
| INITCAP | MONTHS_BETWEEN | TO_DATE |
| INSTR | NEXTDAY | NVL |
| LENGTH | SYSDATE | NVL2 |
| LPAD/RPAD | MOD | NULLIF |
| REPLACE | TRUNC | DECODE |
| SUBSTR | CASE |
副問合せも関数と同様に、設問のカテゴリは、「DML文の使用による表の管理」なのだが、選択肢には副問合せが含まれたSQL文が登場するというのが多く、すべてのカテゴリに登場します。つまり、副問合せの基本が理解できていなければ、多くの設問で失点する可能性があるのです。 「単一列副問合せ」「複数列副問合せ」「単一行副問合せ」「複数行副問合せ」と聞いて、「注意点はこれね」とピンと来ない方は要注意です。
また、SQLの試験というとSELECT文ばかりを着目しますが、「データ定義言語の概要」の出題率も高いです。試験では、表の作成ができればよいのではなく、どういう要件のときにどういうデータ型、どういう制約を使用するべきかが問われます。表だけでなく、順序に関しても同様です。ALTERを使用した表の変更はどういう条件下においてどういう変更が可能かを理解している必要があります。 つまり、「表設計時に今後の変化も考慮しておかないと、後から簡単に変更できることと困難なことがあるんだ」ということを理解している必要があるといえるでしょう。
表設計時といえば、「概要」のカテゴリでは、ER図を読み取れるかどうかが試される設問もあります。
Oracle固有ではなく一般的なDBスキルも必要
次の問題に挑戦してみてください。
正しい記述はどれですか？
- a. 部門は強いエンティティである
- b. 部門は弱いエンティティである
- c. 部門名は属性である
- d. 部門名はコンポジット属性である
まず、「この絵はなあに？」と思われた方、これはER図です。 「私の知っているER図とは全然違う」と思われた方、これは、Peter Chen氏が考案した「チェーン記法」と呼ばれる描き方です。ER図には、IDEF1X記法、IE記法など複数あるのです。
ER図とは、データを「実体（entity）」「関連（relationship）」「属性（attribute）」という3つの構成要素でモデル化するものですが、チェーン記法では、実体を四角、関連をひし形、属性は実体から線で引っ張った先（本図では楕円）に記述します。
この設問のER図には関連（relationship）が描かれていないため、ER図を理解している人にすら、唐突な感じがするでしょう。
次に「強い」「弱い」ですが、データモデリングが分かっている人には、「強い」エンティティとは独立エンティティ、「弱い」エンティティとは従属エンティティと言えば理解できるでしょうか。
例えば、注文と注文明細というエンティティ（表）が存在する場合、注文明細エンティティのデータは、注文エンティティにデータが発生した上で必要になるデータです。注文なくして、その明細は存在しえません。この状態を注文明細は注文に従属しているといいます。
アプリケーションを中心に担当している人に説明するならば、マスタ表と呼ばれるエンティティは強いエンティティで、トランザクション表と呼ばれるエンティティは弱いエンティティだと思えばいいでしょう。
部門エンティティはマスタ表であり、他の表にデータが登録されたことをきっかけに発生するデータではありませんね。よって、「a. 部門は強いエンティティである」は正しいです。
また、属性（attribute）とは列のことなので、「c. 部門名は属性である」は正しいです。しかし、選択肢d.にある「コンポジット属性」であるかどうかは、「コンポジット」の意味が分からなければ、解答できません。
コンポジット（composite）とは複数のものを合成あるいは組み合わせたものを表します。データベース列で説明するならば、注文明細表の識別番号が意味をなさない数値、例えば、1、2、3、……と順に採番されるなら、コンポジット属性ではありません。 しかし、注文番号と明細行の組合せ、例えば、注文番号100番の1件目の明細は1001、2件目は1002、……とするならば、コンポジット属性です。 よって、部門名はコンポジットではなく、「d. 部門名はコンポジット属性である」は正しくありません。
12c SQL基礎試験をあなどるなかれ
文中にも書きましたが、クラウドやビッグデータの出現により、DBエンジニアに求められるスキルは、少しずつ変化しています。 それに伴い、オラクルマスター試験で評価されるスキルも変化して当然ともいえるでしょう。設計のスキルやデータを分析するSQLは特にウェイトが高くなっているといっても過言ではありません。
12c SQL基礎には、そんなスキルが求められているなんていうと、言い過ぎかもしれませんが、そう覚悟して臨んでください。 そして、そんな12c SQL基礎の試験に合格したら、どうぞ、自慢してください。 また、人事担当の方や部下に資格取得を推奨する立場ならば、「SQLの試験だろ、簡単だよ」と合格して当然のように考えたり、学習期間を短くしたりなさらないでください。
しっかりと事前準備をするために、本連載を活用していただけると嬉しく思います。
