如何检查3NF？

Question

I have created a simple CRUD application database schehme. However, before implementing it I want to check if it is in 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)
)

From my opinion it is in 3NF . I would appreciate your reply!

Answer 1

It's difficult to comment on a database design without knowing what business rules are supposed to be in force. You need to determine that from your own analysis of the business domain. Without that information all we can do is make some assumptions and guesses based on a list of table and column names.

The person table looks problematic. Are the student and staff columns supposed to be nullabale? It looks to me like you are maintaining two distinct types of person in one table. Probably better to create distinct tables for each of those person subtypes and just have the attributes that are common to both student and staff in the person table.

The concept of 3NF is based on relations and dependencies which permit only values, never nulls. If you have nulls then you don't have a relation that satisfies 3NF. Further, if staff_no is supposed to be a determinant for the staff attributes then it is a non-key determinant (because it's nullable). Nullable uniqueness constraints are a bad idea for multiple reasons and you should try to avoid them.

Answer 2

From a very short glimpse, the course table looks VERY non-3NF.

• It lacks a key
• Unless there is only one course per lecturer, then lecturer_id is not the key, so lecturer_name shouldn't be there
• I guess there can be more than one student per course as well; in that case, student_id belongs somewhere else
• Does a lecture room belong to one and only one faculty?
• Isn't course_code dependent on course_id?

Just to get you started...