Figure 4-26: 3NF transitive dependence separation from one table to a new table. A transitive dependency occurs where one field depends on another, which in turn depends on a third field--- the third field typically being the primary key. A state of transitive dependency can also be interpreted as a field not being entirely dependent on the primary key.
In Figure 4-26, a transitive dependency exists because it is assumed that each employee is assigned to a particular department. Each depentment within a company is exclusively based in one specific city. In other words, any company in the database boes not have single departments spread across more than a single city. As stated in Figure 4-26, this type of normalization might be getting a little over zealous in terms of creating too many tables, possibly resulting in slow queries having to join too many tables.
Another very typical 3NF candidate is as shown in Figure 4-27, where a calculated value is stored in a table. Also, the calculated value results from values in other fields within the same table. In this situation, the calculated field is actually non-fully dependent on the primary key (transitively dependent) and thus does not necessarily require a new table. Calculated fields are simply removed.
It is important to understand these 2NF relationships in the opposite direction such that BOOK entries depend on the existence of PUBLISHER and SUBJECT entries. Thus, publishers and subjects must exist for a book to exist---or every book must have a publisher and subject. Think about it, it makes perfect sense, exception could be a bankrupt publisher. On the contrary, the relationship between PUBLISHER and BOOK plus SUBJECT and BOOK are actually one-to-zero, one, or many. This means that not all publishers absolutely have any titles published at any specific time, and also that there is not always a book available covering each available subject.