私は構築している学生ポータルプロジェクトの以下のデータベースを持っています。私はデータベースが初めてですが、私は概念をかなり知っています。私は私のダイアグラムで学生が部門に依存するように弱い実体であることを尋ねることはしませんでした。部門がない場合、その部門には学生はいません。学生はDBMSの弱いエンティティであるべきですか？
私の主な質問とは別に、出席と授業の表について少し混乱しています。私はそれらを正しく関連づけており、その属性は十分で正しいものですか？私は多くのことを尋ねていることは分かっていますが、私の図を見直して、ゼロから作ることができたとしても、それを改善するための示唆を提供できますか？おかげさまで
学生は弱いエンティティセットである必要はありません。弱いエンティティセットは存在依存関係を意味しますが、存在依存関係は弱いエンティティセットを暗示しません。通常のエンティティセットにも全参加が可能です。
存在の依存関係を見るのではなく、識別を見てください。脆弱なエンティティセットは、独自の属性だけでは識別できません。外部キー（通常は弱いキーと組み合わせて）によって識別されます。エンティティセットがRoll ID（代理IDは常に独立している）のような独立したアイデンティティを持つ場合、エンティティセットは通常のエンティティです。
おそらく、使用している表記法が異なるため、テーブルとエンティティセットを混同しているようです。あなたのモデルを正しく読んだら、Gradesは、StudentとCoursesの関係にあります。なぜなら、2つの外部キーからなる主キーを持っているからです。ただし、図はStudentの不要なhas関係を介してのみリンクされています。
テーブルにもリレーションシップが埋め込まれています（例： CoursesにはDepartment FKがありますが、図では2つをリンクしていません。 Enrollsには独自のテーブルが必要ですが、ダイアグラムの他の多対多リレーションシップとは異なります。
Attendanceは、Gradesのように、StudentとCoursesの間の関係を表します。 Departmentとの関連付けを表示しますが、FKを示すものではありません。オリジナルのER表記法では、外部キーを属性として指定することはありませんが、ダイアグラムではこれは他の表のほとんどと矛盾しています。
編集：
ここでは、StudentとCoursesとの間の関係としてGradesを表現する方法の例です。あなたの表記を実装するツールがないので、私は元のER表記を使用しました。示すように
出席テーブルは部署ないコースと学生にリンクされなければなりません。
コースと学生がすでにリンクしているときに、どのように参加することができるのか少し詳しく説明できますか？私は3者またはn元関係を視覚化することに失敗しています –
それについて考えるなら、学生はコースに参加します。実際には、コースとクラスが1対多の関係を持つ別のテーブルClassを持つ方がよいでしょう。たとえば、コースに合格するには、最低x数のクラスに参加する必要があります。もちろんコースは部局との関係が1対1になるでしょう。だから一言で言えば、出席 - >クラス - >コース - >部門 – Ezani
私は矛盾した表記法を使用していることを知っています。それは残念です。また、N：Mは混乱を解消した後に描画する別のテーブルが必要です。私は出席と授業が学生とコースに沿っているべきだと私は同意しましたが、私はそれを視覚化していません。どのようにダイアグラムをどのように再調整すればいいのでしょうか？私はどこでどのrealtionによって接続すべきか。 –
私は例を追加しました。 – reaanb
本当に助けてくれてありがとう！その答えを見たいと思っていた。 –