In regards to the keys in being alphanumeric in the source table, those would be referred to as natural keys. For best practices you want to typically stay away from referencing natural keys at least as using them as the keys in the star schema model. This is where you want to implement your own surrogate key. You can still store the natural key for reference. There are a few reasons for this. One like I stated for performance (improve joins). The other is because what would happen if by chance you acquired another company or needed to merge data from another system into this dimension table and they had the same natural (source) keys, but they were actually different dimension records.

It is totally up to you, but if you want performance and a way to cover yourself to avoid a collision or reuse down the road for some reason (I have seen natural keys reused in systems) I would go with the surrogate key - To Surrogate Key or Not.