Введение в системы БД (542480), страница 217
Текст из файла (страница 217)
проверка их целостности); в) построение всех необходимых индексов. Кратко прокомментируем каждый из этих этапов. ° Пересылка данных. Современные СУБД обычно предоставляют утилиты параллельной загрузки данных. Иногда, прежде чем будет выполнена настоящая загрузка, данные преобразуются во внутренний физический формат, требуемый целевой СУБД. (Альтернативный и более эффективный метод предусматривает загрузку в рабочие таблицы, состав которых отражает структуру целевой схемы.
На этих рабочих таблицах может быть выполнена необходимая проверка целостности, а затем для пересылки данных из рабочих таблиц в целевые таблицы может использоваться операция 1КБЕКТ, выполняемая на уровне множеств. ° Проверка целоппности. Большая часть процесса проверки целостности загружаемых данных может быть выполнена еше до реальной загрузки, без обращения к данным, уже находящимся в базе.
Однако некоторые ограничения все же не могут быть проверены без обращения к существующей базе данных. Например„ограничение, контролирующее уникальность значений, в общем случае должно проверяться во время реальной загрузки (или, если загрузка выполняется в пакетном режиме, после ее завершения). ° Построение индексов. Наличие индексов может резко замедлить процесс загрузки данных, поскольку большинство продуктов выполняет обновление индексов при вставке в таблицу каждой строки. Поэтому иногда выгодно удалить индексы перед загрузкой данных, а затем, после ее завершения, создать их заново. Олнако такой подход не булет целесообразным, если количество новых данных по отношению к уже существующим данным мало; в этом случае затраты на создание индексов для 828 Часть г'. Дополнительные аспекты всей таблицы будут существенно больше затрат на обновление индексов.
Кроме того, создание индексов для большой таблицы может быть причиной неустранимых ошибок выделения памяти, причем вероятность их возникновения увеличивается по мере увеличения объема таблицы. Замечание. Большинство СУБД подлерживает режим параллельного создания индексов, призванный ускорить процессы загрузки данных и построения индексов.
Обновление данных В большинстве баз данных поддержки принятия решений (но не во всех) требуется периодическое обновление данных для поддержания их актуальности. Обновление обычно предусматривает частичную загрузку, хотя лля некоторых систем поддержки принятия решений требуется удаление всех данных и их полная перезагрузка. При обновлении возникают те же проблемы, что и при загрузке, и, кроме того, может потребоваться, чтобы обновление выполнялось в то время, когда пользователи обращаются к базе данных. (См.
раздел 9.5 главы 9, а также )9.2) и 19.6).) Банки оперативных данных Банки оперативных данных представляют собой "предметно-ориентированные, интегрированные, изменчивые, т.е, обновляемые, текущие, или почти текущие, коллекции данных" )21.19). Другими словами, банки оперативных данных — это специализированные базы данных.
Термин предметно-ориентированные означает, что рассматриваемые данные прелставляют некоторую конкретную предметную область, например заказчиков, продукты и т,п. Банки оперативных данных могут использоваться для разных целей: как область накопления для физической реорганизации извлеченных оперативных данных, для выдачи оперативных отчетов, а также лля поддержки оперативных решений. Кроме того, банки оперативных данных могут служить местом консолидации данных, если оперативные данные поступают из нескольких источников. Поэтому они могут быть предназначены для многих целей.
Заиечание. Поскольку банки оперативных данных не накапливают исторические данные, обычно они не разрастаются ло слишком больших объемов. С другой стороны, банки оперативных данных обычно достаточно часто или даже непрерывно обновляются информацией из источников оперативных данныхв. Проблемы синхронизации времени (см. полраздел "Преобразование и консолидация данных") в операционных хранилищах данных могут успешно преодолеваться, если обновление выполняется достаточно часто. 21.5. Хранилища данных и магазины данных Оперативные системы с базами, данных обычно характеризуются жесткими требованиями к производительности, предсказуемым уровнем обшей нагрузки, небольшими елиницами работы и высоким коэффициентом использования.
Системы поддержки принятия решений, напротив, обычно имеют различные требования к производительности, непредсказуемый уровень нагрузки, большие единицы работы и характеризуются нере- В Иногда для этих целей используется асинхронная репликация из источников оперативных данных непосредственно а банки оперативныл данных. В этом случае состояние данных может отличаться от текущего всего лишь на несколько леинут 829 Глава 21.
Поддержка нринятзся решений гулярным использованием. Из-за этих различий могут возникнуть трудности в отношении совмещения функционирования оперативной системы обработки данных и системы поддержки принятия решений внутри единой системы. Особенно это касается планирования объемов, управления ресурсами и настройки производительности системы, Поэтому системные администраторы обычно неохотно разрешают устанавливать приложения поддержки принятия решений на своих системах, особенно если имеют практический опыт работы с двумя системами одновременно.
Замечание. Отметим в качестве небольшого отступления, что так было не всегда. Раньше системы поддержки принятия решений реализовались на базе оперативных систем, но с низким приоритетом или во время так называемых "пакетных окон". При наличии достаточных вычислительных ресурсов этот подход имеет несколько преимушеств, и, пожалуй, наиболее очевидным из них является то, что он позволяет избежать всевозможных затратных процедур копирования и переформатирования данных, а также дополнительных операций передачи информации, необходимых при работе с двумя отдельными системами. На практике преимушества от совместного функционирования оперативных систем и систем поддержки принятия решений находят все большее понимание. Однако подробное рассмотрение интеграции этих систем выходит за рамки данной главы.
Тем не менее, несмотря на сказанное в предыдущем абзаце, остается неоспоримым тот факт, что, по крайней мере на время написания книги, данные систем поддержки принятия решений обычно извлекаются из различных оперативных систем (часто в корне отличных по своей организации) и помещаются в собственное хранилище, реализованное на отдельной платформе. Такое отдельное хранилище данных называют хранигиигеи данных. Хранилище данных Подобно банкам оперативных данных (а также магазинам ланных; см. следующий подраздел), хранилище данных — это специальная база данных. Этот термин возник, по-видимому, в конце ! 980 года (21.13], 121.17), хотя соответствующая концепция появилась несколько позднее.
В 121.18) хранилище данных определяется как "предметно- ориентированное, интегрированное, постоянное, изменяемое во времени хранилище данных для поддержки управленческих решений". Здесь термин поспюякное означает, что, будучи ввеленными, данные впоследствии не изменяются, хотя и могут быть удалены. Хранилища данных появились по двум причинам: во-первых, для систем поддержки принятия решений необходимо было предоставить отдельный, чистый, согласованный источник данных и, во-вторых, этой цели следовало достичь, не оказывая влияния на функционирование оперативных систем. Согласно определению ожилаемая рабочая нагрузка на хранилище данных — это ожидаемая рабочая нагрузка в системе поддержки принятия решений.
Поэтому можно ожидать, что хранилище данных будет подвергаться частым обращениям с запросами, а также периодической пакетной обработке для обновления данных. Кроме того, для хранилищ данных характерен весьма большой объем занимаемой памяти — часто он превышает 500 Гбайт и может увеличиваться на 50'/о в год. Вследствие этого бывает трудно добиться высокой производительности системы, хотя и нельзя сказать, что это невозможно, Также могут возникнуть проблемы, связанные с расширяемостью базы данных. Причины подобных затруднений обычно кроются в ошибках проектирования базы данных (обсуждавщихся в последнем подразделе раздела 21.3), неэффективном использовании реляционных операций (что обсуждалось в разделе 21.2), наличии недостатков в 830 Часть г".
Дополнительные аспекты реализации реляционной модели в целевой СУБД, недостаточных возможностях расширения, реализованных в самой целевой СУБД, наличии ошибок в архитектуре проекта, ограничивающих объемы и препятствующих масштабированию платформы. Обсуждение двух последних причин выходит за рамки книги„а две первые уже рассматривались в этой главе. Единственная оставшаяся причина обсуждается в других частях этой книги.
Магазины данных Хранилища данных в общем случае представляют собой единый источник информации для любой обработки, связанной с поддержкой принятия решений. Однако в начале 90-х годов, когда хранилища данных только приобретали популярность, было обнаружено, что чаше всего пользователи составляли пространные отчеты и выполняли различные операции анализа данных на относительно небольшом подмножестве полного объема информации в хранилище данных. И действительно, пользователи повторяли те же самые операции на том же самом подмножестве данных каждый раз после их обновления. Более того, некоторые из этих операций — например, предикативный анализ (прогноз), имитация, моделирование "что если'* на основе деловых данных — включали создание новых схем и данных с последующим обновлением этих новых данных.
Неоднократное повторное выполнение таких операций на одном и том же подмножестве информации полного хранилища данных, безусловно, не очень эффективно. Поэтому возникла очевидная идея построения некоторого ограниченного "хранилища" специального назначения, которое подходило бы для достижения рассматриваемых целей. Кроме того, в некоторых случаях можно извлекать и обрабатывать данные непосредственно из локальных источников, предоставляя более быстрый доступ к данным по сравнению с тем, который мог быть предоставлен при синхронизации со всеми остальными данными, загруженными в полное хранилище.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
