СУБД Ingres проектировалась в расчете на использование в среде ОС UNIX. Эта система играла роль своего рода виртуальной машины. Ориентация на использование UNIX наложила существенный отпечаток на общую организацию Ingres, на статическую и динамическую структуру СУБД.

     Прежде всего, все базы данных, обслуживаемые СУБД Ingres на данном UNIX-компьютере, хранятся в одном поддереве файловой системы. Каждой базе данных соответствует отдельный справочник, каждое отношение базы данных (включая служебные отношения) хранится в отдельном файле ОС UNIX. Защита программных компонентов системы от несанкционированного выполнения и баз данных от несанкционированного доступа основывается главным образом на общем механизме защиты файлов ОС UNIX. При установке СУБД Ingres автоматически заводится специальный "пользователь" ОС UNIX с именем Ingres, от имени которого работают все системные процессы Ingres, и только ему разрешается запускать эти системные процессы и обращаться к файлам баз данных. Более точное управление доступом берет на себя Ingres [7]. 

     Существуют  две возможности вызова Ingres - в  интерактивном режиме командой языка Shell или из прикладной программы, написанной на языке EQUEL и преобразованной прекомпилятором  языка EQUEL к программе на языке  Си. В первом случае создается следующая структура процессов:

     Во  втором случае структура процессов  выглядит следующим образом:

     Процесс 1 - это интерактивный терминальный монитор, позволяющий пользователю формулировать, редактировать и  выполнять наборы команд Ingres (операторов языка QUEL).

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

     Процесс 3 является ответственным за выполнение операторов выборки, занесения и удаления кортежей. В нем выполняется оптимизация запросов на основе техники декомпозиции сложных запросов. Кроме того, для операторов модификации кортежей производится предварительная выборка модифицируемых кортежей и подготовка их новых образов для реального выполнения модификации в процессе 4.

     Наконец, в процессе 4 выполняются так называемые команды-утилиты - создания и уничтожения  отношений, индексов и т.д., а также  упомянутая отложенная модификация кортежей.

     Процессы  связаны программными каналами (pipes) ОС UNIX. Прямая информация при обработке  операторов передается по каналам A, B и C. Результаты, включая сообщения  об ошибках, передаются по обратным каналам D, E и F. Процессы работают строго синхронно: после посылки прямого сообщения каждый процесс дожидается получения ответного сообщения, а после посылки ответного сообщения - ждет получения очередного прямого. 

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

     Следует отметить, что на описанную структуру оказал большое влияние тот факт, что первый вариант Ingres реализовывался для 16-разрядных компьютеров, в которых размер виртуальной памяти процесса был весьма ограничен. Поскольку процессы системы функционировали синхронно, принципиальной выгоды от наличия нескольких процессов не было. Но подход к разбиению системы на несколько процессов позволил выработать разумную статическую структуризацию системы, в ряде компонентов которой не используются общие данные. Кроме того, с развитием системы стали использоваться и реальные возможности распараллеливания [7]. 

     2.3. Архитектура Sybase System 11

     Фирма Sybase - один из ведущих производителей промышленных СУБД, средств разработки приложений и других продуктов, реализующих  технологию клиент-сервер [9]. Выпуская в конце 1995 года Sybase System 11, фирма предлагает оптимизированные по производительности средства для использования в каждой из трех важных областей работы (таблица 2. см. Приложение Б):

• текущая деятельность организаций (обработка транзакций в режиме online - OLTP);
• анализ и прогнозирование (поддержка принятия решений - DSS);
• массовое использование на персональных компьютерах, в точках продаж, малых филиалах (mass deployment).

     Архитектура Sybase System 11 поддерживает как синхронную, так и асинхронную модель управления транзакциями. Модель выбирается в соответствии с требованиями предметной области.

     Централизованное  хранение данных и доступ к центральной  БД в условиях географически распределенной системы приводят к необходимости  установления соединений между центральным сервером, хранящим данные, и компьютерами-клиентами. Большинство компьютеров-клиентов отделены от центрального сервера медленными и недостаточно надежными линиями связи, поэтому работа в режиме удаленного клиента становится почти невозможной. Этим можно объяснить часто существующую ситуацию, когда в узлах распределенной системы функционируют группы автоматизированных рабочих мест (АРМ) и эти группы АРМ не связаны друг с другом.

     Содержательная  сторона задачи обычно требует обмена данными между группами АРМ, так как изменения в данные могут вноситься в одной группе АРМ, а использоваться - в другой. Обмен данными на практике часто реализуется регламентной передачей файлов, либо через модемное соединение, либо "с курьером".

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

     В современной технологии АРМ объединены в локальную сеть. АРМ-клиент выдает запросы на выборку и обновление данных, а СУБД исполняет их. Запросы клиента в соответствии с требованиями задачи сгруппированы в логические единицы работы (транзакции). Если все операции с базой данных, содержащиеся внутри транзакции, выполнены успешно, транзакция в целом выполняется успешно (фиксируется). Если хотя бы одна из операций с БД внутри транзакции не выполнилась успешно, то все изменения в БД, произведенные к этому моменту из транзакции, отменяются (происходит откат транзакции). Такое функционирование обеспечивает логическую целостность данных в базе данных.

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

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

     Sybase System 11 - семейство интегрированных  продуктов, нацеленных на каждую область применения реляционной СУБД, от обработки данных в реальном времени до задач принятия решений и хранилищ данных, от тысяч пользователей и очень больших баз данных до "легкого" сервера для рабочих групп, который работает на персональном компьютере. В сочетании с мощными средствами разработки и CASE-системами той же фирмы этот набор средств вооружает разработчика для решения практически любых задач [9]. 
 
 
 

     2.4. СУБД Oracle

       Oracle Database 10g - первая в мире база  данных, разработанная специально для работы в сетях распределенных вычислений. Oracle Database 10g предназначена для эффективного развертывания на базе различных типов оборудования, от небольших серверов до Oracle Enterprise Grid мощных многопроцессорных серверных систем, от отдельных кластеров до корпоративных распределенных вычислительных систем. Oracle Database 10g предоставляет возможность автоматической настройки и управления, которая делает ее использование простым и экономически выгодным. Ее уникальные возможности осуществлять управление всеми данными предприятия - от обычных операций с бизнес-информацией до динамического многомерного анализа данных (OLAP), операций с документами формата XML, управления распределенной/локальной информацией - делает ее идеальным выбором для выполнения приложений, обеспечивающих обработку оперативных транзакций, интеллектуальный анализ информации, хранение данных и управление информационным наполнением [10].

       Oracle Database 10g позволяет пользователям виртуализировать использование аппаратного обеспечения - серверов и систем хранения данных. Oracle Database 10g обладает технологиями, которые позволяют администраторам надежно хранить и быстро распределять и извлекать данные для пользователей и приложений, работающих в сетях Grid. Oracle Database 10g значительно повышает производительность обработки данных и включает в себя удобные средства администрирования.

     Вот только некоторые ключевые возможности Oracle Database 10g:

     Real Application Cluster (RAC) обеспечивает работу  одного экземпляра базы данных  на нескольких узлах grid, позволяя управлять нагрузкой и гибко масштабировать систему в случае необходимости.  

     RAC используется для создания корпоративных  сетей распределенной обработки  данных. Такие сети строятся из  большого количества стандартизованных  недорогих компонентов: процессоров, серверов, сетевых устройств и устройств хранения данных. RAC - это программный продукт и технология, позволяющая объединить все эти компоненты в эффективную вычислительную систему всей организации. RAC и Grid-технологии дают возможность радикально снизить эксплуатационные затраты и обеспечить новый уровень гибкости, делая корпоративные системы более адаптивными, гибкими и динамичными. Динамическое обеспечение узлами, устройствами хранения, центральными процессорами и оперативной памятью позволяет быстро и эффективно гарантировать необходимые уровни сервиса при одновременном снижении затрат за счет лучшего использования ресурсов. Кроме того, архитектура RAC полностью прозрачна для приложения, работающего с кластерной базой данных - не требуется никаких модификаций приложения для его развертывания в среде RAC [10].

     Automatic Storage Management (ASM) позволяет автоматически  распределять данные между имеющимися  ресурсами систем хранения данных, что повышает отказоустойчивость  системы и снижает общую стоимость владения (TCO).

     Производительность. Oracle Database 10g позволяет автоматически  управлять уровнями сервиса и  тиражировать эталонные конфигурации в рамках всей сети.

     Простые средства разработки. Новый инструмент разработки приложений HTML DB позволит простым пользователям создавать эффективные приложения для работы с базами данных в короткие сроки.

     Самоуправление. Специальные механизмы Oracle Database 10g позволяют  самостоятельно перераспределять нагрузку на систему, оптимизировать и корректировать SQL-запросы, выявлять и прогно- зировать ошибки.

     Большие базы данных. Теперь максимальный размер экземпляра базы данных Oracle может достигать 8 экзабайт.

     Недорогие серверные системы. Oracle Database 10g может  использовать недорогие однопроцессорные компьютеры или модульные системы из "серверов-лезвий".

     В новой версии базы данных реализована  поддержка переносимых табличных  пространств, система управления потоками данных Oracle Streams и модель распределенных SQL-запросов. Для переноса существующих баз данных в среду Grid в них не потребуется вносить изменений, что позволяет быстро начать использовать все преимущества Oracle Database 10g [10]. 
 

     Заключение

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

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

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