１．データベース設計論の授業内容
＜第一回：ＥＲダイアグラム（IDEF1X)＞
(1)前置き
１つの本だけで覚えようとしないこと。用語も概念も混乱しているので複数の本を読んで理解を深めて欲しい。例えばある本で「機能依存」という用語が出てきて、何の事かわからなかった。説明を読むと、関数従属の説明をしているように思えた。考えると関数従属は英語で「Functional Dependency」だからそれを誤訳しているのに気付いた。英語にはRelation/Relationship／Associationという３つの似た概念の言葉がある。日本語には関係／関連と訳しているが、３つの概念を２つの言葉で表現しているので混乱しやすい。
(2)リレーショナルモデルとは
・データを表（テーブル）で表現。表の事を数学的には「関係(Relation)」と呼ぶ
・主キー、候補キー、代替キー、外部キーの説明
→ ｛候補キー｝＝｛主キー｝Ｕ｛代替キー｝
・関数従属(Functional Dependency)、多値従属(Multivalued Dependency)、相互従属(Mutual Dependency)の説明
・外部キー制約、ＮＯＴ ＮＵＬＬ制約、ユニーク制約
・正規形 →正規化の目的は「Ｏｎｅ ｆａｃｔ ｉｎ Ｏｎｅ ｐｌａｃｅ！」
(3)データベース設計
・「DATABASE SYSTEMS」という1200頁ほどある米書を元に説明する
・概念設計・・・使用するデータモデルも意識せずに＜要求仕様策定前＞
・論理設計・・・データモデルを特定して＜要求分析～設計の初期段階＞
・物理設計・・・実装依存＜実装設計フェーズ＞
(4)ＥＲＤ－ＩＤＥＦ１Ｘ
・ＥＲＤの流儀にはいろいろある
→IDEF1X,P.Chen,J.Martin,Visio,UMLクラス図をまねたERD・・・
☆Visioってツールが出てくる事で単に書式の事だとわかります
・IDEF1Xの書き方の説明。ここは相当詳しい。
☆ただ、「読み方」は教わるが「作り方」には何ら言及がない
・まとめとして、真野正氏の「実践的データモデリング入門」の表を引用されています
☆この本は単なる書式であるIDEF1Xを苦労してDOAの方法論として説明されているのに無視して講義されているのが残念です。
＜第２回：設計演習＞
(1)簡単なERDの例として、大学の履修の例を出されます。
「学科」には「教員」が所属しています
独立して右下に「科目」があります。
「科目」には、単位数や配当年次などの属性があります
「学科」「教員」「科目」を外部キーに持つ「授業」があります
「学科」には「学生」も所属しています
「学生」が「授業」を「履修」します
・このERDでは簡単すぎて、現実のデータを表現できません
(2)「大阪IT大学 履修申請システム」の要件を説明されます
☆全部は書けませんので、ややこしい条件だけを書きます
・年次カリキュラム：入学した年次によってカリキュラムが決まる
→カリキュラムとは、科目の配当年次と進級／卒業要件等がセットになったもの
→数年ごとにカリキュラムが変更されるが入学時点のカリキュラムは変わらない
・科目の読み替え：廃講になった科目を類似科目に読み替えて旧科目の単位とみなす
・先修科目：科目を履修する条件として別の科目の単位を持っている事
・複数授業があった時の履修可能条件
J学科とS学科がある。それぞれの学科内でＡ組とＢ組に分かれている
Ｊ学科２年次配当の授業は火曜の２時限と３時限にある。
Ｊ学科２年次のＡ組は２時限、Ｂ組は３時限しか履修できない
Ｊ学科３年次以上は２時限３時限のどちらも履修できる
Ｓ学科の２年次以上は２時限３時限のどちらも履修できる
・科目IDは異なっていても科目名が同じ科目は複数履修出来ない
☆この条件が特に難しいです
→2006年度カリキュラムの「日本史」と、2002年度の「日本の歴史」は同じ授業
１つの授業を構成する（カリキュラムと科目ID）の集合が決まると、この中の各（カリキュラムと科目ID）に対して履修可能学生集合が決まる
(3)システム機能
学生番号を入力すると、その学生の履修可能科目が入った時間割を表示するシステムを作るときのデータモデルを設計しなさい。
＜第3回：設計事例＞
このブログを読んで下さってる方でこの事例を真面目に一からされる方はいらっしゃらないだろうと思いますので、ちょっとだけ答えを載っけちゃいます。ご了承ください。
・エンティティ候補と関連を引きながら試行錯誤して作る手順を示されます
☆おそらく講師の方は後付けで作られているように感じます
・主キーベースのモデルとしてこういうものが提示されます
☆「授業」と「開講枠」のN:M関係はこの後1:Nに解消されます
・本物の業務のIDEF1X表記だともっと複雑怪奇です。
これだけでも読みにくい事はわかってもらえると思います。IDEF1Xで書いてしまうと、リソースとトランザクションの違いや業務の流れなどの「ストーリー」が消えてしまうためです。
・例えば、こんな部分も気になります
履修・成績エンティティの主キーに学生番号とカリキュラムIDが同居しています。 カリキュラムIDは学生番号から一意に決まるものですから、継承属性です。渡辺式なら（カリキュラムID）と書くべきところです。
学科と科目に何の関連もなくて良いのでしょうか
２．渡辺式では？
若干簡単な例ですが、「業務システムモデリング練習帳」の中に科目履修管理システムの例が載っています。入学年度のカリキュラムという概念がありませんが、参考になります。
チャレンジされるなら、XEAD Modelerをダウンロードして、是非渡辺式でチャレンジして下さい。この本のモデルは、CONCEPTWARE/科目履修管理でダウンロードする事が出来ます。
以上