我在关系模型中有以下关系（表）
Person
person_id, first_name, last_name, address
Student
person_id, matr_nr
Teacher
person_id, salary
Lecture
lecture_id, lect_name, lect_description
Attendees
lecture_id, person_id, date
我想知道学生和老师的功能依赖性。
这些表格是否符合第3范式？哪个应该是这些表的主键？
答案 0 :(得分：3)
使用像“表继承”这样的概念（松散地）和连接表我会以这种方式设置：
Person
person_id, first_name, last_name, address
Student
student_id, person_id, matr_nr
Teacher
teacher_id, person_id, salary
Lecture
lecture_id, teacher_id, lect_name, lect_description, date
Attendees
lecture_id, student_id
学生和教师表“继承”来自Person，而参加者表是Lecture和Student之间的Join表（在Lecture表中使用teacher_id来指定谁在教授课程。并且通过Join table最佳实践，表格应该是被命名为Lecture_Student或类似的）
替代设计：（允许多个班级教师）
Person
person_id, first_name, last_name, address
Student
student_id, person_id, matr_nr
Teacher
teacher_id, person_id, salary
Lecture
lecture_id, lect_name, lect_description, date
Lecture_Student
lecture_id, student_id
Lecture_Teacher
lecture_id, teacher_id
答案 1 :(得分：0)
我认为3NF标准化（关键，整个密钥，只有密钥）就我们所知，但它可能无法解决您的问题域问题。
您的主键是_id列 - 除了与会者。哪里都是_id列 - 但这不适应在不同的日期参加相同的讲座（或者技术上是不同的讲座？）在我建立的类调度系统中，我们在一个类中有部分，但问题域因为这可能比你给出的要大得多。
学生和老师的问题已经提出 - 两个人都是与会者，这就是你所知道的一切 - 所有老师都可以教学，或者只有一些教师可以教学，或者他们可能是同学（研讨会，说）
我认为这首先是域建模问题，然后是规范化......
答案 2 :(得分：0)
“这些表格是否符合第3范式？”
如果您告诉我们密钥是什么以及完整的功能依赖集是什么，那么这个问题只能回答。
如果没有这个，任何人给出的答案只能是回答者的非零猜测量的结果，而且你无法保证猜测与你的商业现实相符。
那就是说，你可能会调查参加者。很可能那里有腐烂的东西。
（嘿，你声称自己不想被人掏勺。）
答案 3 :(得分：0)
绝对不是3NF。针对上述问题的一个简单的标准化设计（假设person_id唯一地标识教师和学生，并且每个讲座有一名教师）如下：
Person
person_id (PK), first_name, last_name, address, Student_matr_nr, Teacher_salary
Lecture
lecture_id (PK), teacher_person_id (FK), lect_name, lect_description
Attendees
lecture_id (PK), student_person_id (PK), date
具有相同密钥的关系具有相同的关系。