Лабораторная работа № 5
Разработка и эксплуатация хранилищ баз данных
Многомерные базы данных и хранилища данных
Способы организации хранилищ данных могут очень сильно отличаться в зависимости от характера планируемых запросов. Одним из возможных запросов к системе может быть запрос типа: “выбрать из системы все данные, удовлетворяющие такому-то условию”. Такой запрос может потребовать анализа очень большого количества данных, но результат его выполнения – выборка одной или нескольких записей.
Более типичными запросами к хранилищу данных могут быть запросы, возвращающие какие-то обобщенные значения на основе обработанных данных. В процессе выполнения такого запроса данные фильтруются по определенным критериям (SQL-оператор WHERE), группируются (SQL-оператор GROUP BY) и агрегируются (подсчитывается сумма, или среднее значение, или максимальное/минимальное значение и т.д.).
Наиболее распространенным способом организации хранилищ для выполнения подобных аналитических запросов является использование многомерной модели данных, которая обычно ассоциируется с понятием OLAP и его частным случаем –ROLAP.
В OLAP-системе данные параметризуются несколькими равноправными величинами (измерениями, dimensions). Например, данные по продажам в крупной торговой компании можно было бы анализировать в следующих измерениях:
время (день, месяц, квартал, год, неделя)
география (город, штат, страна)
товар (фирма-производитель, тип товара)
покупатель (пол, возраст)
Заметим, что измерения (время, география) носят иерархический характер: в различных запросах может понадобиться производить анализ с дискретностью день, месяц или квартал. Естественно, способ организации данных должен поддерживать эти возможности.
В построенной таким образом системе можно было бы достаточно легко формировать запросы типа:
как в прошлом году распределялись продажи телевизоров (тип товара) различных производителей по разным штатам?
какова динамика продаж по месяцам видеомагнитофонов в текущем году по городам штата Калифорния?
Видно, что подобные запросы строятся следующим образом:
на участвующие в запросы данные устанавливаются фильтры (“текущий год” – время, “штат Калифорния” – география, “видеомагнитофоны” – тип товара), которые позволяют ограничить объем анализируемых данных.
в рамках отфильтрованных данных производится группировка данных (о продажах) по требуемым параметрам (“по месяцам”- время, “по фирмам-производителям” – тип товара) с последующим вычислением агрегатных функций.
Результаты запроса, как правило, оформляются в таблицу (поскольку именно двумерный срез многомерного представления данных легко доступен для анализа). В колонках и столбцах этой таблицы располагаются параметры запроса, по которым производилась группировка; отдельные ячейки таблиц могут оказаться пустыми (например, в таком-то штате не было продано ни одного телевизора данного производителя) – в таком случае соответствующая ячейка должна автоматически инициализироваться нулевым значением. Разумеется, подобную таблицу можно легко и очень эффектно отобразить графически с помощью развитых современных графических средств.
Нередко в задачах анализа после получения матрицы-выборки необходимо провести ее углубленную статистическую обработку для выявления корреляционных зависимостей между различными параметрами. Подобный анализ требует от аналитика очень хорошей математической подготовки - наряду с глубоким знанием предметной области. Между тем, удачно подобранное графическое представление данных часто позволяет визуально выявлять корреляционные зависимости не менее эффективно, чем это позволяют делать значительно более сложные методы математической статистики.
В зависимости от способа физической реализации многомерные базы данных делятся на две основные категории:
– когда программный продукт, реализующий OLAP-сервер, использует специализированные (отличные от реляционных) внутренние структуры данных для хранения многомерных данных. Этот подход, например, воплощен в таких продуктах, как Oracle Express Server и Sybase IQ.
– когда для физической реализации многомерной модели данных используется реляционный сервер баз данных. Этот подход использовала компания Informix в своем OLAP-средстве Informix MetaCube, где для хранения данных используется любой из серверов Informix (OnLine Dynamic Server, Extended Parallel Server или Informix Universal Server). К такому же подходу пришла компания Oracle, заменив технологию Express Server на OLAP option.
Каждый из подходов имеет определенные преимущества и недостатки. К достоинству реляционного OLAP можно отнести исключительно высокую масштабируемость, обусловленную очень хорошей маштабируемостью серверов БД (у компании Informix есть примеры реально работающих хранилищ данных, содержащих несколько терабайт данных), и большую гибкость построения прикладных решений, когда многомерную организацию БД можно комбинировать с любой другой моделью в рамках реляционных СУБД.
Схема “звезда” - основа реляционного OLAP.
В основе реляционного OLAP лежит схема БД “звезда” (star schema). Остановимся на ней более подробно.
Модель данных состоит из двух типов таблиц: одной таблицы фактов (fact table) – центр “звезды” – и нескольких таблиц измерений (dimension table) по числу измерений в модели данных – лучи “звезды”.
Таблица фактов обычно содержит одну или несколько колонок типа DECIMAL, дающих числовую характеристику какому-то аспекту деятельности компании (например, объем продаж для торговой компании или сумма платежей для банка), и несколько целочисленных колонок-ключей для доступа к таблицам измерений.
Таблицы измерений расшифровывают ключи, на которые ссылается таблица фактов; например, таблица “products” измерения “товары” базы данных торговой компании может содержать сведения о названии товара, его производителе, типе товара. За счет использования специальной структуры таблицы измерений реализуется иерархия измерений, в том числе ветвящаяся.
Обычно данные в таблицах-измерениях денормализованы: ценой несколько неэффективного использования дискового пространства удается уменьшить число участвующих в операции соединения таблиц, что обычно приводит к сильному уменьшению времени выполнения запроса. Иногда, тем не менее, требуется произвести нормализацию таблиц-измерений; такая схема носит название “снежинка” (snowflake schema).
SQL-запрос к схеме “звезда” обычно содержит в себе:
одно или несколько соединений таблицы фактов с таблицами измерений;
несколько фильтров (SQL-оператор WHERE), применяемых к таблице фактов или таблицам измерений;
группировку и агрегирование по требуемым элементам иерархии измерений (dimension elements).