I think you are confusing a few different things here.
1: database normalisation.
The question answer you link to is about normalizing out repeated data into a second table with a FK. The key needent be an int and will be repeated, so if your data is JUST the key you are already normalized.
2: ints as keys (due to space?)
You suggest that using an int is better as a key, but this is contaversial. GUIDs are another option and strings can be used.
3: persisting enum values
So an enum will eval as an int, but if you only store the int -> name relationship in your code and not the db you have potential issues if you ever change the enum.
If you replicate the enum in a lookup table then you double up on this problem and will need some way of syncing code with db.
Its usualy best to persist an enum as a string, as this carries the meaning and an enum is not a 'display string' that will change, be translated etc
So taking these together, where you have a poco object with an enum field. i recommend storing the field as a string in a db table with cols which match the objects properties. Ie
Id -> some guid
Name -> fred
Sex (ENUM) -> male
Where the property is a class with more than one property you should use a FK to another table. Ie.
address (class) -> (addressId col) some guid
If you treat the enum like a class and move it out to a lookup table you can achieve space savings if you have many rows and few enum values Eg.
Sex(enum) male -> (sexId [short] ) 0
But the id and FK relationship should be purely at the DB layer. You shoud still return the Name from queries and deserialise that string back to your enum rather than mapping the short Id to your enum int.
However, this is an optimisation rather than a normalisation and you are only saving space, which as your referenced question says, is cheap. Personally I tend to leave this kind of thing to DBAs
Consider for example you will need an insert sproc, which takes the enum string, checks the lookup table to find the short id, adds the enum to the lookup table if required and then uses the short id for the insert. So there is a downside to the optimisation as well as an upside