Реферат по "Интегрированным системам"

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

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

Тогда запрос "получить информацию о сотрудниках компании" может  быть сформулирован так:

 

SELECT * FROM employee@donetsk, employee@kiev

 

На рисунке 1 изображен принцип разделения данных при горизонтальной фрагментации.

На рисунке 2 приведен пример горизонтальной фрагментации.

Рис. 1 Горизонтальная фрагментация

 

Рис. 2 Пример горизонтальной фрагментации

 

При вертикальной фрагментации отношение  делится на разделы при помощи операции проекции. Например, один раздел отношения Employee может содержать поля Номер_сотрудника (emp_id), ФИО_сотрудника (emp_name), Адрес_сотрудника (emp_adress), а другой – поля Номер_сотрудника (emp_id), Оклад (salary), Руководитель (emp_chief).

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

 

SELECT employee.emp_id, emp_name, salary

FROM employee@donetsk, employee@kiev

ORDER BY emp_id

 

На рисунках 3 и 4 изображены сущность и пример вертикальной фрагментации.

Рис. 3 Вертикальная фрагментация

 

Рис. 4. Пример вертикальной фрагментации

 

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

Репликация данных

 

Второй способ распределения данных – репликация (рис.5). Репликация (или тиражирование) означает создание дубликатов данных. Репликаты – это множество различных физических копий некоторого объекта базы данных (обычно таблицы), для которых поддерживается синхронизация (идентичность) с некоторой "главной" копией.

 

Рис. 5. Репликация

 

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

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

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

В современных СУБД функции репликации выполняет, как правило, специальный  модуль – сервер тиражирования данных, называемый репликатором (так устроены СУБД CA – OpenIngress и Sybase). В Informix-OnLine Dynamic Server репликатор встроен в сервер, в Oracle для использования репликации необходимо приобрести дополнительную опцию Replication Option.

Спецификация механизмов репликации зависит от используемой СУБД. Простейший вариант – использование “моментальных  снимков” (snapshot).

 

 

 

Каталог распределенной системы

 

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

1. Централизированный каталог. Весь каталог храниться в одном месте, т.е. на центральном узле.
2. Полностью реплицированный каталог. Весь каталог полностью хранится на каждом узле.
3. Секционированный каталог. На каждом узле содержится его с собственный каталог для объектов, хранимых на этом узле. Общий каталог является объединением всех разъединенных локальных каталогов.
4. Комбинация первого и третьего вариантов. На каждом узле содержится его собственный каталог (как в п.3), кроме того, на одном центральном узле хранится унифицированная копия всех этих локальных каталогов (как в п.1).

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

 

Заключение

 

В основе любых технологических  потрясений лежит простой экономический  расчет: выгодно - невыгодно. В основе нынешней ситуации в развитии распределенных систем также лежит экономическое  обоснование - стоимость передачи данных по сети становится меньше стоимости  вычислений на клиентской машине и  эта тенденция имеет устойчивый характер. Взрывной рост Internet, который многие связывают с "демократическими свободами" или развитием новой технологии имеет в своей основе все тоже простое экономическое обоснование - эта технология экономически выгодна. Отсюда проистекают и те изменения в мире технологий свидетелями которых мы являемся: стремительный рост пропускной способности каналов, присутствие в сети большинства корпораций и масс медиа, электронная коммерция и банки … На основе этих технологий выросли новые направления бизнеса, а распространенность Internet растет темпами невиданными в отрасли (быстрее телефонии и телевидения).

Однако, если присмотреться поближе к этой технологии, то в ней нет ничего революционного, за исключением того, как уже известные решения применены в новой области. Давно известны языки разметки (TeX), протоколы передачи данных (TCP) и удаленных сервисов (NSF, POP), распределенные транзакции (мониторы транзакций), платформопереносимые языки (С, Perl) и т.д.

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

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

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

Значительно пересмотрены и другие концепции, казавшиеся незыблемыми. К  примеру, технология клиент - сервер построена  на обращении клиента к серверу  по частному протоколу (SQL Net в случае). Находящийся на стороне сервера listener обеспечивает соединение и обработку запроса. Возникает вопрос - а почему к СУБД можно обращаться только по одному специальному протоколу? Ведь при построении приложения в Internet приходится несколько раз проводить преобразование протоколов http в SGI (Perl, сервлеты и т.п.) и затем в SQL. Когда можно просто поручить listener'у иметь возможность обрабатывать запросы по http, POP3, IMAP4, NFS и другим. Подобная концепция реализованная в Oracle8i позволяет реально превратить реляционную СУБД в хранилище информации в Internet. Подобные решения кардинальным образом переворачивают наши представления о правильно построенной информационной системе, но это неизбежная дань за участие в очередной технологической революции.

Подход корпорации Oracle основан на полном признании сложившихся стандартов и их интеграцию (тоже на основе стандартов). Для Oracle вопрос не ставится как "или" клиент-сервер "или" Web "или" распределенные объекты, решение Oracle являются объединением лучших черт технологий клиент-сервер (мощность, устойчивость, транзакции), Web (легкость распространения и управления, тонкий клиент) и распределенных объектов (компонентное программное обеспечение, интеграция решений от разных производителей и распределение задачи по всем компьютерам в сети). Такая интеграция возможна на основе стандартов CORBA 2.0 (Архитектура Диспетчера Объектных Запросов) , HTTP/HTML, IIOP (Internet Inter Object Protocol), COM/DCOM (стандарт Microsoft) и Java.

В основе подхода Oracle лежит WRB (Диспетчер Объектных Запросов Web), связанный с Web сервером и управляющий всеми объектами в сети. Такие объекты могут располагаться на сервере приложений (любом сервере в сети), в базе данных (используя все возможности Базы Данных Oracle 7 и особенно объектные расширения Oracle 8) или на клиентской части (браузере). При этом все объекты (картриджи) предоставляют Диспетчеру Объектных Запросов свой интерфейс и после этого могут вызывать друг друга, создавать новые экземпляры объектов и т.д. Управление объектами, их установка, секретность, регулировка загрузки серверов и др. возможности обеспечиваются WRB. Такая архитектура называется Архитектура Сетевых Вычислений.

Таким образом любое приложение используемое в Архитектуре Сетевых Вычислений становится независимым от языка программирования (Java, C/C++, SQL, Visual Basic и др.), независимым от типа архитектуры (клиент-сервер, web) и может быть легко интегрировано с любым другим приложением (картриджем), даже разработанным другим производителем.

Подобный подход позволяет разрабатывать  любые приложения для Web. При этом страницы HTML не существуют до появления запроса пользователя и генерируются в виде последовательности команд HTML по запросу пользователя и содержат только ту информацию, которая запрашивалась в запросе. Дальнейшим расширением "виртуальных" HTML страниц по запросу является использование Java applets передаваемых на браузер, создающие интерфейс аналогичный интерфейсу экранных клиент-сервер с аналогичной функциональностью и поддержкой транзакций и секретности (SSL 3.0).

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

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

 

Литература

 

 

1. Е.Н. Коровин. Методология прогнозирования и оптимального управления территориально распределенными социально-экономическими системами на основе трансформации информации и многовариантного моделирования : Дис. ... д-ра техн. наук : 05.13.01, 05.13.10 Воронеж, 2005 356 с. РГБ ОД, 71:06-5/194

 

2. Ю.И. Шокин, А.М. Федотов Информационные технологии. Internet // Вычислительные технологии Том 2, N 3, 1997.

 

3. M. Tamer Ozsu, Patrick Valduriez. Distributed and parallel database systems. //Открытые системы. # 4/1996.

 

4. Date C.J. 1987. What is distributed database? InfoDB, 2:7

 

5. Г.М. Ладыженский. Технология "клиент-сервер" и мониторы транзакций. //Открытые информационные системы

 

6. В.И. Коржов, Многоуровневые системы клиент-сервер // Сети, #06/1997

 

7. В.А. Гладцын, К.В. Кринкин, В.В. Яновский. Сервис-ориентированная архитектура, стандарты, алгоритмы, протоколы. —СПб.: Издательство СПбГЭТУ "ЛЭТИ", 2006;