教師、科目、等級データベースの設計提案

Question

高等学校のデータベース設計作業の一環として、私はクラステーブルに固執しています。これまでに作成されたテーブルは次のとおりです：

Students 
-------------- 
Id 
name 

Grades (grade 1,2,....9,10) 
------------------ 
id  
description  
term 

Subjects (science,maths...) 
------------------- 
id 
name 

grade_subject (subjects tought in grades) 
---------------- 
id 
grade_id 
subject_id 

teacher 
--------------------- 
id 
name 

teacher_subject (teachers who are assigned to teach subjects in particular grade) 
--------------------- 
id 
teacher_id 
grade_subject_id 

私はteacher_subjectテーブルのテーブル設計について確信がありません。この表は、良いデザインではないかもしれないgrade_subject_idのIDを利用しています。このテーブルに2つのFK、1つのgrade_idとsubject_idが必要ですか？

また、特定の教師によって特定の科目や学年について行われた授業の数をさらに格納する必要があります。

は、この場合におけるこの表のフィット感になります。

Class (stores daily teaching schedule) 
----------------------------------- 
id 
*teacher_id 
grade_id 
subject_id* 

*or only teacher_subject_id from teacher_subject table* 

date 
start_time 
end_time 
status (conducted/cancelled/postponed)+ 

そして最後に、クラス

attandants 
-------------------- 
student_id 
class_id 

に出席者に関する情報を格納するテーブルの任意の提案をいただければ幸いです。

Answer 1

データモデリングを解決しようとしている問題に適用されることの芸術であります関係図で現実の世界を表しています。あなたのモードは正しいですが、それは本当ですか？

CLASSとは何ですか？教師、主題、学年です。それらはあなたの関係です。さらに、SUBJECTがその学年に適しており、教師がその学年のSUBJECTを教えることができるようなルールを適用したいとします。

あなたの問題は、交差テーブルの代理キーの使用にあると思います。これらは、多対多の関係を表す表です。teacher_subject、grade_subject。とにかくこれらは合成テーブルですが、キーだけで構成されています。したがって、複合主キーで十分です。

代理プライマリキーには意味がないため、grade_subject(subject_id, grade_id)に一意制約を定義して（ 'PHYSICS'、 'YEAR 2'）の2つのレコードがないようにする必要があります。 grade_subjectが他の列を持たない交差テーブルであるとすれば、代理キーを追加することは無意味です。サロゲートキーの価値は、変化するビジネスキーの影響を最小限に抑えることです。しかし、grade_subjectにはビジネスキーはありません。代理キーはsubject_idとgrade_idです。

これは、参照整合性の定義には利点があります。

だから私はこの方法で問題にアプローチします：

grade_subject 
---------------- 
grade_id 
subject_id 
primary key (grade_id, subject_id) 
foreign key (grade_id) reference grade (grade_id) 
foreign key (subject_id) reference subject (subject_id) 

teacher_subject 
--------------------- 
teacher_id 
grade_id 
subject_id 
primary key (teacher_id,grade_id, subject_id) 
foreign key (grade_id) reference grade (grade_id) 
foreign key (subject_id) reference subject (subject_id) 
foreign key (teacher_id) reference teacher (teacher_id) 
foreign key (grade_id,subject_id) reference grade_subject (grade_id,subject_id) 

Class 
----------------------------------- 
id 
teacher_id 
grade_id 
subject_id 
primary key (id) 
foreign key (grade_id) reference grade (grade_id) 
foreign key (subject_id) reference subject (subject_id) 
foreign key (teacher_id) reference teacher (teacher_id) 
foreign key (grade_id,subject_id) reference grade_subject (grade_id,subject_id) 
foreign key (teacher_id,grade_id,subject_id) reference teacher_subject (teacher_id,grade_id,subject_id) 

これは、外部キーのパイルアップのように見えることがあり、私は審査段階でいくつかの引数を想定することができます。 （私はgrade_subjectに外来キーを含めるので、私はあまり気にしないので、それを認めてくれる何かを認めている）。

しかし、私は、TEACHER_SUBJECTのような補助的な関係によって強制されることによって難読化されたCLASS_SUBJECTのような重要なデータ関係を持つことは好きではありません。 CLASSをSUBJECTに参加させるためにTEACHER_SUBJECTとSUBJECT_GRADEに参加する必要はありません。

ここで、後者が間接的に前者を強制するとき、単一の親テーブルと交差テーブルに参照整合性制約を含めることを選択したのはなぜですか？それはモデルのの関係をより明確にするためです。物理データベースでは、単一テーブルの外部キーを省略するか無効にするか、交差テーブルのリレーショナル・インテグリティを信頼するかを選択する可能性があるため、モデルに重点を置いています。

---

トリプルカラムのコンポジットについて、私はバグがあります。これは十分に正規化されていないと思います。特別な場合がありますが、より一般的なモデルはTEACHER_SUBJECTとTEACHER_GRADEという2つのルールになります。それでも氏ドゥルーリーだけあなたがTEACHER_SUBJECT_GRADEテーブルを必要とする第六フォーマに第四フォーマと物理学に数学を教えることができるルールを強制したい場合には、もちろんこの

teacher_subject 
--------------------- 
teacher_id 
subject_id 
primary key (teacher_id, subject_id) 
foreign key (subject_id) reference subject (subject_id) 
foreign keye (teacher_id) reference teacher (teacher_id) 

teacher_grade 
--------------------- 
teacher_id 
grade_id 
primary key (teacher_id,grade_id) 
foreign key (grade_id) reference grade (grade_id) 
foreign key (teacher_id) reference teacher (teacher_id) 

Class 
----------------------------------- 
id 
teacher_id 
grade_id 
subject_id 
primary key (id) 
foreign key (grade_id) reference grade (grade_id) 
foreign key (subject_id) reference subject (subject_id) 
foreign key (teacher_id) reference teacher (teacher_id) 
foreign key (grade_id,subject_id) reference grade_subject (grade_id,subject_id) 
foreign key (teacher_id,subject_id) reference teacher_subject (teacher_id,subject_id) 
foreign key (teacher_id,grade_id) reference teacher_grade (teacher_id,grade_id) 

ようになります。

---

データモデルで扱われないことの1つがスケジューリングの問題です。学校の時刻表は網に掛けなければならないので、クラスはあらかじめ決められたグリッドに収まる必要があります。おそらく、タイムテーブルのスロットを別のテーブルとして定義し、それにCLASSをリンクする必要があります。クラスには教室も必要です。それは別のテーブルです。

Answer 2

このモデルは、リレーショナル・モデルの作成方法を学習するときにデータベース設計者にとって典型的なものです。 は、このサイトを見てくださいサンプルのトンが含まれており、それらのいくつかは、あなたが

http://www.databaseanswers.org/data_models/

チェック部218教育