You are wrong on all counts. Several database systems are based upon
an OS's underlying file system, for one thing. For another, the response
to the OP was correct: there was no call for your sarcastic response.

To the OP: it seems like you want one table whose records look like:

             (teacher-ID,  hour,  day,  course).

For a case this simple, you don't need to resort to entity-relationship
(ER) diagrams: just apply some common sense. A teacher cannot be in two
places at once, so you cannot have both:

               (teacher-A, 9:40am, Monday, course-X) and
               (teacher-A, 9:40am, Monday, course-Y).

Therefore, the triple: (teacher-ID, hour, day) must appear uniquely in
your table -- which is to say, it is a primary key (PK). This means there
is a "primary-key constraint" which should be enforced:

  1) for Insert's, a new record should not be allowed with the same triple
     as another record in the table;

  2) for Update's, an existing record should not be changed to one with
     the same triple as another record in the table.

As to the issue of privacy, this can be handled by your DBA.
For instance, in INFORMIX, if the name of your table is "Teachers":

             REVOKE ALL on Teachers from PUBLIC;
             GRANT SELECT (teacher-ID, course) on Teachers TO phyllis

would limit access to the user with ID = "phyllis".