Table definitions are analogous to class definitions, but the use of a table as a set is analogous to a collection of instances of the table definition itself.
The designer of a database is thinking "class" definition and the name becomes singular ("a set of type Employee"). Architects might be correct to use singular names in logical data models (Data Definition Language), with the exception of modeling "many" relationships, cardinality rules, and other set-based constraints, which would assume a collection of instances of the table definition (class). When using a table, it is also true that you are working with a set or collection of objects of type "table", so the name used as a set (Structured Query Language and not DDL) would be plural.
The OOP analogy breaks down when you begin to name tables as you would in a class library with names like "EmployeeCollection". Since all tables will represent collections of type "Employee", distinguishing collections from classes with the "Collection" suffix is pointless. But, the fact that the table represents a collection remains and should therefore be pluralized "Employees" (or be given a more meaningful collective name like "Personnel").