Один из вариантов решения:
1. В фактовой таблице создаете поле DateId int.
2. Создаете табличку типа
CREATE TABLE [dbo].[Calendar] (
[Id] [int] NOT NULL ,
[DateItem] [smalldatetime] NULL
) ON [PRIMARY]

ALTER TABLE [dbo].[Calendar] WITH NOCHECK ADD
CONSTRAINT [PK_Calendar] PRIMARY KEY CLUSTERED
(
[Id]
) ON [PRIMARY]
3. При закачке данных в хранилище проверяете в календаре наличие этого дня и при необходимости его добавляете, не забыв заполнить дырки за предыдущие дни (от последней меньшей даты до добавляемой).
4. В кубе делаете связку Calendar.Id <-> YouFacttable.DateId.

Нормальной практикой является не прямой забор данных из oltp-базы, а предварительное помещение только необходимых данных в хранилище olap (одновременно выполняется очистка данных), а уже на его основе формирование и процессинг измерений и кубов. То есть создание некоторой промежуточной базы, которая будет относиться только к конкретной предметной области, в рамках которого и требуется применить ОЛАП-решение.
Вы ведь уже начали такое применять согласно ваших слов -
"Теперь получается так: есть таблица фактов Customer и Dimension Table для Time Dimension - Date". Dimension Table - где создано? В реляционной базе?

Еще один вариант - использовать в качестве фактовой таблицы не саму Customer, а ее представление, добавив в конце еще одно поле DateId на основе вашего поля Customer.CreatedOn.

Можно посмотреть:
http://www.sqljunkies.com/Article/D1E44392-592C-40DB-B80D-F20D60951395.scuk

Да - вы правильно поняли. Имеет смысл создавать свою БД, предназначенную для закачки данных в кубы и измерения. В отличие от вашей реляционной (вы так называете свою оперативную БД), в ней хранятся только необходимые и подготовленные данные. В вашем примере - в вашей реляционной базе поле
CreatedOn может содержать либо дату и время создания документа в вашей учетной системе, либо дату и время создания собственно первичного документа, либо дату и время внесения (чужого) документа. Вариантов много. Вам для анализа, как правило, нужна определенность. Опять же, эта дата в неудобном формате. Преобразовав ее (01.03.2004) в формат 20040301 получаем новую таблицу, в которой можем сделать первичный ключ по этому полю (рекомендуется построение для каждой таблицы измерения первичного ключа) - одно измерение полностью готово.
Далее - создать куб можно как на основе таблицы существующей (в вашей оперативной базе или в созданной вами для нужд ОЛАПа), так и на основе ее представления. Все поля таблицы фактов, по которым есть измерения, должны быть связаны с таблицами измерений.
Применение разных типов Molap или Holap возможно как для реляционной (оперативной) базы, так и для построенной для нужд ОЛАП.
К плюсам своей БД ОЛАП можно отнести и тот факт, что реляционная (оперативная) БД периодически подрезается (как правило), а в своей можно хранить только необходимые данные, а при организации кубов через временные партиции и ее тоже можно подрезать - данные в кубе за удаленный период останутся.

В продолжение ответа.
В своей БД заведите табличку DayOfWeek - два поля IdDay - день недели и NameDay - название дня недели. Заполните семь строк (можно ручками).
В фактовую таблицу добавьте поле DayOfWeekId и заполните его с помощь функции DATEPART(weekday, Orders.CreatedOn).

В результате будете иметь еще и анализ в рамках дней недели.
Успехов!