21.5. Хранилища данных и магазины данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Один из методов организации данных, обеспечивающий подобный тип доступа, на­зывался "многокаталоговой" базой данных⁹. Такие базы данных могли бы содержать большие основные файлы данных, включающие данные производственных транзак­ций, вместе с тремя отдельными файлами "каталогов" для продуктов, периодов време­ни и заказчиков. Рассматриваемые файлы каталогов схожи с индексами, в которых со­держатся указатели на записи в файле данных, но элементы каталога могут размещать­ся пользователем явно ("обслуживание каталога") и каталоги могут содержать допол­нительную информацию (например, адрес заказчика), которая затем может быть уда­лена из файла данных. Следует отметить, что файлы каталогов обычно малы по срав-. нению с файлами данных.

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

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

Замечание. Смысл термина "размерность" разъясняется в разделе 21.6.

В целях демонстрации предположим, что снова необходимо модифицировать базу данных поставщиков и деталей, на этот раз так, чтобы показать каждую поставку за оп­ределенное время, когда эта поставка осуществлялась. Присвоим поставке за определен­ный период идентификатор f TP и введем еще одну таблицу TP, чтобы связать идентифи­каторы с соответствующими периодами. Теперь исправленная таблица SP и новая табли­ца периодов времени будут выглядеть так, как показано на рис. 21.3¹⁰. В соответствии с терминологией схем типа "звезда" таблица поставок SP представляет собой таблицу фак­тов, а таблица периодов времени TP — таблицу размерностей (также в эту схему входят таблица поставщиков S и таблица деталей Р, как показано на рис. 21.4).

⁹ Не имеет ничего общего с каталогами баз данных в современном смысле этого термина. *° В столбцах FROM и ТО таблицы TP содержатся данные типа временной отметки. Для упро­щения на рисунке показаны не реальные значения временных отметок, а символические обозначения.

Замечание.Напомним, что общие вопросы обработки данных, представляющих пе­риоды времени, будут подробно рассмотрены в главе 22.

S I S# I SNAME I STATUS I CITY I TP |TP#| FROM* | TO

_{t T}

SP S# P# TP# QTY

P I P# I PNAME J COLOR | WEIGHT | CITY

Рис. 21.4. Схема типа "звезда" для базы данных поставщиков и деталей (с периодами времени)

При обработке запросов в схеме типа "звезда" таблицы размерности обычно ис­пользуются для поиска всех необходимых сочетаний внешних ключей, после чего най­денные сочетания используются для доступа к таблице фактов. Предположим, что доступ к таблице размерности и соответствующий доступ к таблице фактов связаны в единый запрос. Тогда лучшим способом реализации такого запроса, как правило, яв­ляется так называемое звездообразное соединение. Звездообразное соединение пред­ставляет собой специальную стратегию реализации операции соединения, которая от­личается от обычных стратегий тем, что соединение преднамеренно начинается с вы­числения декартова произведения, а именно — декартова произведения таблиц раз­мерностей. Как мы уже видели в главе 17, оптимизаторы запросов обычно пытаются избежать вычисления декартова произведения [17.54], [17.55]. Однако в данном случае формирование, в первую очередь, декартова произведения таблиц значительно мень­шей размерности, а затем использование результата для просмотра таблицы фактов очень больших размеров с помощью индексов почти всегда эффективнее любой дру­гой стратегии. Поэтому для эффективной обработки запросов в схеме типа "звезда" традиционные оптимизаторы нуждаются в переработке.

У читателя может возникнуть вопрос, в чем же отличие схемы типа "звезда" от схемы, которую можно было считать настоящим реляционным проектом. Действи­тельно, простая схема типа "звезда", подобная рассмотренной выше, может показать­ся очень похожей на настоящий реляционный проект (и даже идентичной ему). Одна­ко, к сожалению, в общем случае при использовании схем типа "звезда" возникает це­лый ряд проблем.

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

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

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

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

5. Опять же, из-за отсутствия строгости таблицы размерностей Могут оказаться неоднородными. Такая ошибка обычно возникает, когда таблица фактов ис­пользуется для размещения данных из разных уровней обобщения. Например, мы могли бы (ошибочно) добавить в таблицу поставок строки, содержащие итоговые количества деталей, поставленных за каждый день, каждый месяц, каждый квартал, каждый год и даже сводный текущий итог. Прежде всего, об­ратите внимание, что такое изменение приводит к тому, что столбцы иденти­фикатора периода (#ТР) и количества (QTY) в таблице SP будут иметь не едино­образные значения. Предположим теперь, что столбцы FROM и ТО в таблице размерности TP заменены комбинациями столбцов YEAR, MONTH, DAY и т.д. Тогда все эти столбцы YEAR, MONTH, DAY и др. должны будут допускать NULL-значения. Кроме того, возможно, потребуется также столбец флажка, указы­вающего тип соответствующего периода времени.

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

И наконец отметим, что одним из вариантов схемы типа "звезда" является схема ти­па "снежинка", которая предусматривает нормализацию таблицы размерности. Назва­ние схемы также произошло от ее изображения в виде диаграммы "сущность/связь". Из­редка можно услышать термины схема типа "созвездие" и схема типа "метель" с оче­видным (?) смыслом.