数据库设计——是否尊重第三个NF？

Question

我在关系模型中有以下关系（表）

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

我想知道学生和教师的功能依赖关系。

这些表符合第三范式吗？这些表的主键应该是哪个？

Answer 1

使用“表继承”（松散地）和联接表等概念，我会以这种方式进行设置：

 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

其中学生和教师表从人员“继承”，而参加者表是讲座和学生之间的联接表（teacher_id 用于讲座表指定谁在授课。通过连接表最佳实践，该表实际上应命名为 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

Answer 2

据我们所知，我认为它是 3NF 标准化的（密钥、整个密钥，除了密钥什么都没有），但它可能无法解决您的问题域问题。

您的主键将是 _id 列 - 与会者除外。其中两个 _id 列 - 但这不能适应在不同日期参加同一讲座（或者技术上这会是不同的 Lecture_id 吗？）在我构建的课程安排系统中，我们在班级中有部分，但问题域因为这可能比你所给予的要大得多。

学生和老师的问题已经被提出了 - 两者都将是参加者，这就是你所知道的 - 所有老师都可以在教学，或者只有其中一些可以在教学，或者他们可以是同伴（例如研讨会）

我认为这首先是一个领域建模问题，然后是标准化问题......

Answer 3

“这些表遵循第三范式吗？”

只有当您告诉我们键是什么以及完整的函数依赖关系集是什么时，这个问题才可以回答。

如果没有这一点，任何人给出的任何答案都只能是回答者非零猜测的结果，并且您无法保证该猜测符合您的业务现实。

也就是说，您可以查看与会者。那里很可能有什么东西腐烂了。

（嘿，你声称自己不想被灌输。）

Answer 4

这绝对不是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

彼此具有相同键的关系是相同的关系。