Normalize or De-Normalize?

Ok. This is a not a bad question. Let's start with the normalization part. It is a useful, but theoretical thing. In everyday situations you can consider following or not following it for practical reasons.

I can't see your concrete model, but if only a single value is in the other table (like a category), you can consider keeping both tables (the "category" table should be kept to deliver the set of values), but instead of using key based references, you put the actual value in the referring table - but be sure to be consistent. This is useful if the data in that field is not so large.
Let's take an other example: invoices. Invoices contains buyer address, that can change over time, but an invoice has to be kept unaltered after issuing it. So you have to assure, that the data stored related to the invoice is the same even if partner's actual data changes. But you need a key based reference for other reasons. So you can take a mixed approach: keep all partner data in the external table, keep the foreign key in invoices table - but also copy data that has to be kept intact in the invoice table.
As you can see there are several considerations - but you have to decide.

Let's take a look on those 160 fields. There might be a design flow. It is really rare that you can't decompose such a high number. If they are mostly optional fields (properties) you have chosen to put all possibilities in a single table, you should consider following too (also in combination with the above approach): use XML field and those properties in it; or keep the really unique fields in a table, and externalize the properties with an 1:N relation to a table that holds only name-value pairs in addition to the reference. Let's suppose you want to store the data of a pc. You would have a field for processor, motherboard, memory and so on. Than you could decompose it as follows:

COMPONENT_KINDS(ck_id, component_kind_name)<br />
PC (pc_id,....)<br />
PC_COMPONENTS (pcc_id, pc_id, ck_id, value)

So you could have only as many PC_COMPONENT records for a PC as many you need. It is like rotating a horizontal model to a vertical one.