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

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

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

Хранилище данных

Подобно банкам оперативных данных (а также магазинам данных; см. следующий подраздел), хранилище данных - это специальная база данных. Этот термин возник, по-видимому, в конце 1980 года [21.13], [21.17], хотя соответствующая концепция появилась несколько позднее. В [21.18] хранилище данных определяется как предметно-ориентированное, интефированное, постоянное, изменяемое во времени хранилище данных для поддержки управленческих решений . Здесь термин постоянное означает, что, будучи введенными, данные впоследствии не изменяются, хотя и могут быть удалены. Хранилища данных появились по двум причинам: во-первых, для систем поддержки принятия решений необходимо было предоставить отдельный, чистый, согласованный источник данных и, во-вторых, этой цели следовало достичь, не оказывая влияния на функционирование оперативных систем.

Согласно определению ожидаемая рабочая нагрузка на хранилище данных- это ожидаемая рабочая нагрузка в системе поддержки принятия решений. Поэтому можно ожидать, что хранилище данных будет подвергаться частым обращениям с запросами, а также периодической пакетной обработке для обновления данных. Кроме того, для хранилищ данных характерен весьма большой объем занимаемой памяти - часто он превышает 500 Гбайт и может увеличиваться на 50% в год. Вследствие этого бывает фудно добиться высокой производительности системы, хотя и нельзя сказать, что это невозможно. Также могут возникнуть проблемы, связанные с расширяемостью базы данных. Причины подобных затруднений обычно кроются в ошибках проектирования базы данных (обсуждавшихся в последнем подразделе раздела 21.3), неэффективном использовании реляционных операций (что обсуждалось в разделе 21.2), наличии недостатков в

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

Магазины данных

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

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

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

Существует три основных подхода к созданию магазинов данных.

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

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

ща данных). Такой подход может быть приемлемым, когда хранилище данных по каким-то причинам недоступно, например по финансовым, оперативным или даже политическим (или же хранилища данных может еще просто не существовать; см. комментарии к следующему подходу).

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

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

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

И еще одно замечание. Поскольку пользователи магазинов данных часто применяют определенные аналитические инструменты, в физическом проекте обычно указывается, по крайней мере частично, какие именно конкретные инструменты должны использоваться (см. обсуждение двух видов аналитической обработки ROLAP и MOLAP в разделе 21.6). Такое неудовлетворительное состояние дел может привести к созданию многомерных схем (рассматриваются ниже), которые не отвечают правилам надежного проектирования.

Многомерные схемы

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