Введение в системы БД (542480), страница 218
Текст из файла (страница 218)
Подобные соображения привели к появлению концепции магазинов данных. На самом деле вокруг точного определения термина магазин данных еще ведутся споры. Для наших целей магазин данных можно определить как "специализированное, предметно-ориентированное, интегрированное, непостоянное, изменяемое во времени хранилище данных для поддержки конкретного подмножества управленческих решений". Как видим, ключевое отличие между магазинами данных и хранилищами данных заключается в том, что магазины данных — спсциатизированцые и иепостояиные.
Под характеристикой специашзированцые подразумевается, что они содержат данные для поддержки лишь некоторой конкретной области делового анализа, а пол характеристикой непостоянные подразумевается, что пользователи могут обновлять данные и, возможно, даже создавать в каких-то целях новые данные, например новые таблицы. Существует три основных подхода к созданию магазинов данных.
° Данные просто извлекаются из хранилища данных — по существу, следуя подходу "разделяй и властвуй" по отношению к процессу поддержки принятия решений в целом. Это позволяет достичь более высокого уровня производительности и масштабируемости. Обычно извлеченные данные загружаются в базу данных с физической схемой, которая имеет близкое сходство с соответствующим подмножеством хранилища данных. Часто такая схема может быть даже несколько упрощена благодаря узкой специализации магазинов данных, ° Несмотря на то что хранилища данных подразумевают предоставление информации с "единой точки зрения", независимо вполне могут создаваться еще и магазины данных (т.е. поддерживаемые не посредством извлечения данных из хранили- Глава 21. Поддержка принятия решений 831' ша данных).
Такой подход может быть приемлемым, когда хранилище данных по каким-то причинам недоступно, например по финансовым, оперативным или даже политическим (или же хранилища данных может еще просто не существовать; см, комментарии к следующему подходу). ° В некоторых установках используется обратный подход: сначала создаются необходимые магазины данных, а полное хранилище данных впоследствии строится как объединение информации из различных магазинов данных. Для последних двух подходов обычно характерны проблемы, связанные с семантическим несоответствием. Независимые магазины данных особенно чувствительны к таким проблемам, поскольку не существует очевидных способов проверить семантическое несоответствие, если базы данных спроектированы независимо.
Консолидация магазинов данных в одно хранилище данных в общем случае заканчивается неудачно, кроме тех ситуаций, когда сначала создается единая логическая схема для хранилища данных, е уже затем — схемы лля отдельных магазинов данных, производные от схемы полного хранилища данных. (Безусловно, при необходимости схема для хранилища данных может постепенно расширяться — с целью включения данных о каждом новом магазине; конечно, если она была лолжным образом спроектирована.) Замечание по проектированию магаэьвов данных. При проектировании базы данных поддержки принятия решений важно определиться с уровнем детализации базы данных.
Под термином уровень детатизаиии здесь подразумевается самый низкий уровень обобщения данных, предназначенных для хранения в базе данных. Для большинства приложений поддержки принятия решений рано или поздно требуется доступ к детальным данным, так что с уровнем детализации для хранилищ данных определиться несложно. Но для магазинов данных это сделать несколько труднее. Если уровень детализации занижен и данные нижнего уровня используются не очень часто, то извлечение больших объемов детальных данных из хранилища данных и их сохранение в магазине данных может оказаться весьма неэффективным решением. С другой стороны, иногда трудно точно установить, какой именно нижний уровень детализации реально необходим.
В тех случаях, когда вместе с обобщенными данными, сохраняемыми в магазинах данных, необходимы еше и детальные данные, можно обращаться непосредственно в хранилище данных. В то же время полное обобщение данных вообще невозможно, поскольку в результате применения множества способов обобщения данных будут получены очень большие объемы итоговых данных. Далее, в разделе 21.6, мы обсудим этот вопрос подробнее. И еше одно замечание. Поскольку пользователи магазинов данных часто применяют определенные аналитические инструменты, в физическом проекте обычно указывается, по крайней мере частично, какие именно конкретные инструменты должны использоваться (см, обсуждение двух видов аналитической обработки КОЕАР и МОЕАР в разделе 21.6). Такое неудовлетворительное состояние дел может привести к созданию "многомерных схем" (рассматриваются ниже), которые не отвечают правилам надежного проектирования.
Многомерные схемы Предположим, что необходимо накапливать исторические сведения о выполнении производственных транзакций для последующего анализа. Как отмечалось в разделе 21.1, ранние системы поддержки принятия решений сохранили бы эту историю в виде обыкновенного файла, доступ к которому осуществлялся бы посредством послелова- 832 Часть )г. дополнительные аспекты тельного просмотра.
Однако по мере роста объема данных для просмотра файла все более выгодной (с различных точек зрения) становится поддержка прямо~о доступа к записям файла. Например, может быть желательно, чтобы существовала возможность поиска всех производственных транзакций, включающих конкретный продукт, или всех производственных транзакций, относящихся к определенному заказчику. Один из методов организации данных, обеспечивающий подобный тип доступа, назывался "многокаталоговой" базой данныхэ. Такие базы данных могли бы содержать большие основные файлы данных, включающие данные производственных транзакций, вместе с тремя отдельными файлами "каталогов" для продуктов, периодов времени и заказчиков.
рассматриваемые файлы каталогов схожи с индексами, в которых содержатся указатели на записи в файле данных, но элементы катало~а мокнут размещаться пользователем явно ("обслуживание каталога") и каталоги могут содержать дополнительную информацию (например, адрес заказчика), которая затем может быть удалена из файла данных. Следует отметить, что файлы каталогов обычно малы по срав, нению с файлами данных.
При такой организации данных более эффективно используется память и затраты на ввод-вывод гораздо меньше, чем при использовании первого проекта, предполагающего наличие простых линейных файлов данных. Отметим, в частности, что информация о продукте, периоде времени и заказчике в основном файле данных теперь сводится просто к идентификаторам продукта, периода времени и заказчика. Если этот подход имитировать в реляционной базе данных, то файл данных и файлы катало~он станут таблицами (образами соответствующих файлов), указатели в каталогах файлов станут первичными ключами в таблицах, которые служат образами файлов каталогов, а идентификаторы в файле данных станут внешними ключами в таблице, соответствующей этому файлу данных. Обычно эти первичные и внешние ключи полностью индексированы. При таком соответствии образ файла данных называют таблицей фактов, а образы файлов каталогов — таблицами размерностей.
Весь проект называют многомерным или имеющим схему типа "звезда" из-за его вида, если начертить соответствующую диаграмму "сущность!связь" (таблица фактов будет окружена таблицами размерностей и связана с ними). Замечание. Смысл термина "размерность" разъясняется в разделе 21.6. В целях демонстрации предположим, что снова необходимо модифицировать базу данных поставщиков и деталей, на этот раз так, чтобы показать каждую поставку за определенное время, когда эта поставка осуществлялась.
Присвоим поставке за определенный период идентификатор (1ТР и введем еше одну таблицу ТР, чтобы связать идентификаторы с соответствующими периодами, Теперь исправленная таблица ЯР и новая таблица периодов времени будут выглядеть так, как показано на рис. 21.3'о. В соответствии с терминологией схем типа "звезда" таблица поставок ЯР представляет собой таблицу фактов, а таблица периодов времени ТР— таблицу размерностей (также в эту схему входят таблица поставщиков Я и таблица деталей Р, как показано на рис. 21.4). Замечание. Напомним, что общие вопросы обработки данных, представляющих периоды времени, будут подробно рассмотрены в главе 22.
О Не имеет ничего общего с каталогами баз данныл в современнач слзысле этого термина. ГО В стачбцол Ряби 70 таблицы ТР содерзкатся данные типа врелзенной отметки. Для упрощения на рисунке показаны не реальные значен~т временныл отчеток, а символические обозначения 833 Глава 21, Поддержка принятия решений Рис. 21.3. Прииер таблицы фактов ($Р) и таблииы размерностей (зР) Рис. 21.4. Схема типа "звезда" для базы данных поставщиков и деталей (с периадаии времени) При обработке запросов в схеме типа "звезда" таблицы размерности обычно используются для поиска всех необходимых сочетаний внешних ключей, после чего найденные сочетания используются для доступа к таблице фактов. Предположим, что доступ к таблице размерности и соответствуюший доступ к таблице фактов связаны в единый запрос.
Тогда лучшим способом реализации такого запроса, как правило, является так называемое звездообразное соединение. Звездообразное соединение представляет собой специальную стратегию реализации операции соединения, которая отличается от обычных стратегий тем, что соединение преднамеренно начинается с вычисления декартова произведения, а именно — декартова произведения таблиц размерностей.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
