数据库设计 - 它是否尊重第三个NF?

时间:2010-06-10 17:02:49

标签: sql database-design database relational

我在关系模型中有以下关系(表)

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范式?哪个应该是这些表的主键?

4 个答案:

答案 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

具有相同密钥的关系具有相同的关系