Not sure why you think some random technique like UNPIVOT would audit your table for you. As @011111100010 stated in the comments, it sounds like you need an audit trigger - here is a tutorial that will show you how to do that
Create a Simple SQL Server Trigger to Build an Audit Trail[
^]
Your motivation for doing this is not clear so perhaps you should also familiarise yourself with
How to read the SQL Server Database Transaction Log[
^]
If you choose to do this manually then you would have to do something like this
INSERT INTO DATA_LOG (EMP_ID, FIELD_NAME, TABLE_NAME, OLD_VALUE, NEW_VALUE)
SELECT EMP.EMP_ID, 'FIRST_NAME', 'EMP_TABLE', EMP.FIRST_NAME AS OLD_VALUE, T.FIRST_NAME AS NEW_VALUE
INSERT INTO DATA_LOG (EMP_ID, FIELD_NAME, TABLE_NAME, OLD_VALUE, NEW_VALUE)
SELECT EMP.EMP_ID, 'LAST_NAME', 'EMP_TABLE', EMP.LAST_NAME AS OLD_VALUE, T.LAST_NAME AS NEW_VALUE
INSERT INTO DATA_LOG (EMP_ID, FIELD_NAME, TABLE_NAME, OLD_VALUE, NEW_VALUE)
SELECT EMP.EMP_ID, 'MOBILE_NO', 'EMP_TABLE', EMP.MOBILE_NO AS OLD_VALUE, T.MOBILE_NO AS NEW_VALUE
(assuming the ID is an identity column) Truly awful, and the best argument I could give for using a Trigger instead.
Incidentally, if you are doing an audit don't you think it would be a good idea to also capture the date-time of the change, and possible who did it? If space is at a premium then why bother holding the new value on the audit table - this will be either the value currently on the EMP_TABLE or the OLD_VALUE stored on the next audit log for this EMP_ID.
Finally, I trust that TEMP_DATA only contains values that you definitely want to change on EMP_TABLE as you have omitted any WHERE clause.