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