【デスペ】令和5年秋午後1問1の解説（データベーススペシャリスト）

このNoteでは「デスペR6春午後1問1」の解説をします。

私はデータベース設計に絞って、SQLは絶対にしません。

データベース設計は問題文（仕様）をER図とスキーマ表に矛盾なく実装する「作業」です。

データベース設計は地道な作業。言葉と表を大まかにも細かくも手厚くチェックする忍耐と速さが必要です。正直、真面目でない・一発逆転を狙う・コツコツできない方には向かないです。私もお力にはなれません。

しかし、他のSQLや運用の問題と違って、データベース設計は構成が決まっています。問題文・ER図・スキーマ表は必ず。あとは、処理の追加による設計変更、各スキーマへの権限がプラスされて出題される形。

しっかり学習をすれば得点再現性がとても高いのです。

あなたの「データベーススペシャリスト合格の戦略立て」の役に立ったら嬉しいです。是非読んでいって欲しいです。

このNoteは、私が独学合格した経験と、IT専門学校での授業のノウハウで書いています。合格のお手伝いに少しでもなったら嬉しいです。

それでは始めましょう！

設問1(1) | 主キーであるキーワード「コード」「番号」「識別」

候補キーとは「主キーの候補となるキー」。

図2のスキーマの各項目の記述を、問題文から見つけて判断します。

• 社員コード：3-(1)「社員コードで識別」の「識別」からキーになり得る。

• 社員氏名：3-(1)「同姓同名の社員は存在し得る」から、一意性がないのでキーになり得ない

• 社員所属組織コード：3-(2)「複数の組織に所属し得る」より、社員コード（など）と複合主キーにしそう

• 社員所属組織名：1-(1)「組織名は重複しない」より、組織コードと同じくキーになり得る

• 社員所属上位組織コード：1-(2)「一つの上位組織に属する」より、所属組織から一意に決まるので、キーにしなくて良い

• 社員所属上位組織名：1-(2)「一つの上位組織に属する」より、所属組織から一意に決まるので、キーにしなくて良い

• 社員役職コード：

  • 2「役職コードで識別」よりキーになり得るかもだが…

  • 3-(3)「同一組織で複数の役職には就かない」より、複合主キーにする必要はない。現状、(社員コード, 社員所属組織コードor社員所属組織名)で一意に決まるので、キーにしなくて良い

• 社員役職名：2「役職名は重複しない」より、キーになり得るが、社員役職コードと同じで、社員所属スキーマのキーにならなくて良い

• 報告先社員コード：3-(4)「所属組織ごとに、報告先となる社員が高々1名決まっている」より、各社員の所属組織ごとに一意なので、キーにしなくてよい

• 報告先社員氏名：3-(1)「同姓同名の社員は存在し得る」ので、キーになり得ない

以上より、社員所属スキーマ（社員所属表と云ってもOK）の一行を特定する（一意に決める）には、（社員コード, 社員所属組織コード）か（社員コード, 社員所属組織名）を複合主キーに設定します。

設問1(2) | 3種類の関数従属性「完全/部分/推移的」

正規形の判定なので、各項目の関数従属を見れば良いですね。

関数従属性を図示する

関数従属は、ある項目で別の項目が決まること。

3種類あります。

• 主キーから決まる（完全関数従属）

• （複合）主キーの一部から決まる（部分関数従属）

• 主キー以外から決まる（推移的関数従属）

上図のように部分関数従属が残っているので、第一正規形です。

とはいえ私の解答は「主キーを社員コードと社員所属組織コード（または社員所属組織名）としたとき、社員所属組織名が社員所属組織コードに部分関数従属しているから」。「単一値」がないので×の可能性が高いです。

単一値でない時点で、非正規形が確定します。部分関数従属や推移的関数従属がなくても、単一値でない時点で非正規形です。

また、主キーが1つの時点で、第1正規形ではありません。主キーが1つなので、主の一部に部分関数従属するわけないので。非正規形でなければ、自動的に第一正規形を満たし、第二正規形以降になります。

主キーだけに従属するように表を分ける

何となくで良いので、以下のように表を分けられたら「センスあり」です。

正直「部分的関数従属が～」とか考えてチクチクやっていると時間がありません。最初にズバーンと「こんな形かな」とできた方が良いです。

データベースは第三正規形を目指します。

第三正規形は、主キーから全ての項目が決まる状態です。

• 非正規形：繰り返し項目が残る

• 第一正規形：部分が残る（繰り返しを除いた）

• 第ニ正規形：推移的が残る（部分を取り除いた）

• 第三正規形：完全だけが残る（推移を取り除いた）

正規形で残っている従属性と、正規「化」で取り除く従属性がずれてるように見えるので注意を。例えば、部分関数を取り除くのが「第二正規化」、取り除かれた後が「第二正規形」で、推移的関数従属が残っています。残っていなければ自動的に第三正規形に移行します。

あと地味に「計算できる値」を消す、のも含まれます。例えば、商品の「単価」と「個数」が分かれば「支払金額」が分かりますよね。よってデータベースに「支払金額」の項目を設ける必要は「本来は」ありません。

しかし、毎回計算するのが負担である場合、「価格」が変動する場合などがあるので、「支払金額」をあえて残す/設けることはよくあります。第三正規形を「敢えて」崩すことはよくあります。このあたり、過去問を解いていると分かるようになります。

階層構造エンティティの王道

組織所属表の正規化を仕上げていきます。

2番目の社員所属組織、3番目の上位組織は、1つの組織表で表現できます。

ER図のリレーションを自分にループさせるのは「階層構造」の王道です。

問題文の「1-(2)組織は、階層構造であり、いずれか一つの上位組織に属する」の時点で、スキーマの組織（組織コード, 組織名, 上位組織コード）を、パッと思いつくようにはってください。

データベースには「型」があります。

例えばER図で、発注→発注明細と「1対多」になってますよね。1回の発注で複数の商品を発注しますから。同様に、入荷→入荷明細、発送→発送明細。主キーは発注（発注番号）、発注明細（発注番号, 明細番号）ですね。

発注・入荷・発送との関係は、状況によって少し変わります。

問題演習をしたらER図の形、スキーマの表名・項目名をよく見てください。よくある形、よくある名前が分かります。その後、よくまとめられたテキストを読むと理解が進みます。＞DBの学習法Note

私は、問題文を読んで最初から、組織・役職・社員・組織所属の4つだと思っていたので、図2の社員所属スキーマを見て「おいおい」、設問1の正規化を見て「はいはい。ですよね」と思ってぐらいです。