You could do this conceptually. A technical way would be pretty simple, just compare the distinct instances of an attribute vs. the row count of the table. If the distinct instances are smaller, you can replace that attribute with a key in the current table and create another table with the same key and the attribute. This would make sense for attributes that could potentially belong to another 'entity'.
Conceptually, when looking at an individual table, especially one that's normalized, it should have information only describing that entity. For example, a Stores table should only have fields that describe that store, having fields such as Store Name. Let's say that LocationID is the primary key for the Location table and has only one other field, Country. Also assume that this was the result of joining a Location table to the Store table and then dropping LocationID. The resulting table would contain Store and Country data and can be considered a 'denormalized' table. Now let's take this backwards. Let's say you realize that there's only three distinct values for Country in the Stores table, but you have 10,000 rows in the Stores table, so that the three distinct values for Country are repeated many times. To normalize this relationship you would replace the Country in the Store table with a key and create a Country table with the key (distinct) and attribute. This would lower the memory overall since instead of having something like 'Argentina' repeat thousands of times there be a numeric key in its place on the Stores table and a single instance of 'Argentina' on the Location table.
