Многоуровневые измерения

в схеме звезда , изображенной на рис. 213, каждое измерение имеет только один уровень. На практике же довольно распространена более сложная структура базы данных, в которой измерения могут иметь по нескольку уровней. Например.

Данные о продажах могут накапливаться отдельно для каждого офиса. Офисы располагаются в районах, а районы в регионах.

ш Данные о продажах накапливаются по месяцам, но анализировать их полезно не только по месяцам, но и по кварталам.

Данные о продажах накапливаются по отдельным продуктам, а каждый продукт ассоциирован с конкретным производителем.

Подобные многоуровневые измерения усложняют звездообразную схему, и на практике возникающую проблему рещают по-разному:

Дополнительные данные в таблицах измерений. Таблица географического измерения может содержать информацию об отдельных офисах и при этом иметь столбцы, указывающие, к какому району и региону относится каждый офис. Статистические данные, касающиеся районов и регионов, могут бьпъ получены с помощью итоговых запросов, объединяющих таблицу фактов с таблицей измерения и фуппирующих данные по столбцам района и региона. Этот подход концептуально довольно прост, но не всегда позволяет получить нужные данные за один раз: чаще всего требуется проводить вычисления в несколько этапов, запрос за запросом. Из-за этого на формирование итоговых данных может уходить слишком много времени.

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

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

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

(например, о продажах по районам и месяцам) нужна специальная таблица фактов, в которой данные просуммированы для этих уровней измерений Результирующая схема таблиц измеренлй и фактов имеет множество перекрестных связей и напоминает снежинку, поэтому схемы баз данных этого типа обычно так и называют: схема снежинка . Этот подход рещает проблему производительности и устраняет дублирование данных в таблицах фактов, но может существенно усложнить структуру баз данных хранилищ, поскольку для каждого типа возможных запросов нужна своя таблица фактов.

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

Расширения SQL для хранилищ данных

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

Сортировка данных. Многие аналитические запросы явно или неявно требуют предварительной сортировки данных. Вам наверняка не раз встречались такие критерии отбора информации, как первые десять процентов , первая десятка , самые низкоприбыльные и т.п. Однако SQL оперирует неотсортированными наборами записей. Единственным средством сортировки данных в нем является предложение order by в инсфукции select, причем сортировка выполняется в самом конце процесса, когда данные уже отобраны и обработаны.

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

Сравнение с итоговыми данными. Многие аналитические запросы сравнивают значения отдельных элементов (например, объемы продаж отдельных офисов) с итоговыми данными (например, объемами продаж по регионам) Такой запрос трудно выразить на стандартном диалекте SQL. А если вам нужен сводный отчет классического формата - с детальными данными, промежуточными и общими итогами, то его с помощью SQL вообще нельзя сгенерировать, поскольку Сфуктура всех строк в таблице результатов запроса должна быть одинаковой. Пытаясь решить все этих проблемы, производители СУБД для хранилищ данных

обычно расширяют в своих продуктах возможности языка SQL. Например, в СУБД компании Red Brick, которая была одним из пионеров рынка хранилищ данных, а сейчас входит в состав компании Informix, в язык RISQL (Red Brick Intelligent SQL) включены следующие расширения:

диапазоны - позволяют формулировать запросы вида отобрать первые десять записей ;

ш перемещение итогов и средних - используется для хронологического анализа

требующего предварительной обработки исходных данных; ш расчет текущих итогов и средних - позволяет получать данные по отдельным

месяцам плюс годовой итог на текущую дату и выполнять другие подобные

запросы;

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

ш декодирование - упрощает замену кодов из таблиц измерений понятными име- нами (например, замену кодов товаров их названиями);

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

Многие разработчики СУБД для хранилищ данных используют аналогичные расширения SQL или встраивают в свои продукты специальные функции для получения нетипичных для SQL данных. Как и в случае с другими расширениями SQL, их концептуальные возможности, предлагаемые различными разработчиками сходны, а реализация зачастую соверщенно разная.

Производительность хранилищ данных

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

Скорость загрузки данных

Зафузка в хранилище очередной порции данных - дело не бысфое. Этот процес! может занимать часы и даже дни. Обычно он состоит из следующих операций:

Извлечение данных Как правило, загружаемые в хранилище данные поступают из нескольких различных источников. Среди них могут быть реляционные базы данных OLTP-приложений.

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

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