DBゼミの第1回発表の内容は，
からなります．
試験でデータベース設計を問われているのであれば，ER図ひとつで答案とせざるを得ないこともありますが，DBゼミ，そして後々の研究や仕事において，「図をひとつ描いたら終わり」ということはありません．
どんな考えからその図を描くに至ったか，説明することが不可欠です．この「考え」ひとつで，見聞きする人の課題に対する印象が変わりますし，実装にも大きく影響します．「着想」あるいは「(基本的な)アイデア」ということもありますし，「設計思想」「デザインコンセプト」と呼ばれることもあります．どのようにその「考え」を導き出せばいいかというのは，また別の機会に．
そのほかに，ER図の中に直接書くことができないけれど，データベース構築やシステム実装に不可欠な情報も，少なくないはずです．その情報があるとないとで，見聞きする人の印象が変わりそうなら，それを班(設計者たち)の中だけで持っておくのではなく，早い段階で提示し，批評を浴びるほうがいいでしょう．
設計をするときに「実体の数」や「ひとつの実体が持つ属性の数」が気になる人がいるかもしれません．A4で1枚の図に収まらなかったら，詳細化のしすぎじゃないのか，とか．
たしかにDBゼミは，あらかじめ教員のほうで用意しておいた課題に取り組んでもらうので，その出題者は「ほどほど」のところを想定していて，過度に多かったり少なかったりすると，指摘が入るものです．しかし，ほどほどの数を見つけるというのは，間違ったアプローチです．
設計では，そこに書いたひとつひとつの実体や関連，そしてその中のひとつひとつの属性に，適切な役割を与えることを最重要視しないといけません*4．役割は，「責務」とも言います．責務は，設計する中で湧き上がってくることもありますが，それだけですべて出てくるとは限りません．
お勧めなのは，図を描き終わったら，課題文と照合することです．たいてい，与えられた文章と自分で描いた図の間には，ギャップがあります．そのギャップを埋めるために，キーワードを考えてみると，それが「責務」だったりします*5．
図と文の照合には，別の効果もあります．課題文*6で書かれていて，ER図にないものは，情報を追加しないといけませんし，逆に，ER図にあるけれども，課題文に書かれていないものは，削除するか，必要性を説明できるようにしておきます．このようにして，設計をより万全にしていくわけです．
*1:全参加者に，各班の課題を配布してはいますが，PowerPointに，課題文を書き写しておくほうがいいでしょう．
*2:「実態関連ダイアグラム」は間違いです．
*3:データベースの書籍で「ERD」と書かれていることもあります．Entity-Relationship Diagramの略ですね．
*4:『「概念設計」は「もののねらいをきめること」』，はてなより．
*5:「責務」に限りません．大学の成績管理を例にすると，履修と成績確定とでタイミングが違う(履修時には成績はつかない)ことに注意して，人やシステムがどのように関わるかを時系列で表現できるはずです．これは「筋書き」と呼ぶべきでしょう．
*6:前回，「隠された課題」を挙げましたが，隠された課題を合わせて提示するのなら，「課題文+隠された課題」とER図とを照合します．隠された課題は，与えられた課題文よりも流動的であることを忘れずに．
