Меню

Хранилища данных таблица измерений



Измерение (хранилище данных) — Dimension (data warehouse)

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

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

Эти функции часто называют «срезать и играть в кости». Типичный пример хранилища данных включает продажи как меру, а клиента и продукт как измерения. При каждой продаже покупатель покупает товар. Данные можно разрезать, удалив всех клиентов, за исключением изучаемой группы, а затем разделить на части, сгруппировав по продуктам.

Обычно измерения в хранилище данных организованы внутри в одну или несколько иерархий. «Дата» — это обычное измерение с несколькими возможными иерархиями:

  • «Дни (сгруппированы в) Месяцы (которые сгруппированы в) Годы»,
  • «Дни (сгруппированы в) Недели (которые сгруппированы в) Годы»
  • «Дни (сгруппированы в) Месяцы (которые сгруппированы в) Кварталы (которые сгруппированы в) Годы»
  • и т.п.

Содержание

Согласованный размер

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

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

Согласованные измерения — это либо идентичные, либо строгие математические подмножества наиболее детализированного и подробного измерения. Таблицы измерений не согласовываются, если атрибуты помечены по-другому или содержат разные значения. Согласованные размеры бывают разных вкусов. На самом базовом уровне согласованные измерения означают одно и то же со всеми возможными таблицами фактов, к которым они присоединены. Таблица измерения даты, связанная с фактами продаж, идентична измерению даты, связанной с фактами запасов.

Размер мусора

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

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

Решение этой проблемы состоит в том, чтобы идентифицировать все атрибуты и затем помещать их в одно или несколько ненужных измерений. Одно измерение нежелательной почты может содержать несколько индикаторов истина / ложь или да / нет, которые не связаны друг с другом, поэтому было бы удобно преобразовать индикаторы в более описывающий атрибут. Примером может служить индикатор того, прибыла ли посылка: вместо того, чтобы указывать это как «да» или «нет», она будет преобразована в «прибыла» или «ожидает» в измерении нежелательной почты. Разработчик может выбрать создание таблицы измерений так, чтобы она содержала все индикаторы, встречающиеся с каждым другим индикатором, чтобы охватить все комбинации. Это устанавливает фиксированный размер для самой таблицы , которая будет 2 х строк, где х представляет собой количество показателей. Это решение подходит в ситуациях, когда разработчик ожидает столкнуться с множеством различных комбинаций и где возможные комбинации ограничены приемлемым уровнем. В ситуации, когда количество индикаторов велико, что создает очень большую таблицу, или когда разработчик ожидает встретить только несколько возможных комбинаций, было бы более целесообразно строить каждую строку в измерении нежелательной почты по мере появления новых комбинаций. . Чтобы ограничить размер таблиц, несколько измерений нежелательной почты могут быть уместны в других ситуациях в зависимости от корреляции между различными индикаторами.

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

Вырожденное измерение

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

Ролевое измерение

Размеры часто повторно используются для нескольких приложений в одной базе данных. Например, измерение «Дата» может использоваться для «Даты продажи», а также «Дата доставки» или «Дата найма». Это часто называют «ролевым измерением». Это можно реализовать с помощью представления той же таблицы измерений.

Размер аутригера

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

Сжатое измерение

Согласованные размеры называются сжатыми, если они включают подмножество строк и / или столбцов исходного измерения.

Размер календарной даты

Для представления дат с точностью до дня можно использовать измерение особого типа. На даты будут ссылаться в таблице фактов как на внешние ключи к измерению даты. Первичный ключ измерения даты может быть суррогатным ключом или числом в формате ГГГГММДД.

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

Вместо этого время обычно лучше всего представляется как отметка времени в таблице фактов .

Использование терминов ISO

При ссылке на данные из реестра метаданных, такого как ISO / IEC 11179 , термины представления, такие как «Индикатор» (логическое значение «истина / ложь»), «Код» (набор неперекрывающихся перечислимых значений) обычно используются в качестве измерений. Например, при использовании Национальной модели обмена информацией (NIEM) имя элемента данных будет «PersonGenderCode», а перечисленные значения могут быть «мужской», «женский» и «неизвестный».

Таблица размеров

В хранилищах данных , таблица измерения является одним из множества таблиц компаньонов к таблице фактов .

Таблица фактов содержит бизнес-факты (или меры ) и внешние ключи, которые относятся к ключам-кандидатам (обычно первичным ключам ) в таблицах измерений.

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

Атрибуты измерения должны быть:

  • Verbose (метки, состоящие из полных слов)
  • Описательный
  • Завершено (без пропущенных значений)
  • Дискретно оцениваемый (имеющий только одно значение на строку таблицы измерений)
  • Гарантированное качество (без орфографических ошибок или недопустимых значений)

Строки таблицы измерений однозначно идентифицируются одним ключевым полем. Рекомендуется, чтобы ключевое поле было простым целым числом, поскольку значение ключа не имеет смысла и используется только для объединения полей между таблицами фактов и измерений. В таблицах измерений часто используются первичные ключи, которые также являются суррогатными ключами. Суррогатные ключи часто генерируются автоматически (например, Sybase или SQL Server «столбец идентификации», серийный номер PostgreSQL или Informix, Oracle SEQUENCE или столбец, определенный с помощью AUTO_INCREMENT в MySQL).

Читайте также:  Спектральные методы измерения температуры

Использование суррогатных ключей измерения дает несколько преимуществ, в том числе:

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

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

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

Согласованные измерения важны для корпоративного характера систем DW / BI, поскольку они способствуют:

  • Последовательность. Каждая таблица фактов фильтруется последовательно, поэтому ответы на запросы помечаются последовательно.
  • Интеграция. Запросы можно детализировать по отдельности в разные таблицы фактов процессов, а затем объединить результаты по общим атрибутам измерения.
  • Сокращение времени разработки до выхода на рынок. Общие размеры доступны без воссоздания.

Со временем атрибуты данной строки в таблице измерений могут измениться. Например, адрес доставки для компании может измениться. Кимбалл называет это явление медленно меняющимся измерением . Стратегии борьбы с такого рода изменениями делятся на три категории:

  • Тип первый: просто перезапишите старое значение (я).
  • Тип два: добавьте новую строку, содержащую новое значение (я), и проведите различие между строками, используя методы управления версиями кортежей .
  • Тип третий: добавьте новый атрибут в существующую строку.

Общие шаблоны

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

Если дата и время суток находятся в одном измерении, это может легко привести к огромному измерению с миллионами строк. Если требуется большое количество деталей, обычно рекомендуется разделить дату и время на два или более отдельных измерения. Измерение времени с долей секунд в день будет иметь только 86400 строк. Более или менее подробное зерно для размеров даты / времени может быть выбрано в зависимости от потребностей. Например, измерения даты могут быть с точностью до года, квартала, месяца или дня, а измерения времени — с точностью до часов, минут или секунд.

Как показывает практика, измерение времени суток следует создавать только в том случае, если необходимы иерархические группировки или есть содержательные текстовые описания для периодов времени в течение дня (например, «вечерняя смена» или «первая смена»).

Если строки в таблице фактов поступают из нескольких часовых поясов, может быть полезно хранить дату и время как по местному, так и по стандартному времени. Это можно сделать, используя два измерения для каждого необходимого измерения даты / времени — одно для местного времени, а другое для стандартного времени. Сохранение даты / времени как в местном, так и в стандартном времени позволит проанализировать, когда факты создаются в локальных условиях, а также в глобальных. Выбранное стандартное время может быть глобальным стандартным временем (например, UTC ), это может быть местное время штаб-квартиры компании или любой другой часовой пояс, который имеет смысл использовать.

Источник

Таблицы фактов и измерений в хранилищах данных

Обычно говорят о четырех наиболее часто встречающихся типах фактов. К ним относятся:

  • факты, связанные с транзакциями (англ. Transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата);
  • факты, связанные с “моментальными снимками” (англ. Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка;
  • факты, связанные с элементами документа (англ. Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);
  • факты, связанные с событиями или состоянием объекта (англ. Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей).

Таблица фактов, как правило, содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа “дата/время” в целочисленном формате — ведь таблица фактов может содержать сотни тысяч или даже миллионы записей, и хранить в ней повторяющиеся текстовые описания, как правило, невыгодно — лучше поместить их в меньшие по объему таблицы измерений. При этом как ключевые, так и некоторые неключевые поля должны соответствовать будущим измерениям OLAP-куба. Помимо этого таблица фактов содержит одно или несколько числовых полей, на основании которых в дальнейшем будут получены агрегатные данные.

Для многомерного анализа пригодны таблицы фактов, содержащие как можно более подробные данные (то есть соответствующие членам нижних уровней иерархии соответствующих измерений). Бывает предпочтительнее взять за основу факты продажи товаров отдельным заказчикам, а не суммы продаж для разных стран — последние все равно будут вычислены OLAP-средством, в случае использования такового. Исключение можно сделать, пожалуй, только для клиентских OLAP-средств, поскольку в силу ряда ограничений они не могут манипулировать большими объемами данных.

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

Таблица фактов связана с таблицами измерений с помощью внешнего ключа.

Источник

Введение в OLAP: часть 2. Хранилища данных

Алексей Федоров,
Наталия Елманова, преподаватель УКЦ «Interface Ltd»,
КомпьютерПресс 5’2001

Первая статья данного цикла (см. Введение в OLAP: часть 1. Основы OLAP) была посвящена основам OLAP (On-Line Analytical Processing) — технологии многомерного анализа данных. В ней мы обсудили концепции хранилищ данных и OLAP, требования к хранилищам данных и OLAP-средствам, логическую организацию OLAP-данных, а также основные термины и понятия, относящиеся к многомерному анализу.

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

Типичная структура хранилищ данных

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

Типичная структура хранилища данных существенно отличается от структуры обычной реляционной СУБД. Как правило, эта структура денормализована (это позволяет повысить скорость выполнения запросов), поэтому может допускать избыточность данных.

Для дальнейших примеров мы снова воспользуемся базой данных Northwind, входящей в комплекты поставки Microsoft SQL Server и Microsoft Access. Ее структура данных приведена на рис. 1.

Рис. 1. Структура базы данных Northwind

Основными составляющими структуры хранилищ данных являются таблица фактов (fact table) и таблицы измерений (dimension tables).

Таблица фактов

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

  • факты, связанные с транзакциями (Transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата);
  • факты, связанные с «моментальными снимками» (Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка;
  • факты, связанные с элементами документа (Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);
  • факты, связанные с событиями или состоянием объекта (Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей).

Для примера рассмотрим факты, связанные с элементами документа (в данном случае счета, выставленного за товар).

Таблица фактов, как правило, содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа «дата/время» — ведь таблица фактов может содержать сотни тысяч или даже миллионы записей, и хранить в ней повторяющиеся текстовые описания, как правило, невыгодно — лучше поместить их в меньшие по объему таблицы измерений. При этом как ключевые, так и некоторые неключевые поля должны соответствовать будущим измерениям OLAP-куба. Помимо этого таблица фактов содержит одно или несколько числовых полей, на основании которых в дальнейшем будут получены агрегатные данные.

Пример таблицы фактов, которая может быть построена на основе базы данных Northwind, приведен на рис. 2.

Рис. 2. Пример таблицы фактов

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

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

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

Таблицы измерений

Таблицы измерений содержат неизменяемые либо редко изменяемые данные. В подавляющем большинстве случаев эти данные представляют собой по одной записи для каждого члена нижнего уровня иерархии в измерении. Таблицы измерений также содержат как минимум одно описательное поле (обычно с именем члена измерения) и, как правило, целочисленное ключевое поле (обычно это суррогатный ключ) для однозначной идентификации члена измерения. Если будущее измерение, основанное на данной таблице измерений, содержит иерархию, то таблица измерений также может содержать поля, указывающие на «родителя» данного члена в этой иерархии. Нередко (но не всегда) таблица измерений может содержать и поля, указывающие на «прародителей», и иных «предков» в данной иерархии (это обычно характерно для сбалансированных иерархий), а также дополнительные атрибуты членов измерений, содержавшиеся в исходной оперативной базе данных (например, адреса и телефоны клиентов).

Каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов.

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

Пример таблицы измерений приведен на рис. 3.

Рис. 3. Пример таблицы измерений

Рис. 4. Пример схемы «звезда»

Если же хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название «снежинка» (snowflake schema). Дополнительные таблицы измерений в такой схеме, обычно соответствующие верхним уровням иерархии измерения и находящиеся в соотношении «один ко многим» в главной таблице измерений, соответствующей нижнему уровню иерархии, иногда называют консольными таблицами (outrigger table). Пример схемы «снежинка» приведен на рис. 5.

Рис. 5. Пример схемы «снежинка»

Отметим, что даже при наличии иерархических измерений с целью повышения скорости выполнения запросов к хранилищу данных нередко предпочтение отдается схеме «звезда».

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

В случае несбалансированной иерархии (например, такой, которая может быть основана на таблице Employees базы данных Northwind, имеющей поле EmployeeID, которое одновременно является и первичным, и внешним ключом и отражает подчиненность одних сотрудников другим (см. рис. 1) в схему «снежинка» также следует вносить коррективы. В этом случае обычно в таблице измерений присутствует связь, аналогичная соответствующей связи в оперативной базе данных.

Еще один пример отступления от правил — наличие нескольких разных иерархий для одного и того же измерения. Типичные примеры таких иерархий — иерархии для календарного и финансового года (при условии, что финансовый год начинается не с 1 января), или с различными способами группировки членов измерения (например, группировать товары можно по категориям, а можно и по компаниям-поставщикам). В этом случае таблица измерений содержит поля для всех возможных иерархий с одними и теми же членами нижнего уровня, но с разными членами верхних уровней (пример такой таблицы приведен на рис. 3).

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

Более подробно о проектировании хранилищ данных и одном из CASE-инструментов, способных упростить процесс их создания, — CA ERwin, рассказано в статье Сергея Маклакова «Хранилища данных и их проектирование с помощью CA ERwin», КомпьютерПресс, CD-ROM № 1’2001).

Следует сказать, что для создания реляционных хранилищ данных нередко применяются специализированные СУБД, хранение данных в которых оптимизировано с точки зрения скорости выполнения запросов. Примером такого продукта является Sybase Adaptive Server IQ, реализующий нетрадиционный способ хранения данных в таблицах (не по строкам, а по столбцам). Однако создавать хранилища можно и в обычных реляционных СУБД.

Итак, обсудив типичную структуру хранилища данных, на основе которых обычно строятся OLAP-кубы, вернемся к созданию OLAP-кубов и поговорим о том, какими бывают OLAP-инструменты.

OLAP на клиенте и на сервере

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

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

Если исходные данные содержатся в настольной СУБД, вычисление агрегатных данных производится самим OLAP-средством. Если же источник исходных данных — серверная СУБД, многие из клиентских OLAP-средств посылают на сервер SQL-запросы, содержащие оператор GROUP BY, и в результате получают агрегатные данные, вычисленные на сервере.

Как правило, OLAP-функциональность реализована в средствах статистической обработки данных (из продуктов этого класса на российском рынке широко распространены продукты компаний StatSoft и SPSS) и в некоторых электронных таблицах. В частности, неплохими средствами многомерного анализа обладает Microsoft Excel 2000. С помощью этого продукта можно создать и сохранить в виде файла небольшой локальный многомерный OLAP-куб и отобразить его двух- или трехмерные сечения.

Многие средства разработки содержат библиотеки классов или компонентов, позволяющие создавать приложения, реализующие простейшую OLAP-функциональность (такие, например, как компоненты DecisionCube в Borland Delphi и Borland C++Builder). Помимо этого многие компании предлагают элементы управления ActiveX и другие библиотеки, реализующие подобную функциональность.

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

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

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

Преимущества применения серверных OLAP-средств по сравнению с клиентскими OLAP-средствами сходны с преимуществами применения серверных СУБД по сравнению с настольными: в случае применения серверных средств вычисление и хранение агрегатных данных происходят на сервере, а клиентское приложение получает лишь результаты запросов к ним, что позволяет в общем случае снизить сетевой трафик, время выполнения запросов и требования к ресурсам, потребляемым клиентским приложением. Отметим, что средства анализа и обработки данных масштаба предприятия, как правило, базируются именно на серверных OLAP-средствах, например, таких как Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, продуктах компаний Crystal Decisions, BusinessObjects, Cognos, SAS Institute. Поскольку все ведущие производители серверных СУБД производят (либо лицензировали у других компаний) те или иные серверные OLAP-средства, выбор их достаточно широк и почти во всех случаях можно приобрести OLAP-сервер того же производителя, что и у самого сервера баз данных.

Отметим, что многие клиентские OLAP-средства (в частности, Microsoft Excel 2000, Seagate Analysis и др.) позволяют обращаться к серверным OLAP-хранилищам, выступая в этом случае в роли клиентских приложений, выполняющих подобные запросы. Помимо этого имеется немало продуктов, представляющих собой клиентские приложения к OLAP-средствам различных производителей.

OLAP-серверы могут хранить многомерные данные разными способами, которые мы и обсудим в следующем разделе.

Технические аспекты многомерного хранения данных

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

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

Как исходные, так и агрегатные данные могут храниться либо в реляционных, либо в многомерных структурах. Поэтому в настоящее время применяются три способа хранения данных:

  • MOLAP (Multidimensional OLAP) –— исходные и агрегатные данные хранятся в многомерной базе данных. Хранение данных в многомерных структурах позволяет манипулировать данными как многомерным массивом, благодаря чему скорость вычисления агрегатных значений одинакова для любого из измерений. Однако в этом случае многомерная база данных оказывается избыточной, так как многомерные данные полностью содержат исходные реляционные данные.
  • ROLAP (Relational OLAP) — исходные данные остаются в той же реляционной базе данных, где они изначально и находились. Агрегатные же данные помещают в специально созданные для их хранения служебные таблицы в той же базе данных.
  • HOLAP (Hybrid OLAP) — исходные данные остаются в той же реляционной базе данных, где они изначально находились, а агрегатные данные хранятся в многомерной базе данных.

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

Отметим также, что подавляющее большинство современных OLAP-средств не хранит «пустых» значений (примером «пустого» значения может быть отсутствие продаж сезонного товара вне сезона).

Заключение

В данной статье мы рассмотрели типичную структуру реляционных хранилищ данных. Итак, теперь мы знаем, что:

  • типичная структура хранилища данных существенно отличается от структуры обычной реляционной СУБД — как правило, она денормализована;
  • основными составляющими структуры хранилищ данных являются таблица фактов (fact table) и таблицы измерений (dimension tables);
  • таблица фактов является основной таблицей хранилища данных. Обычно она содержит сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться; таблица фактов, как правило, содержит уникальный составной ключ, состоящий из первичных ключей таблиц измерений. При этом как ключевые, так и некоторые неключевые ее поля должны соответствовать будущим измерениям OLAP-куба. Помимо этого таблица фактов содержит одно или несколько числовых полей, на основании которых в дальнейшем вычисляются агрегатные данные; таблицы измерений содержат неизменяемые либо редко изменяемые данные — как правило, по одной записи для каждого члена нижнего уровня иерархии в измерении;
  • таблицы измерений содержат как минимум одно описательное поле и, как правило, целочисленное ключевое поле для однозначной идентификации члена измерения;
  • каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов;
  • если каждое измерение содержится в одной таблице измерений, такая схема хранилища данных носит название «звезда». Если же хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название «снежинка».

Далее мы обсудили особенности клиентских и серверных OLAP-средств. Мы узнали, что:

  • клиентские OLAP-средства представляют собой приложения, осуществляющие вычисление агрегатных данных (сумм, средних величин, максимальных или минимальных значений) и их отображение, при этом сами агрегатные данные содержатся в кэше внутри адресного пространства такого OLAP-средства;
  • в серверных OLAP-средствах сохранение и изменение агрегатных данных, а также поддержка содержащего их хранилища осуществляются отдельным приложением или процессом, называемым OLAP-сервером;
  • в случае применения серверных средств вычисление и хранение агрегатных данных происходят на сервере, что позволяет в общем случае снизить требования к ресурсам, потребляемым клиентским приложением, а также сетевой трафик и время выполнения запросов.
  • наконец, мы рассмотрели различные технические аспекты многомерного хранения данных. Мы узнали, что в настоящее время применяются три способа хранения данных:
    • MOLAP (Multidimensional OLAP) — и детальные, и агрегатные данные хранятся в многомерной базе данных. В этом случае многомерные данные полностью содержат исходные детальные данные;
    • ROLAP (Relational OLAP) — детальные данные остаются в той же реляционной базе данных, где они находились изначально. Агрегатные же данные помещаются в специально созданные для их хранения служебные таблицы в той же самой базе данных;
    • HOLAP (Hybrid OLAP) — детальные данные остаются в той же реляционной базе данных, где они и находились изначально, а агрегатные данные хранятся в многомерной базе данных.

Мы также узнали, что подавляющее большинство современных OLAP-средств не хранит «пустых» значений.

В следующей статье данного цикла мы рассмотрим архитектуру Microsoft Analysis Services — OLAP-сервера фирмы Microsoft, входящего в комплект поставки Microsoft SQL Server 2000 Enterpise Edition.

Источник