While the answer above will tell you how to look at the transaction log, I agree with JNK that parsing a transaction log is not a good audit trail for table changes.
It all depends on how much audit data you want to keep and how much speed you are willing to loose with the auditing. Do not forget about data retention period.
1 - Trigger based auditing at both the table and database level work fine. See my blog for a presentation on this.
However, auditing on a table that has a large number of changes might not be practical and you might never use the data. A retention period is key.
2 - If you want to use something that is built into SQL Server, take a look at the Change Data Capture feature. It is based upon reading the log file as a periodic SQL Agent job. Therefore, you do not have a trigger fire for each event. There is a lag time between when something happens and when it occurs.
3 - If you are just looking if the record was inserted or updated, by who, and when, this can be done by the custom ETL code that is modifying the Data Warehouse. Just add those fields to the table and have the code update them.
I hope these suggestions move you away from reading the transaction log which can be very tedious in-deed.
John