Содержание
1. СУБД
– системы управления базами данных и
требования
к их функциональным
возможностям
стр. 2
2. Распределенные
системы обработки данных
стр. 3
а) СУБД структуры «сервер – клиент».
Особенности построения
и работы
стр. 3
б)
СУБД компании Microsoft. Особенности
построения и работы
стр. 5
в)
СУБД компании Oracle. Особенности построения
и работы
стр. 6
г)
СУБД компании Informix. Особенности построения
и работы
стр. 8
д)
СУБД компании Sybase. Особенности построения
и работы
стр. 10
3. Выводы
стр. 12
4. Список
используемой литературы
стр. 14
Системы
управления базами данных
и определенные требования
к их функциональным
возможностям
Для взаимодействия пользователей
с БД используются системы
управления базами данных (СУБД),
которые обеспечивают:
• набор средств для поддержки
таблиц и соотношений между
ними;
• развитый пользовательский
интерфейс, позволяющий вводить
и модифицировать информацию, проводить
поиск и представлять результаты;
• средства программирования,
позволяющие создавать собственные приложения.
Подход к построению СУБД значительно
видоизменялся на протяжении
почти 40 лет. На смену ВЦ
предприятий и АСУП на их
основе пришли персональные компьютеры
и настольные (персональные) системы
управления базами данных, затем с
развитием коммуникаций появились распределенные
системы и концепции управления крупными
предприятиями- корпорациями на основе
изучения бизнес-процессов. При этом в
условиях динамичного их изменения в последние
годы сформулирован ряд
определенных требований
к функциональным возможностям
СУБД, производители которых стремятся
поддерживать свои продукты на высоком,
конкурентоспособном уровне.
- Обеспечение
непротиворечивого определения
данных для всех используемых платформ,
сетей и БД при сохранении распределенной
архитектуры системы в целом, поскольку
создание единой базы становится неприемлемым
из-за ее громоздскости и высокой стоимости.
Это означает, что создаваемые средствами
СУБД приложения должны обладать высокой
степенью мобильности и легко переноситься
на разные компьютерные и сетевые платформы,
когда на первый план выходят проблемы
синхронизации и целостности. Кроме того,
это позволяет в дальнейшем более свободно
развивать ресурсы системы.
- Коммуникационный
обмен данными становится асинхронным,
а информационные процессы – длительными,
поэтому возникает необходимость журнализации
состояния баз данных и проведения возможного
отката/восстановления для расширения
временных рамок (дни, недели).
- Средства
СУБД должны допускать возможность гибкого
варьирования архитектурой различных
ИС для соблюдения разумного компромисса
при разделении функциональных возможностей
системы между рабочими станциями клиентов
и серверами. Современный уровень технологий
(графический оконный интерфейс, мультимедиа-приложения)
и возможность интеграции наследуемых
частей систем приводят к целесообразности
выполнения этих функций на достаточно
развитых станциях клиентов. В то же время
системы, обладающие «мощными» серверами
(когда на последних осуществляется почти
вся работа), демонстрируют масштабируемость,
требуют меньших усилий для создания новых
версий ИС при переконфигурировании данных,
обладают повышенными показателями целостности
и безопасности данных за счет размещения
процедур на сервере. Кроме того, архитектуры,
использующие размещение программ-приложений
на сервере, благодаря их непосредственной
близости к данным характеризуются менее
напряженным сетевым трафиком.
- Создание
«менеджеров процессов» может быть эффективным
только в таких условиях, когда средства
программирования СУБД объектно-ориентированы
и возможно создание стабильных приложений
при динамичном изменении маршрутизации
сквозь эти задачи. Критически важным
становится подход многократного использования
программного обеспечения, при котором
обеспечивается требуемая бизнес-процессами
гибкость и легкость создания новых версий
ИС.
- Производителям
СУБД следует обеспечить соответствие
поставляемых ими продуктов открытым
стандартам взаимодействия, так как
все чаще информационные системы призываются
для реализации потоков запросов в архитектуре
«клиент-сервер», охватывающих платформы
различных поставщиков. При этом предусмотрительные
владельцы ИС выиграют в наибольшей степени,
когда будут использовать инструментарий
разработки, охватывающий различные СУБД.
- Расширение
бизнес-процессов за пределы одной компании
и необходимость создания глобальных
информационных связей выдвигает серьезную
задачу поддержки высокой степени готовности
систем, работающих 24 часа в сутки все
365 дней в году. Это означает, что средства
СУБД должны гарантировать администрирование
баз данных в «горячем» режиме без остановки
основных процессов.
Перечисленные требования к СУБД
позволяют взглянуть на существующие
в настоящее время на рынке
продукты разных производителей
под соответствующим углом зрения.
Адекватность предлагаемых сегодня СУБД
новым требованиям определит для их будущих
владельцев и клиентов преимущества создаваемых
ИС, их гибкость, мобильность, возможность
легкой перестройки и, в конечном счете,
способность к выживанию.
Распределенные
системы обработки
данных
СУБД
структуры «сервер-клиент»
Построение распределенных систем
важно, особенно в условиях
бессистемного оснащения предприятий
компьютерной техникой, когда многие
уже работают (или им необходимо
работать) с системами, состоящими из множества
компьютеров разного типа (серверов, мини-компьютеров,
больших машин).
Централизованное хранение данных
и доступ к центральной БД в условиях
географически распределенной системы
требуют устройства соединений между
центральным сервером, хранящим данные,
и компьютерами-клиентами. Большинство
таких компьютеров отделены от центрального
сервера медленными и недостаточно надежными
линиями связи, и работа в режиме удаленного
клиента становится почти невозможной.
Этим можно объяснить существующую ситуацию,
когда в узлах распределенной системы
функционируют группы автоматизированных
рабочих мест (APM), абсолютно не связанные
друг с другом.
Содержательная сторона задачи
обычно требует обмена данными
между группами АРМ, так как изменения
в какие-либо данные могут вносить в одной
группе, а использоваться – в другой. На
практике обмен информацией реализуется
регламентной передачей файлов – через
модемное соединение или «с курьером».
То, что данные доставляются к месту
назначения не системными средствами,
а путем экспорта/импорта файлов, требует
участия человека в процессе обмена, а
это влечет за собой невысокую оперативность
поступления данных и требует использования
внешних механизмов контроля целостности
и непротиворечивости. В результате возрастает
вероятность появления ошибок. Кроме того,
реализация всех алгоритмов обмена данными
и контроля в этом случае возлагается
на прикладных программистов, проектирующих
APM. Объем работ по программированию и
отладке подпрограмм обмена соответствует
числу различных APM. Это также приводит
к повышению вероятности сбоев в работе
системы.
В современных технологиях APM
объединены в локальную сеть. АРМ клиента
выдает запросы на выборку и обновление
данных, а СУБД исполняет их. Запросы клиента
в соответствии с требованиями задачи
сгруппированы в логические единицы работы
(транзакции). Если все операции с базой
данных, содержащиеся внутри транзакции,
выполнены удачно, транзакция в целом
также выполняется успешно (фиксируется).
Если хотя бы одна из операций с БД внутри
транзакции осуществлена неудачно, то
все изменения в БД, происшедшие к этому
моменту из-за транзакции, отменяются
(происходит откат транзакции). Такое функционирование
обеспечивает логическую целостность
информации в базе данных.
При распределенной обработке
изменения, проводимые приложением-клиентом,
могут затрагивать более чем
один сервер СУБД. Для поддержания
целостности и в этом случае
необходимо применение того или
иного транзакционного механизма,
реализуемого системными средствами,
а не прикладной программой.
Но основной недостаток систем,
построенных на распределенных
транзакциях,- высокие требования
к надежности и пропускной
способности линий связи. Поэтому
альтернативой распределенным транзакциям
является репликация (дублирование)
данных. В таких системах одна и та же информация
хранится в различных узлах. Согласование
значений и распространение данных по
узлам осуществляются автоматически.
В зависимости от условий, предусмотренных
разработчиком, репликация может осуществляться
либо сразу после наступления некоторого
события, либо через заранее заданные
интервалы времени, либо в определенный
момент времени. Если узел, в котором выполняется
репликация, в данный момент недоступен,
информация об этом сохраняется в вызывающем
узле и репликация осуществляется после
восстановления связи. Более того, гарантируется
сохранение заданного вызывающим узлом
порядка выполнения репликации.
Современные СУБД используют
так называемый системный
журнал, в который вносят записи об изменениях
в базе данных и завершении транзакций.
Журнал используется сервером БД для отката
или прокрутки транзакций после сбоев
и для резервного копирования. Измененные
данные из журнала передаются репликационному
серверу, обслуживающему этот узел, который
в соответствии с описанием тиражирования
и подписками отправляет данные в эффективном
специальном протоколе по месту назначения,
т.е. к соответствующим репликационным
серверам в удаленных узлах.
Именно в этом сечении –
между репликационными серверами
– связь может быть медленной или недостаточно
надежной. Передаваемые данные в составе
транзакций при недоступности узла-получателя
записываются в стабильные очереди на
диске и затем передаются по мере возможности.
В одной базе данных могут
содержаться как первичные данные, так
и данные-копии. Приложение-клиент, работающее
со своей СУБД, может вносить изменения
напрямую (операторами INSERT, DELETE, UPDATE) только
в первичные данные. Для изменения копии
данных предназначен механизм асинхронного
вызова процедур. Для работы этого механизма
в нескольких базах данных создаются процедуры
с одинаковым именем и параметрами, но,
разумеется, с различным текстом. В одной
базе данных процедура помечается как
предназначенная к репликации. Вызов этой
процедуры вместе со значениями параметров
через журнал и механизм репликации передается
к узлам-подписчикам, и в их базах данных
вызывается одноименная процедура с теми
же значениями параметров.
Система, хранящая вторичные данные,
может быть любой из ряда
систем, доступных через шлюз: будь то
Oracle, Informix, DB2, RMS или ISAM и т.д. Система, хранящая
первичные данные, требует наличия менеджера
журнала транзакций (Log Transfer Manager – LTM).
Интерфейс LTM является открытым, и в скором
будущем, возможно, подобные модули будут
созданы для нестандартных источников
данных.
Вообще тиражирование данных
может найти самое разнообразное
применение:
• для разгрузки сервера, выполняющего
активное обновление данных от
сложных запросов, связанных с
поддержкой принятия решений;
• для консолидации данных
от подразделений в центре;
• для обмена данными по
медленным или ненадежным линиям
связи;
• для поддержания резервной
базы данных;
• для построения сети равноправных
узлов, обменивающихся данными.
Подчеркнем, что репликационный сервер
тиражирует транзакции, а не отдельные
изменения в базе данных. Метод тиражирования
транзакций гарантирует целостность внутри
транзакций и, как следствие, невозможность
нарушения ссылочной целостности. Схема
обновления первичных данных и копий данных
исключает возможность возникновения
конфликтов; последние могут быть вызваны
лишь неправильным проектированием системы
или сбоем.
Большинство производителей современных
промышленных СУБД в той или
иной степени обеспечивают поддержку
распределенной обработки транзакций.
Распределенная обработка данных основывается
на синхронных и асинхронных механизмах
обработки распределенных транзакций.
Эти механизмы могут использоваться и
совместно. Поскольку каждый механизм
обладает своими сильными и слабыми сторонами,
его выбор зависит от требований конкретной
подзадачи.