Is a chain of foreign keys better than duplicating data?
I would keep this style of design. The only issue that this could begin to cause is a performance hit on reports when dealing with a lot of data, but you wouldn't start seeing it until the millions of rows range. This would be because any report would have to basically query a half dozen tables to get the information it needs, but in general this would give you a lot of flexibility to create queries and views to sort and filter the rows.
In the real world, you'll likely find that the University table would contain the fields for both Country and City, with them just as commonly being just text fields, instead of having lookup tables. This would improve query performance a bit, especially since the number of universities would not be nearly as large as the number of faculty or students. The cost for this would be an increase in storage requirements, since every row in the University table would have the full city and country names instead of the FKs.