【一緒に解こう】デスペ令和4年秋午後1問1（図解59枚, データベーススペシャリスト）
このNoteでは、DB令和4年秋PMI問1の解説をします。
データベース設計の問題では、問題文からスキーマとER図を完成させる手順が必ず含まれます。
私は、他の試験とは違う手順で解いています。
普通は問題文読んで→設問解いて→問題文読み進めて→設問解いてのループですよね。
私は、データベース設計問題では設問を見て、スキーマとER図の完成であれば、まとめて解いています。理由や権限を問われている設問である/ないだけ確認はします。
このNoteは「データベース設計を解く解説の決定版」として作りました。私が本試験で一文一文読んで、どう考えてスキーマとER図を完成させて行っているかが全て分かるように書きました。
図解も59枚。問題文のどこに注目して、スキーマとER図のどの部分に使ったかが分かるようにしています。
読むのに時間がすごくかかりますが、一度私と一緒に解いてみませんか？こんな解説は90分授業でもできませんし、二度と書くことはありません。このNoteが最初で最後。決定版です。
それでは一緒に始めましょう！
私の4ヶ月の勉強法に興味が出たらどうぞ。私が独学合格した経験と、IT専門学校での授業内容を基に作っています。
設問1 | 問題文からスキーマを完成させる
まずは基本から行きましょう。
スキーマ名、項目名、キーや個数対応の記述にマーキングをします。
主語や「〇〇という」は、スキーマ名（エンティティ名）になる確率が極めて高いです。四角で囲みます。
→「CC要員」ですね。その後、どんな情報を記録するかが書かれます。項目（属性）になるので、同じく四角で囲みます。
→「社員番号」「氏名」ですね。またキー制約や個数対応の言葉も書かれる場合が多いです。丸で囲みます。
→「識別」より「社員番号」が主キーだと分かります。
スキーマや項目名は、問題文の言葉をそのまま使って大丈夫。ただ、外部キーの時に少しアレンジをした方が良い場合があります。
例えば、社員（社員番号, 上司社員番号）。上司社員番号が外部キーで、社員表の主キー社員番号を参照しているのですが、分かり易くするために「上司」を追加しました。社員（社員番号, 社員番号）って分からないですからね。
下図は組織の階層構造を表現した場合。＞デスペのER図パターン解説Note
スキーマの構成は以下。
スキーマ名（エンティティ名、表名）
項目名（属性名）
主キー ※複合の場合アリ
外部キー ※複合の場合アリ
その他（特に役割のない項目）
ただし、DBでは「区分」「フラグ」も出題されます。
上図のようにスキーマが作れるのは分かったでしょうか。表名、項目、主キーは必ず特定します。外部キーも予想はしますが、後々仕上げるでもOKです。
さて(3)にて「SLPとASPがある」旨から「区分かフラグを使うだろうな」と予測もします。「SLPかASPなら区分」、「SLPでもありASPでもあるならフラグ」です。
(3)②でフラグだと明記されていました。もし明記されていなくても、「委託企業にはSLPとASP業務があり、契約内容で片方だけでも両方でも委託できる」のような記述が書かれるはずなので、区分かフラグか判断してくださいね。
さて、情報の拾い出しをしましたが、未解決な文言もあります。
未解決な文言には▼印をつけておきます。後で、スキーマやER図を完成する段階で使うかもですし、データーベース改良の焦点になるかもしれませんから。
ここでは「EUって表も作りそうだな」「問合せって表も作りそうだな」「サービス地域って表も作りそうだな」「しかもサービス地域と企業の個数対応がER図リレーションに絡んでくるだろうな」と考えて「とはいえ現段階では解決できない」ので▼印をしておきます。
複合主キーの登場です。
「ASPごとのCE番号」とは、「ASP-A社のCE-001番、ASP-B社のCE-001番のように使う」というメッセージ。つまりCE番号だけでは一意に特定できない状態。よって、ASPを特定するBPコード、あるASPに所属するCEを特定するCE番号の2つを主キー（複合主キー）に設定します。
次のEUスキーマは、今までの解法で充分対応できます。
今回はEUスキーマは穴埋めになっておらず答えが書いてありました。もし穴埋め問題になっていた場合の話をしますね。
「住所から定まるサービス地域」の文言から「サービス地域コード」なり「地域番号」なり勝手に命名して大丈夫です。
データーベース設計では、しばしばスキーマ名（表名）や項目名を自分で作る時もあります。
スキーマの設計は、後の文章を読んで追加や変更など修正する場合もあります。問題を読みながらスキーマを作っていきますが、仮決めだと思ってください。
2(1)で「製品」スキーマを設計しましたが、2(2)によって「製品シリーズ」スキーマと紐づける必要が出てきました。よって「製品」スキーマに外部キーとして「製品シリーズ」の主キー「製品シリーズコード」を追加しました。
なお製品シリーズに製品コードを外部キー設置する解はないです。なぜなら、「1つ」の製品シリーズには「複数」の製品が属するので。
登録製品スキーマの設計については、まったく問題ないですね。
しかし少し疑いが残る表現がありました。「EU（製品利用者）の氏名・住所・電話番号が変更されたら更新する」旨に引っ掛かりを感じてください。
データベースの情報を変更する時、変更前の情報を残すか消すかは重要問題です。
例えば「価格表」の「価格」項目。価格が変更されたら「価格」項目の値を変更するのは勿論ですが、旧価格の情報は残さないで良いかはケースバイケース。昔の取引を分析したい時は、旧価格の情報が必要になりますからね。価格（商品コード, 価格, 設定開始期間）にして、主キーを商品コードと設定開始期間にする場合も考えられます。
他にもポイント制度の場合。会員の所有ポイントを記録するのは勿論ですが、ポイントをいつ得たか・いつ使ったかの記録も必要ですよね。
このように、前情報を消して上書きして良いのか、今までの履歴を残さなくて良いのかは考えます。
今回のEUについては「旧情報はまぁ残さなくて良さそうな情報だけど、一応▼印しておくか」とマーキングして次に進みます。
項目に具体的に入る値が明記されることもあります。
設計には特段影響はないのですが、後で使う可能性・理解を促す仕掛けの可能性も含めて、▼印をしておきます。スキーマの設計で使わなかった情報が残っているのが気持ち悪いのです。
問合せスキーマを考えます。項目数が結構多くなってきましたね。
スキーマ名、項目名、主キーは問題ないですね。
「EUとは関連付けない」旨は、今はキョトンとしますが「ER図で繋げない」「EU番号を外部キーにしないんだな」と解釈します。一応▼印しててもOK。マーキングは、やってメリット、やらなくてデメリットなので。
なお、模範解答では案件番号も含まれていますが、この段階ではまだ分かりません。後になって追加します。
少し慣れてきた頃なので、次からはER図も見ていきます。
データベース設計は、最終的にスキーマとER図が完成していれば良いのです。スキーマを完成させてからER図作成するのがシンプルですが、両方をえっちらおっちらと進めても構いません。
2つの文言から、通話かWeb問合せの排他的サブクラス（二股になる△）、Web問合せではSLP経由の場合があることから共存的サブクラス（股にならない△）を使う、と推測できるようになってください。
そしてサブクラスを別表にする場合。今回なら、問合せ表とは別にWeb問合せ表と通話表を作る場合。問合せ表に「区分」項目が必要なはずです。
なので前の3(3)の「媒体区分」が使われるんだなと理解できます。
もう一つのSLPweb問合せであることを示す「フラグ」は、後ほど3(6)ぐらいで「SLP製品使用者入力区分」という項目を自分で命名して追加します。。超ムズイですね。
3(6)には表明などの情報はなかったですが、「SLweb問合せにBPコードを含めておくんだな」と予測できます。
では、問合せ表はまぁまぁ完成したので、Web問合せとSLPweb問合せを作っていきます。
ポイントは、各エンティティに特有の情報があるかです。
「Web問合せ独自に記録すべき情報はあるか？」
「SLPweb問合せに独自に記録すべき情報はあるか？」
「Web問合せ独自に記録すべき情報はあるか？」
→SLP経由の問い合わせか違うかの区分、が必要「SLPweb問合せに独自に記録すべき」
→SLPを特定するBPコード、が必要
SLP製品使用者入力区分は、「SLP経由の問い合わせ」「SLP経由してない問い合わせ」を区別する項目です。
命名は難しいかもですが、採点者に伝わる表現なら良いです。
私なら「SLPWeb問合せフラグ」にしそうです。
次、SLPBPコードは、「Web問合せの時に経由したSLPのBPコード」である旨が伝われば良いです。
実際参照するのは、SLP表のBPコードなので、単に「BPコード」でも行ける気するのですが、やはり「SLPのBPコード」ぐらいは書いておきたいです。
単にBPコードでは、BP表のBPコードを参照するように思え、ER図でもBPエンティティとSLPWeb問合せエンティティをつなぐと誤解されます。SLPエンティティとつなぐと分かるように書くのが「設計」ですよね。
特段問題はないです。「フラグ」もあるので「股のない△」を使うのも、もう慣れましたね。
あとは「通話音声」を項目名にして良いのかは迷います。とはいえ、通話音声を項目に追加しない、という理由も全くありません。項目で実現する術を考えます。
「音声データである通話音声を記録している」をどうデータベースで実現するものかと考えました。
私なら「通話音声ファイル名」にすると思います。項目名が「通話音声」って正直何が記録されているのか分かりませんよね。音声データをデータベースにINSERT文でぶち込むわけないですから。
発信通話スキーマを考えます。
私はこれは失点します。というか、たぶん設計が間違っています。
一応、解答を見てから解釈すると、発信通話には2種類あり。
通話問合せへの回答のための発信通話
Web問合せへの回答のための発信通話
なので、発信通話にどのWeb問合せかを特定するために「発信元Web問合せ番号」を外部キーとして追加しています。
とはいえ、たぶん間違いです。
問合せEの問合せ番号で、全ての問い合わせは一元管理されているため、通話発信スキーマの問合せ番号だけで充分である。
模範解答ではWeb問合せEと通話発信Eが1対多なので、発信元Web問合せ番号を追加しただろうが、両Eの主キーは問合せ番号1つだけなので「1対多」が実現できない。やるなら通話発信Eの主キーが「問合せ番号, 発信連番」の複合主キーならまだ分かる。
以上のように、問合せ番号で特定できる点で発信元Web問合せ番号の追加は不要、1対多が実現できないのでそもそも設計が間違っている、と私は考えています。
補足は、このNoteの最後にします。
ひとまず試験では、「Web問合せに回答するために電話するから、Web問合せEと通話発信Eを繋ぐから、ER図では繋げて、通話発信Eに外部キー追加しとこ」ぐらいで留めて、次へ行きます。
今までの設計が上手くいっているので、この問題に深く立ち入って時間が厳しくなるよりは、多少解答が甘くても8～9割は取れていると考えて、次へ進みます。
間違っていれば、全部設計し終えた時に矛盾が出るので、また戻って考えれば良いですから。
問合せと案件の関係が書かれていたので、問合せスキーマに案件番号を外部キー追加して、紐づけます。
この文章ぐらいではまだ「案件番号を追加するだろうなぁ」ぐらい。「この後、明記があったら良いなぁ」と思いつつ「9割方、追加するだろう」と考えて進めます。
「登録Eに案件番号を、9割方、追加するだろう」でしたが、4(1)に明記がありました。ラッキー。
案件スキーマの設計も問題ないですね。「登録製品と関連付ける」旨から、登録製品スキーマを見返して「製品製造番号」が必要だと分かればOK。
話が問合せへの登録と対応から、実施サービスに移ります。出張手配スキーマを設計します。
大きな問題はないですが、「案件に対して1回行い」など個数対応に絡む文言には反応します。
出張手配スキーマの主キーの話。今回も案件番号と書いてくれてるので良かったですが、もし穴埋めだったら考える必要がありますよね。
出張手配の主キーを決めるとき、出張年月日や出張時間帯では役不足。「出張番号」を追加しても良いですが。「案件に対して1回行う」から、「案件番号と紐づけるんだから、外部キーとして追加するし主キーに流用もできるなら効率いいじゃん」と考えます。
特段、出張番号の新設が必要ではないので、出張番号は別解にはならない確率が高めかなと思います。
出張手配はいわば予定、実際に行った情報は出張実施スキーマに記録されます。
ひょっとしたら実施年月日と実施時間帯を追加するか迷うかも。出張手配で年月日と時間帯を記録しましたからね。でも問題文に忠実に行きましょう。
また「出張手配と実施で日や時間が違う」可能性もあると想像もします。修理は1日に何件もするので、前の現場での作業の終わり具合で時間が前にも後にもずれるでしょうから。
出張実施に「担当BPコード, 担当CE番号」の両方が必要な理由は、CEスキーマの主キーが「担当BPコード, 担当CE番号」の2つだからです。CE（エンジニア）は、BP-A社のCE-001番、BP-B社のCE-001番のように、CE番号だけでは特定できませんから。
外部キーを複合で追加することもある、と学びになりましたね。
アフターサービスの実施記録の設計です。
スキーマ名や項目名に問題はないのですが、主キーについて明記がなく、注意が必要でした。
ER図を見ると「1対多」になっていて、出張実施の主キーが「案件番号」なので、AS実施記録の主キーは「案件番号, 何か」になります。
実は、MTコードについて2(4)に記述があります。「動作確認、分解点検、ユニット交換」に対応するコードです。（実際の文字列は、点検修理項目スキーマに記録されています）
確認→分解→交換と症状に応じて対応が進行していることから、「確認してダメだったら、分解、だめだったら交換」と段階なので、主キーに使える、と判断…できないですよね。解答をみれば「そうでも良いけど」ぐらいの間隔。
「確認・分解・交換作業が各1回しか行わない」旨の記述がないので、私は間違うと思います。それか「AS実施明細番号」を追加すると思います。
発信通話の時と同じくそこそこの対応で手を退きます。「ER図で1対多だから案件番号とMTコードの複合主キーにしとくか」程度。
設問1 | スキーマからER図を作る
スキーマが完成したので、ER図を完成させます。またはER図を見てスキーマに修正をすることもあります。
リレーションの判断は2種類あります。
繋げるかは外部キーで判断
個数対応は問題文、なければ一般常識で判断
CC要員には外部キーがないので、今のところリレーションは繋ぎません。他のエンティティから、社員番号が外部キー参照されていた時に繋ぎます。
SLPフラグ、ASPフラグの個別「股なし△」について。もし問われたら、問題に文に「BPにはSLPでありASPである企業もあっても良い」旨が書かれます。今回はも元々引いてくれてるので問題文にも明記がなかったです。
またSLPとASPに外部キーはないのでリレーションは発しません。
ASPとCEについて。
外部キーを見たら繋ぐことに問題はないですね。個数対応は「そりゃ1企業に複数人社員さんいるでしょ」で1対多。
ASPからサービス地域に繋ぎます。
個数対応は問題文に「複数の地域を1社が担当」の旨から「1対多」。個数対応には丸印をしてくださいね（図解では便宜上、橙四角にしていますが）。
EUからサービス地域に繋ぎます。EU（利用者）はお客さんなので、1地域にたっくさんいますよね。「1対多」。
製品シリーズは、複数製品をひとまとめにしたものですね。「シャープのアクオスTV」とか「スマホのiPhone」など、シリーズ内に色んな製品があります。
ブランドやカテゴリーでも同じような構造にします。自己回帰することもあります。
例えば以下のような実現方法があります。＞DBAMII：ER図の個数対応の解説Note
製品EとEUエンティティを考えます。
外部キーを見て繋ぎ、一般常識で個数対応を考えます（明記がないので）。
点検修理項目Eから発するかは、外部キーがないので判断しません。
問合せEについて。媒体区分があるので「股あり△」。
問合せEのについて2つめ。案件番号が外部キーなので、案件Eと繋ぎます。
問題は個数対応「1対多」。私は失点します。
問題文に「複数の問い合わせを案件にする」旨がありません。「問合せを案件化する」の記述では、1つの問い合わせで修理点検が必要なら、1つの案件にする、と解釈されます。
ごめんなさい。なぜ「1対多」なのか分からないです。製品の大規模リコールとかなんでしょうか。多数の問い合わせが、特定製品の動作不良の案件に集約できる、みたいな。
問題文から「1対多」と解釈できる記述がありません。私は「1対1」で繋いで次に進みます。
Web問合せのうち、SLP経由の問い合わせ（SLPweb問合せ）があるので、「股なし△」で結ぶのは良いですね。
SLPweb問合せEについて。BPコードが外部キーなので、リレーションを発しましょう。ただし「問合せで経由したSLP」なのでSLPエンティティと繋ぎます。個数対応は常識で、1企業にたくさん問合せくるでしょうと「1対多」。
通話Eにて、対応したカスタマーセンターCCの社員と紐づけます。
通話Eの通話成立フラグについて。
通話成立/不成立でサブクラスを作るわけではないので、特に変更はありません。
通話Eの受発区分について。発信の場合は、発信通話Eにも記録することから「股なし△」が繋がれています。
Web問合せに回答するために電話をかけるので、発信通話と繋ぎます。
相手に繋がらないなどがあるから「1対多」…なんだろうと思って繋ぐし、模範解答も「1対多」なんですが、たぶんこれも間違ってます。発信通話スキーマの設計時にも書いた通り、このNoteの最後に補強します。
登録製品Eには外部キーはないので発しませんが、案件Eに外部キーがあるので繋ぎます。修理点検案件になる製品（個々人が所有）は多いですから「1対多」。
設問2 | 問題文, スキーマ, ER図を見ながら完成させる
今問題文→スキーマ→ER図が基本手順。スキーマやER図が白紙でも、問題文に必要な情報全てが載っていれば完成できます。
よって上記では、基礎固めのために、ER図→スキーマなどは極力控えました。
とはいえ、スキーマやER図は部分的に完成しているのでヒントになりますから、3者を交互に見て完成させるのが実際の解き方です。
ここでは「問題文→スキーマ→ER図」は基本としつつも、完成済みのスキーマやER図も活用して解いていきますね。スキーマとER図を同時に作れるよう慣れてみましょう。
データベース設計問題では、一度目の設計をして、二度目で改良や追加をするのはよくある出題パターンです。今回は追加系、そして一度目を一部流用しています。
個人的には追加系は、一度目の設計の尾を引かず、再度ゼロから設計なので解きやすいですし、得点も取りやすいと感じます。一方、改良系だと色んなところを矛盾なく改変して、今までの動きも阻害しないか確認する必要があるので、面倒を感じます。
ユニットスキーマを作ります。特段問題はありません。
一度目に設計した「製品シリーズ」と今回設計した「ユニット」の絡みです。
「あ」を選んだのはユニットに一番近いから。問題文の最初に設計するのだから「あ」や「a」絡みだとメタ読みもしたからです。
「あ」だと決定的に判断できる文言がないので、可能性のあるところにとりあえず入れて様子を見るしかありません。
「あ：製品シリーズ」と「ユニット」を結んでも良いのですが、「あ：製品シリーズ」からaに繋がっているし、ユニットからaにも繋がっています。しかも「1対多」で。
aが連関エンティティであるかを、具体例（スマホや液晶パネル）を考えて判断しました。
連関エンティティのキーが複合主キーなのは、相変わらずです。
次は「機能部品」スキーマを作ります。問題はありません。
なお「要機能部品」と名前がすでに決まっていました。もし空欄だったら「機能部品」で構いません。
「要管理機能部品」は「ユニット」と絡むようですね。
そして「ユニット」はbに繋がっています。「この形はbが連関エンティティかもな」と仮定して理由を裏付けします。
「機能部品は、複数ユニット」より、ER図にて「ユニット←要管理機能部品」と「多対1」に繋げそうなのに、ユニットがbに繋いでいるんですよね。そこで、1つのユニットから機能部品を見たら何個に見えるかを考えて判断します。
まぁER図の3者の配置から、連関エンティティの可能性が高いですが。
FAQ（よくある質問）のスキーマを作ります。特段問題ありません。
「要点検修理FAQ」の他エンティティとの関係についての記述でした。
「い」が「点検修理項目」エンティティであると、問題文から分かります。そして既にfに繋がっている様子から、fが連関エンティティと分かります。fの主キーが複合主キーになるのはもう大丈夫ですね。
なお、ここでユニットから繋げておきましょう（黄緑）。忘れてしまいますから。
「関連FAQ」を作ります。
1つのエンティティに1対多を2本繋げる形は、分類系によく見られます。階層構造なので自己回帰で組みたいけど「多対多」の場合です。＞デスペのER図パターン解説Note
今回は、FAQエンティティにあるFAQ、それに関連するFAQは、やっぱりFAQエンティティにある、つまり自分自身になるわけです。
FAQエンティティからFAQエンティティにリレーションを引く解もあり得ました。
例えば、社員（社員番号, 上司社員番号）スキーマなら、社員→社員と自己回帰するリレーションを繋げます。＞デスペのER図パターン解説Note
しかし今回は、FAQと関連FAQが「多対多」なので、連関エンティティとして「e：関連FAQ」を新設して、2本つなぐ形になりました。
KWエンティティを作ります。特段問題はありません。
KWエンティティはFAQエンティティと繋ぐ必要性が問題文は語っています（橙）。少し難しいですが。
とはいえ、KWからcに繋がっている、またcの上に半分ずつ重なるように2つのエンティティが描かれている点から、連関エンティティだろうなぁと推測して考えます。
案件とFAQを繋げます。dを連関エンティティにしている繋がり方をしていますね。もういい加減、連関エンティティの組み方には慣れたかもですね。
補強 | 私が理解できなかった設計（Web問合せ, 通話, 発信通話）
「Web問合せ」と「発信通話」の「1対多」が実現できないのでは？という疑問から、実際の業務を考えて「発信通話」「通話」のスキーマもオカシイ疑問に発展しました。
よく見ると「通話」であって「通話問合せ」じゃないのもクサイ。
具体的にデータを入れて考えてみます。
もし電話問合せがあった場合、「問合せ」に登録され、「通話」にも受信で登録されます。
電話問合せに回答するために発信すれば、「発信通話」に記録されるでしょう。しかし「発信通話」の主キーが1つなので、通話が不成立だった時に再度発信したらどう記録するのかが分かりませんでした。
次にWeb問い合わせがあった場合を考えてみます。
まず「問合せ」に登録され、「Web問合せ」にも登録されます。SLP経由なら「SLPweb問合せ」にも登録されます。「通話」には登録されません。
Web問合せに回答するために発信したら「発信通話」に記録されるでしょうけど、通話内容や日時などの項目が「発信通話」にはありません。
通話内容や日時を記録したいなら「通話」に行くしかありません。
しかし「通話」に記録したら、問合せから2股にした意味がなくなってゴチャつくのが気持ち悪いと感じます。
もう1つ。模範解答では「Web問合せ」と「発信通話」が「1対多」です。
「1対多」を実現するには、以下のように「発信元Web問合せ番号」を違えるしかテがありません。しかし主キーが1つなので、問合せ番号を変える必要があります。
問合せ番号が違うなら、そもそも別物の問い合わせですよね。
ひょっとしたら「案件」と「問合せ」が「1対多」だったことが、問合せ番号が違えても良いことの影響かもとは思います。私の理解が至らずすみません。どうしても問題文から読み取れません。
最後に私が設計するなら以下です。
この設計では「通話問合せ」を作るのがちょっと無駄です。問合せ番号しかなにですから。しかし、「ER図にエンティティがあるから、必ずスキーマ（表）にするとは限りません」。忘れてしまったのですが、過去問でER図にエンティティあるけど表を作らなかったことがあったと思います。
「エンティティ＝表」が一番シンプルで良いですが、ER図は概念的な意味もあります。エンティティ＝表を敢えて崩して表を作ることもあり得ます。
まとめ
お疲れ様でした！
このNoteで、問題文のどこに注目して、スキーマとER図の設計に生かす方法が少しでも理解できたのなら嬉しいです。
あとは時間制限。今回は丁寧に読み解きました。過去問演習をして解く速度を速くしたり、端折ったりするなど、自分なりの工夫をしてみてくださいね。
私は午後2はフルパワーでやって時間ギリギリでした。データベース設計を解くのは面倒ですが、得点再現性が高いです。ぜひ一度考えてみてくださいね。
それではデータベーススペシャリストに合格してくださいね！
私が合格してきた勉強法についてもNoteにしました。まずは書籍の読み倒し方、AMIIの勉強だけでも参考にして頂ければ、嬉しいです。
p.s. 普段は >> 専門学校とIT就職のブログ << をやってます。
でわでわ（・ω・▼）ノシ
いいなと思ったら応援しよう！
