Реляционные системы учета, на основе данных которых нам предстоит формировать хранилище, чисто исторически могут быть представлены самыми различными СУБД и форматами хранения. Продуктовая система может быть построена на Oracle, внутренняя бухгалтерия - на FoxPro, а управление кадрами - на Access. Тем не менее, для целей анализа данные нужны могут понадобиться все и сразу. Следовательно, мы должны уметь осуществлять доступ к источникам данных различной природы. Перед тем, как положить данные в хранилище, данные должны быть очищены, проверены на непротиворечивость и приведены к единому виду. Например, одно приложение хранит месяц апрель как "Апрель", другое - как "апр", третье - как "April", четвертое - как "IV", пятое - как "04" и т.д. Даже если мы с помощью OLE DB, ODBC или как-то иначе мы организовали доступ ко всем нашим разнородным источникам данных, или если нам повезло и все это хранится в одной СУБД, мы получим несколько разных членов одного временнОго измерения, которым на самом деле соответствует всего лишь один член уровня "месяц". А, кроме того, он может вообще храниться не отдельно, а в составе даты, и тогда его нужно выделить оттуда при наполнении хранилища. Еще одно требование - возможность частичной предагрегации. Допустим, наша продуктовая система хранит данные о продажах за каждый день. Но в процессе анализа будущего куба мы не собираемся погружаться до дней, так как по логике приложения нас вполне устроит месячный дискрет. Следовательно, нечего тащить все детали в куб и раздувать объем хранилища, стоит агрегировать месячные продажи еще на стадии наполнения хранилища. Согласно теории построения хранилищ, последние должны пополняться в строго определенные моменты времени, скажем, раз в день, неделю, месяц. Это разумно, поскольку а) он-лайновое обновление данных свело бы на нет все преимущества, связанные с read-only природой хранилища (правда, существуют такие вещи, как поддержка ответов на запросы типа "что-если", предполагающая внесение изменений в локальный многомерный кэш, и обратная запись, вносящая изменение непосредственно в хранилище на сервере, но об этом чуть позже); б) предвычисление агрегатов в случае внесения изменений в детальные данные, на основе которых построено хранилище, есть процесс далеко не мгновенный, что невозможно, если допустить он-лайновые изменения в хранилище. Следовательно, загрузка данных в хранилище должна происходить на основе расписания в фиксированные моменты времени.
Итак, доступ к разнородным данным, их очистка, проверка на непротиворечивость, унификация, предагрегация и выполнение на основе определенного графика во времени - все эти задачи при погружении данных в хранилище решают службы преобразования данных .
Назад | Содержание | Вперед