【デスペ合格必須】ER図のパターン【図解12枚】
このNoteには「デスペのER図問題に役立つパターン」を、図解でさくっとまとめました。
私がデスペを勉強していた時に「こんなつなげ方があるなんて!」「これがデスペ本にも載ってたパターンか、なるほど」と思った経験からまとめました。また全ての過去問のER図を見て総ざらいもしました。
APまではリレーションといえば「1対1」の「ー」、「1対多」の「→」だけでしたよね。
デスペ違う記号も使いますし、自分に返したり、2本引くなど、「そんな書き方あるの!?」から学習が始まります。
過去問演習でER図をたくさん書きますが、1/3以上は典型的なパターンで解決するので、得点を稼ぎ・時間を節約する効果があると思い、まとめました。
このNoteは、私が独学合格した経験と、IT専門学校での授業のノウハウで書いています。合格のお手伝いに少しでもなったら嬉しいです。
それでは始めましょう!
「区分」と「フラグ」
まずは△記号。
なお、サブクラスのスキーマ(表)を別途設けるかは、データに依ります。
サブクラス固有のデータを記録するなら新設します。
例えば上図の「有料会員」は新設しなくても良いかも。会員表に有料フラグ(会員区分)で「有料」「無料」を記録すれば良いので。
もし、有料会員だけポイントが付与されるなら、「有料会員」表を新設して「ポイント数」を記録する必要が出てきます。
明細表は「1対多」
受注表は受注日時・受注した企業などの全体的な情報。明細表には商品名・個数・単価や小計などの個別情報を記録します。
項目名は大抵「明細番号」です。
「発注明細番号」と書いても良いですが、単に「明細番号」としても大丈夫です。ただし別の表で外部キー参照する時は「発注明細番号」と「発注表の明細番号」だと分かるように書いて下さい。
例えば、入荷表(入荷番号, 明細番号, 発注明細番号)。2番目の明細番号は入荷明細番号を意味するので省略して良いですが、発注明細番号は別の表の項目だよ、という意味を持たせます。
受注・受注明細と発送・発送明細
問題は、受注・受注明細と発送・発送明細の個数対応。
基本形は受注明細-発送明細と「1対1」。発送明細の主キーは、(受注番号, 明細番号)の複合主キー。
ただし「準備出来た順に発送」だと「1対多」に分けます。
業務を連携するスキーマ間では、個数対応は注目ポイントです。
なお、明細番号が吸収するので属性追加は不要です。発送明細の主キーは、(受注番号, 明細番号)の複合主キーのままです。
とはいえ、問題文に書かれた仕様次第なので、その場で慎重に考えてください。具体的なデータを入れると分かりやすいですよ。
連関エンティティ
APでもDBでも「多対多」「⇔」は絶対にあり得ません。
模範解答を見直してみてください。絶対にありません。
電子工作キットや食品プレート(Aセット, Bセット)など、商品をグループ化した時にも、よく見かける形です。
連関Eは、上図のような両側から挟むよりは、下図のように縦に並べる形をよく見かけます。
もちろん横並びで解答しても正解です。
もしリレーションを補う時に、上2つ下1つで並んでいたら「↓2本かな?」と疑うぐらいの気持ちでご紹介しました。
階層構造は自己回帰/連関エンティティ
自己回帰は良く使います。
階層構造が出た時に、最初に考えてください。
2本引く場合は連関Eと考え方は同じで、自分自身に多対多でリレーションする場合などに使います。
まずは親子関係で自己回帰を使わなかった場合。
次は実際に午後2で出題された形。
番外「こんなのもあるんだ!」
過去問解答をパッと見て「これは初見では発想できないかも」と思った例を2つ追加しておきますね。
私も問題演習してた時に「こんなつなげ方するんだ」と何度もヤられました。そうやって覚えていきましたね。
「まさか自己回帰を2重にするなんて」「分類したサブクラスは無関係だと思ってたのに」なんて、びっくりしますよね。
まとめ
お疲れ様でした!
以下を図解で紹介しました。
組織や会員周りは自己回帰
受注と受注明細の1対多
受注と発注の個数対応
キット/セット商品のグループ化
二重回帰に二重リレーション、
スキーマ(表, 項目)が完成していれば、主キーと外部キーを基にリレーションを繋ぐか決めて、問題文や一般常識から個数対応を考えれば良いですからね。
あなたのDB合格に少しでも役に立てたら嬉しいです。
でわでわ。
p.s. 普段は >> 専門学校とIT就職のブログ << をやってます。
でわでわ(・ω・▼)ノシ