Главная » SQL, Базы данных » ХРАНИЛИЩА ДАННЫХ И МАГАЗИНЫ ДАННЫХ

0

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

Примечание. Отметим в качестве небольшого отступления, что так было не  всегда.

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

преимущества от совместного функционирования оперативных систем и систем  поддержки принятия решений находят все большее понимание (см. [21.9]). Однако подробное рассмотрение интеграции этих систем выходит за рамки данной главы.

Тем не менее, несмотря на сказанное в предыдущем абзаце, остается неоспоримым тот факт, что, по крайней мере, ко времени написания книги данные систем поддержки

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

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

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

По определению ожидаемая рабочая нагрузка на хранилище данных обусловлена нагрузкой в системе поддержки принятия решений. Поэтому  можно  предположить, что хранилище данных будет подвергаться частым обращениям с запросами, кроме того, в ней будет периодически осуществляться обработка в пакетном режиме для обновления данных. К тому же для хранилищ данных характерен весьма большой объем занимаемой памяти — часто он составляет многие терабайты, а увеличение этого объема может достигать 50% в  год или даже больше. Вследствие этого бывает трудно добиться высокой производительности системы, хотя и нельзя сказать, что это невозможно. Могут  также возникнуть проблемы, связанные с масштабируемостью базы данных. Причины подобных затруднений обычно включают: а) ошибки проектирования  базы данных (обсуждавшихся в последнем подразделе раздела 22.3); б) неэффективное использование реляционных операций (что было кратко описано в разделе 22.2); в) наличие недостатков в реализации реляционной модели в  целевой СУБД; г) недостаточные возможности масштабирования, предусмотренные в самой целевой СУБД; д) наличие ошибок в архитектуре проекта, ограничивающих объемы и препятствующих масштабированию платформы. Пункты а) и б) уже рассматривались в этой главе, п. в) подробно обсуждался в части II и в других главах книги, а описаниепп. г) и д) выходит за рамки данной книги.

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

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

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

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

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

Ниже описаны три основных подхода к созданию магазинов данных.

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

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

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

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

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

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

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

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

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

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

7Здесь слово "каталог" не имеет ничего общего скаталогами баз данных в современном смысле этоготермина.

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

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

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

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

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

В целях демонстрации предположим, что снова необходимо модифицировать  базу данных поставщиков и деталей, но на этот раз таким образом, чтобы  показать  каждую поставку за определенный период времени, когда осуществлялась эта поставка. Присвоим поставке за определенный период идентификатор ТI# и  введем еще одну таблицу тт., чтобы связать идентификаторы с  соответствующими  периодами. Теперь исправленная таблица SP и новая таблица периодов времени TI будут выглядеть так, как показано на рис. 22.38. В  соответствии с  терминологией схем типа "звезда", таблица поставок SP представляет собой таблицу фактов, а таблица периодов времени TI — таблицу размерностей (в эту схему также входят таблица поставщиков S и таблица деталей Р, как показано на рис. 22.4).

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

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

8 В столбцах FROM и ТО таблицы TI содержатся данные типа временной отметки. Для упрощения rfa рисунке показаны не реальные значениявременныхотметок,асимволическиеобозначения.

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

Рис. 22.3. Пример таблицы фактов (SP) и таблицы размерностей (TI)

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

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

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

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

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

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

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

MONTH, DAY И Т.Д. Тогда все ЭТИ столбцы YEAR, MONTH, DAY И др.

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

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии