-1

高校のデータベース設計タスクの一環として、私はクラステーブルで立ち往生しています。これまでに作成されたテーブルは次のとおりです。

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

任意の提案をいただければ幸いです。

4

2 に答える 2

0

このモデルは、データベース設計者がリレーショナルモデルの作成方法を学び始めるときに一般的です。このサイトを見てください。たくさんのサンプルが含まれており、そのうちのいくつかはあなたが解決しようとしている問題に当てはまります。

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

セクション218教育を確認してください

于 2012-04-20T04:03:44.220 に答える
0

データモデリングは、関係図で現実の世界を表現する技術です。あなたのモードは正しいですが、それは本当ですか？

考えてみてください、クラスとは何ですか？それは教師、主題、そして成績です。それらはあなたの関係です。さらに、SUBJECTがそのGRADEに適切であり、TEACHERがそのSUBJECTをそのGRADEで教えることができるというルールを適用する必要があります。

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

grade_subject(subject_id, grade_id)代理主キーには意味がないため、（'PHYSICS'、'YEAR 2'）の2つのレコードがないことを確認するために、に一意の制約を定義する必要があります。それgrade_subjectが他の列のない交差テーブルであるとすると、代理キーを追加しても意味がありません。代理キーの価値は、ビジネスキーの変更による影響を最小限に抑えることです。ただしgrade_subject、ビジネスキーはなく、2つの代理キー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 
---------------------
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)

もちろん、Drury氏が数学を4番目のフォーマーに、物理学を6番目のフォーマーにしか教えることができないというルールを適用したい場合は、TEACHER_SUBJECT_GRADEテーブルが必要になります。

データモデルが対処していないことの1つは、スケジューリングの問題です。学校の時間割はメッシュ化する必要があるため、クラスは事前に決定されたグリッドに収まる必要があります。おそらく、タイムテーブルのスロットを別のテーブルとして定義し、CLASSをそれにリンクする必要があります。クラスには教室も必要です。それは別の表です。

于 2012-04-20T07:18:05.873 に答える