Consider adding a SCHOOL_NM to each student record in the original flat file.

Given the discussion on second normal form, it may seem reasonable to put the school name and address in the STUDENT entity.

It is reasonable to ask why the school cannot be an attribute of the student table. Theoretically since the student table contains no repeating groups and does not have a multi-value key it would be in second normal form. (Remember that second normal form implies first normal form also.) The problem is that the key STUDENT_ID describes nothing about the schools or their addresses.

Practically, the problem is that there is potential for update and delete anomalies. It would be possible to update the school name of some schools without doing all of them. This would lead to an incomplete student roster for a given school. If all of the students of a given school were deleted, this would mean the school would also cease to exist in the model. It can be said that the student table is "flat" and can now start with a table as was done above.

To eliminate the theoretical and practical issues, move the model to third normal form.

Any update of a school name or address now cascades to the student. If all the students of a school are deleted, the school still remains.