How far to take normalization?

Denormalization has the advantage of fast SELECTs on large queries.

Disadvantages are:

• It takes more coding and time to ensure integrity (which is most important in your case)

• It's slower on DML (INSERT/UPDATE/DELETE)

• It takes more space

As for optimization, you may optimize either for faster querying or for faster DML (as a rule, these two are antagonists).

Optimizing for faster querying often implies duplicating data, be it denormalization, indices, extra tables of whatever.

In case of indices, the RDBMS does it for you, but in case of denormalization, you'll need to code it yourself. What if Department moves to another Office? You'll need to fix it in three tables instead of one.

So, as I can see from the names of your tables, there won't be millions records there. So you'd better normalize your data, it will be simplier to manage.

Normalize till it hurts, then denormalize till it works

Always normalize as far as necessary to remove database integrity issues (i.e. potential duplicated or missing data).

Even if there were performance gains from denormalizing (which is usually not the case), the price of losing data integrity is too high to justify.

Just ask anyone who has had to work on fixing all the obscure issues from a legacy database whether they would prefer good data or insignificant (if any) speed increases.

Also, as mentioned by John - if you do end up needing denormalised data (for speed/reporting/etc) then create it in a separate table, preserving the raw data.