現在、SQLで初めてグリップを取得しようとしているため、いくつかの問題を解決しています。サンプルデータベースの仕様は次のとおりです。ERダイアグラムからSQLへの関係属性の変換
学生（名前、性別、コース）はプロジェクト（タイトル）です。各プロジェクトには、 の2人の監督者（名前、性別、部署）があります。すべての生徒はプロジェクト を実行しますが、すべてのプロジェクトが実行されるわけではありません。複数の学生が同じ プロジェクトを行うことができます。生徒は監督者の一人と定期的に会い、これらの ミーティングが記録されます（日付、時間、学生、監督、メモ）。
これまでのところ、私は私が正しいと考えているアップ描かれたER図を持っている：私は（例えば学生テーブルなどを作成）基本を取得することができます
が、私がいます関係を表現する方法、具体的には会議の関係、そしてSQLでその属性とその属性を表現する方法について頭を悩ませました。私は代わりに 'ミーティング'エンティティを作成する必要がありますか？
はい、StudentとSupervisorの多対多の関係を表すMeetingエンティティを作成する必要があります。そのテーブルでは、それぞれのテーブルに対応する外部キーを使用して、これらのテーブルに関連付けることができます。あなたはまた、ProjectとSupervisor間Superviseのために同じことをするだろう
Create table Meeting {
id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
student_id INT NOT NULL,
supervisor_id INT NOT NULL,
//rest of the fields...
FOREIGN KEY (student_id) REFERENCES Student(id)
FOREIGN KEY (supervisor_id) REFERENCES Supervisor(id)
}
：SQLでは、このようなものに見えるかもしれません。また、あなたのミーティングテーブルにコンポジットキーと呼ばれるものを使用することもできます。私はそれが個人的な好みになると思います。私はこれがあなたのデータベースに依存する構文であると言っているわけではありません、これは正しい方向にあなたを指す例にすぎません。それが役に立てば幸い。
また、あなたのダイアグラム（これはクラスのためだと思います）では、Visioや視覚的パラダイムなどのソフトウェアを調べてER図を作成することができます。ほとんどの人はあなたの現在の図を理解することができますが、それは正しいモデリングではありません。
は楽しみのために私はあなたのテーブルに基づいて図を作った：彼らは多くの関係に多くがある場合 
あなたはSupervisorとProject間のエンティティをしたいと思います。これはassociative entityと呼ばれます。私はSupervisorProjectというラベルをつけました。もう少し明確です。
編集 学生とプロジェクトが多人数であったことを見落として、申し訳ありません。
Cohagen this stackoverflow postに応答して、Superviseのような多対多の関係は、属性がなくても関係テーブルを保持することで表すことができます。対照的に、Doテーブルは多対1の関係にあり、属性を持たないので、学生のプロジェクトテーブルに外部キーリファレンスを追加するだけで済みます。
ERDを処理できるMacまたはiOSの汎用描画アプリケーションの場合は、[OmniGraffle]（http://www.OmniGroup.com/omnigraffle/）をご覧ください。 –
素晴らしい - 「監督」を実体にするメリットをもう少し広げることができますか？ – Cohagen