Автор работы: Пользователь скрыл имя, 20 Февраля 2011 в 12:52, контрольная работа
В начале 70-х годов для удобства работы с большими массивами данных сформулирована концепция баз данных. Ее основными положениями были:
1.Независимость прикладных программ от данных, размещенных во внешней памяти
2. Отсутствие избыточности в данных
3.Способность системы противостоять сбоям и отказам.
Очевидно, что чем меньше информационный объект по своим размерам, тем выше параллелизм в работе транзакций, так как вероятность конфликта между разными транзакциями уменьшается. Недостатком, как уже было отмечено, является рост накладных расходов системы.
Чаще всего блокирование
Различают 2 типа блокировок:
Рассмотрим правила блокирования:
А) запрос со стороны транзакции В на Х-блокировку этого же кортежа будет отвергнут;
Б) запрос со стороны транзакции В на S-блокировку этого же кортежа будет принят ( т.е. транзакция В сможет установить S-блокировку на кортеж p).
В правилах указано, что
в качестве "блокируемых объектов"
используются кортежи, хотя еще
раз подчеркнем, что могут быть и
другие типы объектов.
Эти правила можно формально
описать с помощью матрицы
совместимости, представленной
Матрица совместимости для Х- и S-блокировки Таблица 1
X | S | - | |
X | N | N | Y |
S | N | Y | Y |
- | Y | Y | Y |
Матрицу совместимости можно интерпретировать следующим образом. Рассмотрим некоторый кортеж р и предположим, что транзакция А блокирует кортеж р различными типами блокировки (это обозначено соответствующими символами S и X, а отсутствие блокировки — прочерком). Предположим также, что некоторая транзакция В запрашивает блокировку кортежа, что обозначено в первом слева столбце матрицы (для полноты картины, в таблице также приведен случай "отсутствия блокировки"). В других ячейках матрицы символ N обозначает конфликтную ситуацию (запрос со стороны транзакции В не может быть удовлетворен, и сама эта транзакция переходит в состояние ожидания), a Y — полную совместимость (запрос со стороны транзакции B удовлетворен).
Большинство современных СУБД устанавливает блокировки автоматически, т.е. неявным образом: например, запрос на "извлечение кортежа" является неявным запросом с S-блокировкой, а запрос на "обновление кортежа" — неявным запросом с Х-блокировкой соответствующего кортежа. При этом под термином "обновление" подразумеваются помимо самих операций обновления также операции вставки и удаления.
В большинстве случаев блокировки устанавливаются применительно к кортежам.
Но такой механизм неявного блокирования иногда может быть не удобен для пользователя и системы. Поэтому система может устанавливать блокировки и применительно к отдельным таблицам (например, в случае, когда таблица очень интенсивно используется какой то транзакцией), и применительно к отдельным страницам базы данных или ко всей базе данных.
Отметим что, наблюдается некоторый тонкий баланс между размером блокируемого информационного объекта и параллелизмом: чем мельче блокируемый информационный объект, тем выше параллелизм, чем крупнее блокируемый информационный объект, тем меньше параллелизм.
Некоторые СУБД обеспечивают возможность явного (преднамеренного в полном смысле этого слова) задания блокировок с помощью разного рода операторов типа LOCK.
Например, оператор LOCK поддерживается системами DB2 и ORACLE. Однако следует иметь в виду, что этот оператор не является оператором языка SQL! Поэтому удобное в некотором смысле средство может быть серьезным орудием, понижающим эффективность разрабатываемой информационной системы (в случае, когда программисты злоупотребляют использованием указанного оператора).
Лекция
13
Тема 2
Интеграция данных
2.1. Хранилища данных
Концепция интеграции данных предусматривает использование содержимого двух или более баз данных с последующим конструированием одной крупной базы данных.
Исходная концепция интеграции данных была предложена специалистами фирмы IВМ в виде "информационного хранилища" и первоначально представлена ими как решение, обеспечивающее доступ к данным, накопленным в нереляционных системах. Предполагалось, что такое информационное хранилище позволит организациям использовать их архивы данных для эффективного решения производственных задач. Однако из-за чрезвычайной сложности и невысокой производительности подобных систем, созданных на начальных этапах, первые попытки создания информационных хранилищ в основном были отвергнуты. С тех пор к концепции хранилищ информации возвращались вновь и вновь, но только в последние годы потенциал технологии хранилищ данных стал рассматриваться как достаточно ценное и жизнеспособное решение.
Наиболее упорным и удачливым
сторонником технологии
Хранилище - это предметно - ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для поддержки принятия решений.
В приведенном выше
• Предметная ориентированность. Хранилище данных организовано в виде специфических разделов, описывающих основные предметы (или субъекты) организации (например, клиенты, товары и продажи), а не прикладные области деятельности (выписка счета клиенту, контроль товарных запасов и продажа товаров).
Это свойство отражает необходимость хранения данных, предназначенных для поддержки принятия решений, а не обычных оперативно-прикладных данных.
• Интегрированность. Смысл этой характеристики состоит в том, что оперативно-прикладные данные обычно поступают из разных источников, которые часто имеют несогласованное представление одних и тех же данных, например, используют разный формат. Для предоставления пользователю единого обобщенного представления данных необходимо создать интегрированный источник, обеспечивающий согласованность хранимой информации.
• Привязка ко времени. Данные в хранилище точны и корректны только в том случае, когда они привязаны к некоторому моменту или промежутку времени,
Привязанность хранилища данных ко времени следует из большой длительности того периода, за который была накоплена сохраняемая в нем информация,
В отличие от операционных данных, привязанных к текущим транзакциям, хранилище данных представляет собой поток данных во времени.
Например,
когда в хранилище данных
После того как данные записаны в хранилище (т.е. выполнена операция вставки) они никогда из него не удаляются, оно постоянно растет. Кроме того эти данные не модифицируются (т.е. не выполняются операции типа Update).
Интегрирующая архитектура хранилища данных предусматривает извлечение (выгрузку) информации из нескольких источников и сочетание ее в рамках глобальной схемы хранилища, которое воспринимается пользователем как традиционная база данных.
На рис. 2.1 представлен пример интеграции данных на основе двух источников.
Рис.2.1 Организация хранилища данных
Компонент извлечения данных
представляет собой
Компонент трансляции/загрузки
Способы трансляции и
Как только информация загружена в хранилище данных, ее можно считывать совершенно так же, как и содержимое любых баз данных.
Существует три основных способа сбора информации в хранилище данных.
1.Содержимое
хранилища периодически (скажем, еженощно)
реконструируется на основе текущей информации
источников — наиболее общий подход, основной
недостаток которого зачастую связан
с необходимостью "отключения" системы
от внешнего мира на время выполнения
процедуры трансляции/загрузки, нередко
весьма продолжительной. Другой изъян
заключается в том, что данные в хранилище
быстро теряют актуальность.
2. В хранилище периодически заносятся данные из источников, претерпевшие изменения с момента осуществления последней загрузки.
Количество переносимых данных в этом случае, как правило, существенно ниже, что весьма важно, если время, отводимое на обновление информации, ограниченно и/или объем хранилища велик (обычной практикой является создание и поддержка хранилищ, размер которых исчисляется многими гигабайтами или даже терабайтами).
Недостаток подхода состоит в сложности процедуры инкрементного обновления в сравнении с прямолинейным алгоритмом полной загрузки данных.
3. Информация
в хранилище обновляется
Использование подобной стратегии предполагает интенсивный обмен данными и может оказаться оправданным, вероятно, только в тех ситуациях, когда размер хранилища невелик и частота операций изменения источников низка.
Медиатор обеспечивает поддержку набора виртуальных таблиц, отображающих интегрированные данные из различных источников, — во многом так же, как хранилище данных, представляет материализованные отношения с обобщенной информацией из аналогичных источников. Однако медиатор сам по себе не сохраняет данные, поэтому механизм его действия существенно отличается от механизма хранилищ данных.