Относительно агрегации существуют два экстремальных решения: вообще не выполнять агрегацию и выполнять агрегацию для каждой возможной комбинации запросов, необходимых пользователю. Из предыдущих обсуждений должно быть ясно, что полное отсутствие агрегации не является вопросом по причине возможных проблем с производительностью. (Хранилище данных без каких-либо агрегирующих таблиц вообще не может быть использовано в качестве производственного склада данных.) Противоположное решение также не является приемлемым по нескольким причинам:

♦ огромный объем дискового пространства, необходимый для хранения дополнительных данных;

♦ непомерно сложная поддержка агрегатных таблиц;

♦ начальная загрузка данных будет слишком долгой.

Сохранение дополнительных данных, которые содержат агрегированные данные на каждом возможном уровне, занимает дополнительный объем дискового пространства, что увеличивает начальное дисковое пространство в шесть или более раз (в зависимости от объема начального дискового пространства и количества необходимых пользователю запросов). Создание таблиц для хранения агрегатов для всех существующих комбинаций является неподъемной задачей для системного администратора. Наконец, создание агрегатов при начальной загрузке данных может иметь разрушительный результат, если загрузка уже заняла много времени и дополнительное время просто недоступно.

По результатам этого обсуждения вы должны понимать, что агрегатные таблицы должны быть аккуратно спланированы и созданы. В процессе выполнения фазы планирования помните эти два основных соображения при определении того, какие агрегаты создавать:

♦ Где концентрируются данные?

♦ Какие именно агрегаты могут в наибольшей степени улучшить производительность?

Планирование и создание агрегатных таблиц зависит от концентрации данных в столбцах базовой таблицы фактов. В хранилище данных, где отсутствует деятельность в течение дня, соответствующая строка вообще не записывается. Следовательно, если система загружает большое количество строк, по сравнению с количеством всех строк, которые могут быть загружены, то выполнение агрегирования по такому столбцу базовой таблицы фактов резко увеличивает производительность. В противоположность этому, если система загружает небольшое количество строк относительно общего количества строк, которые должны быть загружены, то агрегирование по такому столбцу не даст никакого эффекта.

Вот еще один пример, который иллюстрирует предыдущее рассуждение. Из всех продуктов в продуктовом магазине только небольшая их часть (скажем, процентов 15) фактически продана за текущий день. Если у нас пространственная модель с тремя измерениями Product, store и Time, то будет использовано только 15% комбинаций трех соответствующих первичных ключей для конкретного дня и конкретного магазина. Ежедневные данные по продаже продуктов будут разряженными. В отличие от этого, если в продуктовом магазине в конкретный день были проданы все или большинство продуктов (например, за счет специального предложения), то данные по ежедневным продажам продуктов будут плотными.

Для определения того, какие измерения будут плотными, а какие разряженными, вы должны создать строки из всех возможных комбинаций таблиц и оценить их. Обычно измерение Time является плотным, потому что всегда существуют записи для каждого дня. Измерения Product, store и Time в комбинациях с измерениями store и Time являются плотными, потому что для каждого дня будут некоторые данные, относящиеся к продажам в каждом магазине. С другой стороны, комбинация измерений store и Product является разряженным (по причинам, рассмотренным ранее). В этом случае измерение Product обычно является разряженным, потому что его появление в комбинации с другими измерениями является разряженным.

Выбор агрегатов, которые будут в большей мере увеличивать производительность, зависит от конечного пользователя. Поэтому в самом начале проекта бизнес-аналитики вы должны опросить конечных пользователей для сбора информации о данных, которые будут запрашиваться, о том, как много строк будет отыскиваться в этих запросах, и другие критерии.