Корпоративные информационные системы. Борисов Д.Н. - 36 стр.

абстрагирован от физической структуры данных и воспринимает данные
как многомерные.
     2. Многомерная обработка – средство (язык) формулирования
многомерных запросов (традиционный реляционный язык SQL здесь
оказывается непригодным) и процессор, умеющий обработать и выполнить
такой запрос.
     3. Многомерное хранение – средства физической организации данных,
обеспечивающие эффективное выполнение многомерных запросов.
     Первые два уровня в обязательном порядке присутствуют во всех
OLAP-средствах. Третий уровень, хотя и является широко
распространенным, не обязателен, так как данные для многомерного
представления могут извлекаться и из обычных реляционных структур.
Процессор многомерных запросов, в этом случае, транслирует
многомерные запросы в SQL-запросы, которые выполняются реляционной
СУБД.
     В любом хранилище данных – и в обычном, и в многомерном –
наряду с детальными данными, извлекаемыми из оперативных систем,
хранятся и агрегированные показатели (суммарные показатели), такие, как
суммы объемов продаж по месяцам, по категориям товаров и т. д.
Агрегаты хранятся в явном виде с единственной целью – ускорить
выполнение запросов. Ведь, с одной стороны, в хранилище накапливается,
как правило, очень большой объем данных, а с другой – аналитиков в
большинстве случаев интересуют не детальные, а обобщенные показатели.
И если каждый раз для вычисления суммы продаж за год пришлось бы
суммировать миллионы индивидуальных продаж, скорость, скорее всего,
была бы неприемлемой. Поэтому при загрузке данных в многомерную БД
вычисляются и сохраняются все суммарные показатели или их часть.
     Тем не менее, использование агрегированных данных чревато
недостатками. Основными недостатками являются увеличение объема
хранимой информации (при добавлении новых измерений объем данных,
составляющих куб, растет экспоненциально) и времени на их загрузку.
Причем объем информации может увеличиваться в десятки и даже в сотни
раз. Например, в одном из опубликованных стандартных тестов полный
подсчет агрегатов для 10 Мб исходных данных потребовал 2,4 Гб, т. е.
данные выросли в 240 раз!
     Степень увеличения объема данных при вычислении агрегатов
зависит от количества измерений куба и структуры этих измерений, т. е.
соотношения количества «родителей» и «потомков» на разных уровнях
измерения. Для решения проблемы хранения агрегатов применяются
сложные схемы, позволяющие при вычислении далеко не всех возможных
агрегатов достигать значительного повышения производительности
выполнения запросов.
     Как исходные, так и агрегатные данные могут храниться либо в
                                  36