I have a question concerning redundant foreign keys (I will explain
what I mean by "redundant" with my example below), as implemented in a
legacy database schema I'm analyzing. I have simplified the actual
schema in my example to clarify my question. This schema has been
applied to multiple RDBMS (Oracle, SQL Server, Informix, etc.), so I'm
making no vendor-specific assumptions w.r.t. database design or
implementation.

Given the following three tables within the schema:

(1) table "Department", with primary key on column 'DeptID'
(2) table "Employee", with a primary key of 'EmplID' and 'DeptID'. The
table also has a foriegn key on column 'DeptID' referencing
Department.DeptID
(3) table "Workstation", with a primary key of 'WSID'. The table also
has two foreign keys: (a) one on columns EmplID and Dept.ID
referencing Employee, and (b) one on column DeptID referencing
Department.DeptID.

The second foreign key in table "Workstation" is a FK I would consider
"redundant", because there is already the foreign key from Workstation
to Employee, along with the FK from Employee to Department. I don't
know what the decisions were behind this design. I would like to know
if there is any performance benefit for the dabatase either with or
without this "redundant" FK. I'm assuming there is no threat to
referential integrity if this "redundant" FK is removed.

Thanks to everyone for your help.

Workstation
to Employee, along with the FK from Employee to Department. <<

Google a series of articles by Tom Johnston on non-normal form
redundancies at http://dmreview.com/. He has a situation like this in
one of the articles.

His set up was a salesman belongs to a team and is the primary contact
for a customer. But if that salesman cannot get to the customer, then
the customer belongs to the same team as the salesman. He demonstates
the problems and gives a solution.