The requirement imposed on a database by 3NF are as follows:

• Database is in 2NF
• No transitive dependencies: we cannot have one column dependent on another column which is, itself, dependent on a third column

Our 2NF database does have a transitive dependency. The instrument_model column depends on the instrument_id and the measurement_type column depends on the instrument_model column and thus has a transitive dependence on the instrument_id column. Again, this will require another table for measurement_types for a given instrument_model. This division makes some intuitive sense; measurement_type is a function of the general class of instrument as described by instrument_model, which we put in an Instrument_models table, but instrument_id describes a specific instance of the instrument to which the last_maintenance_date, a property of an individual instrument, applies.

Now, we might wonder if measurement_unit has a transitive dependence on instrument_model via measurement_type—requiring an additional table to associate units with measurement_type in the role of PK—but in this case we can imagine that a given measurement_type such as temperature can have multiple units of measurement depending on the instrument_model configuration, so we can leave it in the Instrument_models table; if this matter was a configuration of individual instruments, it would instead go in the Instruments table. In any case, with the assumptions described, our database is in 3NF and we are done.

As a final note, normalization may feel like something of an art, and it does sometimes take a little thought about relationships and dependencies to get right, but the final result is generally an intuitively appealing outcome from which information can often be extracted with relatively simple SQL queries.