2.9. Система управления передачей данных

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

Менеджер передачи данных не является частью СУБД; он представляет собой авто- номную систему со своими правами. Однако, поскольку очевидно, что от менеджера пе- редачи данных и СУБД требуется согласованная совместная работа, они иногда рассмат- риваются как равноправные партнеры в компоненте более высокого уровня, называемо- го системой базы данных и передачи данных. В этой системе СУБД отвечает за рабо- ту с базой данных, а менеджер передачи данных обрабатывает все сообщения, посту- пающие в СУБД и из нее, а точнее говоря, в то приложение, которое использует СУБД, и из него. Однако в этой книге об обработке сообщений нам осталось сказать относи- тельно немного (поскольку такая обширная тема вполне заслуживает самостоятельного обсуждения). В разделе 2.12 кратко рассматриваются вопросы передачи данных между отдельными системами (т.е. между отдельными машинами в сети передачи данных, по- добной Internet), но это уже совсем другая тема.

2.10. Архитектура "клиент/сервер"

В предыдущих разделах этой главы подробно обсуждалась так называемая архитек- тура ANSI/SPARC для систем баз данных. Ее упрощенная схема приведена на рис. 2.3. В настоящем разделе мы посмотрим на базу данных с несколько иной точки зрения. Общее назначение систем баз данных— это, конечно, поддержка разработки и выполнения приложений баз данных. Поэтому на высоком уровне систему баз данных можно рас-

сматривать как систему с очень простои структурой, состоящей из двух частей — серве- ра (внутреннего компонента или машины базы данных) и набора клиентов (внешнего компонента или внешнего интерфейса), как показано на рис. 2.5.

Конечные пользователи

Клиенты

Сервер

База данных

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

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

Замечание. Некоторые специальные "служебные" приложения могут оказаться ис- ключениями. Как упоминалось выше, они иногда работают непосредственно на внутреннем уровне системы (см. раздел 2.5). Подобные утилиты правильнее отно- сить к встроенным компонентам СУБД, а не к приложениям в обычном смысле. В следующем разделе утилиты обсуждаются более подробно.

Приложения, в свою очередь, делятся на несколько четко определенных категорий.

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

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

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

Поставляемые инструментальные средства, в свою очередь, делятся на несколько самостоятельных классов.

а) Процессоры языков запросов.

б) Генераторы отчетов.

в) Графические бизнес-подсистемы.

г) Электронные таблицы.

д) Процессоры обычных языков.

е) Статистические пакеты.

ж) Средства управления копированием или средства извлечения данных.

з) Генераторы приложений (включая процессоры языков четвертого поколения).

и) Другие средства разработки приложений, включая CASE-инструменты (CASE или Computer-Aided Software Engineering— автоматизация разработки про- граммного обеспечения), и т.д.

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

Завершим настоящий раздел ссылкой на последующий материал. Так как система в целом может быть четко разделена на две части (сервер и клиенты), появляется возмож- ность работы этих двух частей на разных машинах. Иначе говоря, существует возмож- ность организации распределенной обработки. Распределенная обработка предпола- гает, что отдельные машины можно соединить какой-нибудь коммуникационной сетью таким способом, что выполнение одной задачи обработки данных можно будет распре- делить на несколько машин этой сети. Как показала практика, эта возможность настоль- ко заманчива по различным соображениям (главным образом, экономическим), что тер- мин "клиент/сервер" стал применяться почти исключительно в тех случаях, когда клиен- ты и сервер действительно находятся на разных машинах. Более подробно распределен- ная обработка данных рассматривается ниже, в разделе 2.12.