Question

我创建了一个简单的CRUD应用程序数据库schehme。但是，在实现它之前，我想检查它是否在3NF：

CREATE TABLE person (
person_id int not null,
name char(30) not null,
student_no int,
staff_no int,
student_fieldOfStudy char(30),
staff_department char(30),
staff_position char(30),
faculty char(30),
PRIMARY KEY (person_id),
CONSTRAINT student_unique UNIQUE (student_no),
CONSTRAINT staff_unique UNIQUE (staff_no)
);

CREATE TABLE university (
university_id int not null,
foundationDate datetime not null,
university_name char(30) not null,
city_name char(30) not null,
country_name char(30) nut null,
PRIMARY KEY (universityID),
CONSTRAINT univ_unique UNIQUE (university_name, city_name)
);

CREATE TABLE course (
course_id int not null,
course_code char(20) not null,
lecturer_name char(30) not null,
lecture_day datetime not null,
faculty char(30) not null,
lecture_room char(30),
lecturer_id int,
student_id int,
FOREIGN KEY (student_id) REFERENCES Persons(person_id),
FOREIGN KEY (lecturer_id) REFERENCES Persons(person_id)
)

从我看来它在3NF。我很感激你的回复！

Answer 1

在不知道应该生效的业务规则的情况下，很难评论数据库设计。您需要根据自己对业务领域的分析来确定。如果没有这些信息，我们所能做的就是根据表名和列名列表做出一些假设和猜测。

人员表看起来有问题。学生和工作人员专栏应该是无聊的吗？在我看来，你喜欢在一张桌子里维护两种不同类型的人。可能更好的是为每个人子类型创建不同的表，并且只具有人员表中学生和员工共同的属性。

3NF的概念基于关系和依赖关系，它们只允许值，而不是空值。如果您有空值，那么您没有满足3NF的关系。此外，如果staff_no应该是人员属性的决定因素，那么它是一个非关键的决定因素（因为它可以为空）。由于多种原因，可空的唯一性约束是一个坏主意，你应该尽量避免它们。

Answer 2

从很短的一瞥看，课程表看起来非常非3NF。

缺少钥匙
除非每位讲师只有一门课程，否则讲座_id不是关键，所以讲师名称不应该在那里
我想每个课程也可以有不止一个学生;在这种情况下，student_id属于其他地方
演讲室是否只属于一个教师？
course_code不依赖于course_id吗？

只是为了让你开始......

如何检查3NF？

2 个答案: