- Tables: are named using a single word in Title case and should not be represented by attributes of the data it contains. (e.g. "Employee" is an attribute of "People" and "Schedule" is a group of "Events").
For clarification, the indication of Students above, as being 'bad' should not be misinterpreted as a bad choice for an actual table name - if a table named Students fits the requirements of your solution. The indication is there because the storage of an actual person who happens to be a Student at the time, should be within a general People table and identified via the data itself (e.g. using either another field as a tag or a join table structure to associate that person as being such a student). A student today is not always a student tomorrow, but they're always a person.
Schedule » People::id
will be much easier to read within calculation code as opposed to