Your natural dimension primary key maybe too large to use in a data-mart with hundreds of millions of rows so you might need to create a smaller alternate key. Sometimes it's not always best to use IDENTITY columns.

Imagine the case where you are importing data from an external system. The usual method to add the correct foreign keys is to either create a lookup (in DTS) which can be very slow, or try and join the imported data to your dimension table and extract the dimension key (which is also pretty slow). I've used a date lookup here as an example (time of day is not used):

update dbo.ImportedData
set DateID = d.DateID
from dbo.ImportedData t join dbo.Dates d
    on d.Date = cast(floor(cast(t.Date as float)) as smalldatetime)

For dimensions like this it maybe much more efficient to create keys using a calculation performed on the common fields. For example, the number of days since a point in time:

update dbo.ImportedData
set DateID = datediff(day, '2000-01-01', Date)
from dbo.ImportedData

This avoids any sort of join and, in fact, could be performed on the data stream as it is loaded into the database. Also, if you use a smallint for the key then you get a 50% saving from the original smalldatetime type and are still able to use dates past 2175.